<?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://blog.gmane.org/gmane.ietf.isis">
    <title>gmane.ietf.isis</title>
    <link>http://blog.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 suggested text changes
to improve the draft. - please help us to make it better ;-)

as a vehicle to foster open collaboration we are VCing our work in github.
feel free to clone the repository at:
https://github.com/hannesgredler/draft-gredler-isis-label-advertisement.git
send us pull requests with your suggested changes (or diffs using email);

thanks,

/hannes

Begin forwarded message:

&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 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 


We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 
http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of
http://sites.google.com/site/dumpconf for comments from well-known researchers 
about WORLDCOMP. 


The status of your WORLDCOMP papers can be changed from scientific
to other (i.e., junk or non-technical) at any time. Better not to have a paper than 
having it in WORLDCOMP and spoil the resume and peace of mind forever!


Our study revealed that WORLDCOMP is a money making business, 
using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing 
out a small chunk of that money (around 20 dollars per paper published 
in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) 
who publicizes WORLDCOMP and also defends it at various forums, using 
fake/anonymous names. The puppet uses fake names and defames other conferences
to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to 
threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). 
That is, the puppet does all his best to get a maximum number of papers published 
at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. 


Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has 
refused to provide the venue for WORLDCOMP’13 because of the fears of their image 
being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 
is taking place at a different resort. WORLDCOMP will not be held after 2013. 


The draft paper submission deadline is over but still there are no committee 
members, no reviewers, and there is no conference Chairman. The only contact 
details available on WORLDCOMP’s website is just an email address! 

Let us make a direct request to Prof. Hamid arabnia: publish all reviews for 
all the papers (after blocking identifiable details) since 2000 conference. Reveal 
the names and affiliations of all the reviewers (for each year) and how many 
papers each reviewer had reviewed on average. We also request him to look at 
the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 


Sorry for posting to multiple lists. Spreading the word is the only way to stop 
this bogus conference. Please forward this message to other mailing lists and people. 


We are shocked with Prof. Hamid Arabnia and his puppet’s activities 
http://worldcomp-fake-bogus.blogspot.com   Search Google using the 
keyword worldcomp fake for additional links.

_______________________________________________
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>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 either have a
1. per-node ordinal (and use IPv6 explicit null to disambiguate whats 
inside)

    so PHP would program:

    label N, BOS=1, POP-&amp;gt;IPv4
    label N, BOS=0, POP-&amp;gt;recurse
      2. allocate one ordinal per-AF / per-node.

    so PHP would program:

    label N1, BOS=1, POP-&amp;gt;IPv4
    label N2, BOS=1, POP-&amp;gt;IPv6

so whether you do 1) or 2) depends on you hardware cap., i know that not 
everybody
can do recursive lookups, so perhaps 2) is safer to use.
&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.

In Section 2.2 comparative study has been mentioned could your share
more details ?

 Also are there any plans to discuss segment routing in Berlin ?

Thanks Patryk Konczyk
&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 since then ?


may i ask you to go back to IETF60 meeting minutes:
http://www.ietf.org/proceedings/60/195.htm

scroll down to the following paragraph:

---
Source Routed MPLS LSP using Domain Wide Label 
draft-tian-mpls-lsp-source-route-01.txt, Albert Tian 

This draft introduces global labels as a means of source routing or loose source routing a packet in an MPLS network. If each destination of interest (say all of the loopback addresses used as router-IDs) had a label which was both globally known and globally used by all routers, then one could source route a packet by stacking up labels for each of the routers in the source route. This technique could be applied to fast reroute. 

In the ensuing discussion it was pointed out that the idea of global labels had been discussed in the early days of MPLS. At that time it was decided that labels would only have local significance (within the forwarding plane). Many workgroup members expressed opposition to such a fundamental change to the MPLS architecture. Alex Zinin stated, "The workgroup is done with architecture. Unless it can be proved that architecture is not sufficient then this doesn't fit in charter." --
---

&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 technologies other than TRILL.
   This document obsoletes RFC 6326.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-isis-rfc6326bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-isis-rfc6326bis-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-isis-rfc6326bis-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
&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>
