<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.ietf.isis">
    <title>gmane.ietf.isis</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3383"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3382"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3381"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3380"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3379"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3378"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3377"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3376"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3375"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3374"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3373"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3372"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3371"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3370"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3369"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3368"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3367"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3366"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3365"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.isis/3364"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3383">
    <title>WG Doc Adoption Proposed:draft-previdi-isis-te-metric-extensions-03</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3383</link>
    <description>&lt;pre&gt;It seems that the discussion on "IS-IS Traffic Engineering (TE) Metric Extensions" has settled down and there was a request for this document to be adopted as a WG document.

If there are objects to adopting this document please let them be known in the next 2 weeks.

Thanks,
Chris &amp;amp; Dave.
&lt;/pre&gt;</description>
    <dc:creator>Christian Hopps</dc:creator>
    <dc:date>2013-05-17T14:48:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3382">
    <title>WG Doc Adoption Proposed:draft-chunduri-isis-extended-sequence-no-tlv-04.txt</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3382</link>
    <description>&lt;pre&gt;"draft-chunduri-isis-extended-sequence-no-tlv-04.txt" has been proposed to become a WG document. Please state any objections to this in the next 2 weeks.

Thanks,
Chris &amp;amp; Dave.
&lt;/pre&gt;</description>
    <dc:creator>Christian Hopps</dc:creator>
    <dc:date>2013-05-17T14:48:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3381">
    <title>Fwd: New Version Notification fordraft-gredler-isis-label-advertisement-02.txt</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3381</link>
    <description>&lt;pre&gt;Dear IS-IS working group,

have posted a new version of the IS-IS label advertisement draft.
the major changes between -00 to -02 are:

-support for signaling Bypass (FRR) Labels
-support for SPT labels using RFC4761 'VPLS' style label block
 advertisements. this is mainly to comply to RFC3031 which
 mandates that label allocation is a strict local procedure,
 and still not loose the comfort of getting an
 automatically provided transport mesh (similar to LDP).

 This provides similar functionality like first mentioned in
 http://tools.ietf.org/id/draft-tian-mpls-lsp-source-route-01.txt
 *without* the need of an RFC 3031 architectural violation.

 The advertised label blocks allow in addition to specify a particular
 rfc5120 topology and an algorithm (SPT). we got feedback
 that having a pluggable algorithm (e.g., but not limited to: MRT)
 would solve a couple of practical use cases for
 'infrastructure LSPs' in the area of make-before break, ordered FIB,
 etc.

the authors are looking for feedback and sugge&lt;/pre&gt;</description>
    <dc:creator>Hannes Gredler</dc:creator>
    <dc:date>2013-05-06T09:58:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3380">
    <title>Re: draft-previdi-filsfils-isis-segment-routing</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3380</link>
    <description>&lt;pre&gt;Hi Patryk,

On Apr 25, 2013, at 5:31 PM, Patryk Konczyk wrote:


indeed. In current SP topologies, and with current HW capabilities, 
the label stack size is a non issue. Having said that, we shouldn't 
neglect mechanisms for stack compression anyway.




the question is whether (and how much more) do you need to compress 
the stack and what benefits it brings you (assuming my statement 
above).




yes, we're in the process of updating the draft and more details 
are to come soon.




Hopefully yes!

Thanks.
s.


&lt;/pre&gt;</description>
    <dc:creator>stefano previdi</dc:creator>
    <dc:date>2013-04-29T14:00:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3379">
    <title>Biggest Fake Conference in Computer Science</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3379</link>
    <description>&lt;pre&gt;Biggest Fake Conference in Computer Science


We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without&lt;/pre&gt;</description>
    <dc:creator>johnsonhammond1&lt; at &gt;hushmail.com</dc:creator>
    <dc:date>2013-04-27T17:47:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3378">
    <title>Re: Advertising MPLS labels in IGP</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3378</link>
    <description>&lt;pre&gt;

sure.




well... you did initiate the thread... ;-)


s.




&lt;/pre&gt;</description>
    <dc:creator>stefano previdi</dc:creator>
    <dc:date>2013-04-26T10:31:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3377">
    <title>Re: Segment Routing - mixed IPv4 &amp; IPv6 handling forAdj-SIDs</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3377</link>
    <description>&lt;pre&gt;Hannes,

note that if you run a single ISIS instance with no MT support, then 
both v4 and v6 topologies MUST be congruent, right ? So, there are no 
such "v4-only" or "V6-only" links.

Now, regarding your point, I agree with Wim: we would need an AF field 
in the Adj-SID SubTLV.  

Thanks for pointing this out.

Also, we are refreshing the draft and I hope to submit the new version 
in a couple of weeks.

Thanks.

s.


On Apr 25, 2013, at 5:51 PM, Hannes Gredler wrote:

&amp;gt; &lt;/pre&gt;</description>
    <dc:creator>stefano previdi</dc:creator>
    <dc:date>2013-04-26T10:25:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3376">
    <title>Re: Advertising MPLS labels in IGP</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3376</link>
    <description>&lt;pre&gt;Hi Hannes,


Well I think the issue with that would be that existing boxes would
not be able to switch based on the v6 extension header without an
upgrade ... I was rather thinking that compatibility with existing
data plane is very important. Stacking just v6 or v4 headers would be
perhaps simpler.

Of course with MPLS there is no issue in this respect.


Indeed.


Yes I saw this. I also think per AF would be clean.

Thx,
R.
&lt;/pre&gt;</description>
    <dc:creator>Robert Raszuk</dc:creator>
    <dc:date>2013-04-26T08:57:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3375">
    <title>Re: Advertising MPLS labels in IGP</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3375</link>
    <description>&lt;pre&gt;| &amp;gt; there are well known techniques where every router independently
| &amp;gt; advertises a label block and an ordinal for himself.
| &amp;gt; see http://tools.ietf.org/html/rfc4761 for a working example
| &amp;gt; of this.
| | So how would this work if I want to encap each segment in v4 or v6
| address rather then mpls label ?

i can only speculate how this would work as clarence has not
yet submitted a spec - all i have is his slides from MPLSWC/IPv6WC
in paris. my understanding is that for e.g. the IPv6-SR plane tries
to mimicry an MPLS data-plane (fixed size 32-bit segment-IDs
embedded into an IPv6 extension-header) and the behavior would be
pretty much identical for MPLS/IPv6-SR for the transit (=non PHP (POP))
case. i'll defer to him for making a comment;
  | Would you send an address block with ordinal ?

i can only comment on the PHP behavior of MPLS (where i think your 
question also applies,
see similar thread asking stefano to add the notion of an 'AF' to
disambiguate label-advertisement).

so in that spirit we could&lt;/pre&gt;</description>
    <dc:creator>Hannes Gredler</dc:creator>
    <dc:date>2013-04-26T08:32:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3374">
    <title>Re: Advertising MPLS labels in IGP</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3374</link>
    <description>&lt;pre&gt;Hi Hannes,


So how would this work if I want to encap each segment in v4 or v6
address rather then mpls label ?

Would you send an address block with ordinal ?

Cheers,
R.
&lt;/pre&gt;</description>
    <dc:creator>Robert Raszuk</dc:creator>
    <dc:date>2013-04-25T21:50:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3373">
    <title>Re: Segment Routing - mixed IPv4 &amp; IPv6 handling forAdj-SIDs</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3373</link>
    <description>&lt;pre&gt;yes thats what i think as well … so the label encoding needs to get changed to include AF;
(*if* you want to carry labels as part of adjacencies …)

/hannes

On Apr 25, 2013, at 5:48 PM, Henderickx, Wim (Wim) wrote:

&amp;gt; &lt;/pre&gt;</description>
    <dc:creator>Hannes Gredler</dc:creator>
    <dc:date>2013-04-25T15:51:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3372">
    <title>Re: Segment Routing - mixed IPv4 &amp; IPv6 handling for Adj-SIDs</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3372</link>
    <description>&lt;pre&gt;For this I believe we need to allocate a adj-LBL for each address family.
My 2 cents

On 25/04/13 14:03, "Hannes Gredler" &amp;lt;hannes&amp;lt; at &amp;gt;juniper.net&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Henderickx, Wim (Wim</dc:creator>
    <dc:date>2013-04-25T15:48:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3371">
    <title>Re: draft-previdi-filsfils-isis-segment-routing</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3371</link>
    <description>&lt;pre&gt; Hello Stefano I've seen Clarence presentation about Segment Routing
at MWC in Paris. I like the concept of using IGP for signalling and to
simply use existing tools like remote LFA for traffic protection.
Traffic Engineering looks simple as well. My initial concern was
around large label stack  especially in cases where there is
significant amount of Traffic Engineering going on. Clarence pointed
out that this can be resolved with loose hops using just two labels in
majority of the cases.
 I was also chatting to Stewart Bryant and he suggested compressing
the label stack I belive you touched on that on page 6 in the ECMP
context. I was wondering if this could be extended for strict and
loose path signalled with single label only, so that we have the same
label stack as in LDP/RSVP based solution. This probably would require
additional signalling.
 IPv6 variant is looking interesting as well. I'm hoping that more
details will appear in the draft shortly and we will have more
discussion on the mailing list.

&lt;/pre&gt;</description>
    <dc:creator>Patryk Konczyk</dc:creator>
    <dc:date>2013-04-25T15:31:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3370">
    <title>ISIS Mib file info</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3370</link>
    <description>&lt;pre&gt;Dear All

I was searching standard ISIS mib file but I do see that RFC 4444 tells the
standards but I dont find any standard mib file on web.

Can someone let me know ?
1) Where I can find latest standard mib of ISIS which provide support for
Ipv4 &amp;amp; v6 as well.
2) As per RFC 4444 Module identity is {mib-2 138}, so that is it something
like this mib module is under Private or enterprise?

thanks in advance.
Satya
_______________________________________________
Isis-wg mailing list
Isis-wg&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
&lt;/pre&gt;</description>
    <dc:creator>satya prakash</dc:creator>
    <dc:date>2013-04-23T07:13:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3369">
    <title>Re: Advertising MPLS labels in IGP</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3369</link>
    <description>&lt;pre&gt;+ isis-wg, as some of my customers have already complained that the
discussion on segment routing is not done on public mailing lists.

On Apr 25, 2013, at 1:58 PM, Saku Ytti wrote:


well first and foremost it is inline with current MPLS framework and domain-wide labels
are not - so the IESG police is going to ask some tough questions.
if you are breaking the law you rather need to have some good reasoning.

i fail to see what additional complexity it is if i use an ordinal to
the label range offered by my downstream router to determine the actual
label value, rather than explicitly signaling the label value (and hoping) that
no router in the domain will clash with the reserved label range.

my take is that giving up the notion of router-local label assignment
is something which can not easily done as one might not oversee the
consequences if doing so.


global-significant labels have been discussed before and people
have decided against it; why open the discussion again,
and what facts have been changed si&lt;/pre&gt;</description>
    <dc:creator>Hannes Gredler</dc:creator>
    <dc:date>2013-04-25T12:19:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3368">
    <title>Segment Routing - mixed IPv4 &amp; IPv6 handling for Adj-SIDs</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3368</link>
    <description>&lt;pre&gt;hi stefano,

i think i have spot a bug (well at least a problematic area)
in the current specification.

consider:
- a pair of routers connected by a ptp link:

    A.00-------B.00

- one of them (A.00) advertising an Adj-SID &amp;lt;N&amp;gt;
- MPLS data plane
- integrated IS-IS - (no MT) being deployed.

Q: what L2-forwarding action does A.00 program for &amp;lt;N&amp;gt; if:

  1. the link is IPv4 only enabled
  2. the link is IPv6 only enabled
  3. the link is both IPv4 and IPv6 enabled

i can imagine that the answer for 

  1. is POP -&amp;gt; MPLS (if BOS is not set)
        POP -&amp;gt; IPv4 (if BOS is set)
  2. is POP -&amp;gt; MPLS (if BOS is not set)
        POP -&amp;gt; IPv6 (if BOS is set)

i fail to come up with something working for 3. - can you ?

thanks,

/hannes
&lt;/pre&gt;</description>
    <dc:creator>Hannes Gredler</dc:creator>
    <dc:date>2013-04-25T12:03:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3367">
    <title>WG Last Call for draft-ietf-isis-rfc6326bis-01.txt</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3367</link>
    <description>&lt;pre&gt;Hi Folks,

We are starting a WG Last Call on the following draft.

Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS
draft-ietf-isis-rfc6326bis-01.txt

Thanks,
CHopps &amp;amp; DWard.
&lt;/pre&gt;</description>
    <dc:creator>Christian Hopps</dc:creator>
    <dc:date>2013-04-16T15:34:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3366">
    <title>I-D Action: draft-ietf-isis-rfc6326bis-01.txt</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3366</link>
    <description>&lt;pre&gt;
A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IS-IS for IP Internets Working Group of the IETF.

Title           : Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS
Author(s)       : Donald Eastlake
                          Tissa Senevirathne
                          Anoop Ghanwani
                          Dinesh Dutt
                          Ayan Banerjee
Filename        : draft-ietf-isis-rfc6326bis-01.txt
Pages           : 48
Date            : 2013-04-09

Abstract:
   The IETF TRILL (Transparent Interconnection of Lots of Links)
   protocol provides optimal pair-wise data frame forwarding without
   configuration in multi-hop networks with arbitrary topology and link
   technology, and support for multipathing of both unicast and
   multicast traffic. This document specifies the data formats and code
   points for the IS-IS extensions to support TRILL. These data formats
   and code points may also be used by tech&lt;/pre&gt;</description>
    <dc:creator>internet-drafts&lt; at &gt;ietf.org</dc:creator>
    <dc:date>2013-04-09T18:22:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3365">
    <title>draft-gredler-isis-label-advertisement</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3365</link>
    <description>&lt;pre&gt;dear isis-wg,

in orlando i have presented in RTGWG and MPLSWG use-cases for
IGP advertisment of MPLS labels.

   http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement

here is the draft outlining the actual protocol extensions for IS-IS

   http://tools.ietf.org/html/draft-gredler-isis-label-advertisement

would love to hear feedback, opinions, flames ;-)

thanks,

/hannes
&lt;/pre&gt;</description>
    <dc:creator>Hannes Gredler</dc:creator>
    <dc:date>2013-04-06T09:00:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3364">
    <title>Re: draft-previdi-filsfils-isis-segment-routing</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3364</link>
    <description>&lt;pre&gt;One additional point .. As just hinted offline by Sam when I said MTU I
assumed it is equal to MRU. If not we should discuss both values and it's
consequences on the packet size in this sort of source based segment chain
selection.

Cheers,
R.


On Tue, Apr 2, 2013 at 6:35 PM, Robert Raszuk &amp;lt;robert&amp;lt; at &amp;gt;raszuk.net&amp;gt; wrote:

_______________________________________________
Isis-wg mailing list
Isis-wg&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
&lt;/pre&gt;</description>
    <dc:creator>Robert Raszuk</dc:creator>
    <dc:date>2013-04-02T17:09:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.isis/3363">
    <title>Re: draft-previdi-filsfils-isis-segment-routing</title>
    <link>http://permalink.gmane.org/gmane.ietf.isis/3363</link>
    <description>&lt;pre&gt;Hi Stefano,

As we have discussed in the past I like the proposal a lot. Control plane
encoding seems fine as well.

My slight concern is however related to data plane. As you recall even with
label stack of 2 we have had number of issues when deploying L3VPNs with
MTU. The draft is very silent on the issue of potential MTU problems - I
would suggest new section to at least recommend some MTU handling (pMTU for
example) before applying this technique.

Likewise one could easily extend your signalling to add MTU on the links to
make sure that while going via all segments data plane packets will "fit".
Such extensions would in fact have more use cases, but I will let you
discover them :)

Also the empty section of IPv6 header encoding is a bit surprising yet
quite an interesting in the light of potential multiple v6 headers and MTU
issues.

Cheers,
R.
_______________________________________________
Isis-wg mailing list
Isis-wg&amp;lt; at &amp;gt;ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
&lt;/pre&gt;</description>
    <dc:creator>Robert Raszuk</dc:creator>
    <dc:date>2013-04-02T16:35:47</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.ietf.isis">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.ietf.isis</link>
  </textinput>
</rdf:RDF>
