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 & Dave.
"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 & Dave.
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(Continue reading)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);
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(Continue reading)
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
_______________________________________________ Isis-wg mailing list Isis-wg <at> ietf.org https://www.ietf.org/mailman/listinfo/isis-wg
+ 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: > Yeah, this is quite like in BGP/VPLS. > > It's been discussed/suggested in SR, but at least to me it seems like additional complexity. 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. > I'm not against it at all personally, but I'd just like to understand why introduce this additional complexity. I like idea of global labels quite much, much like I like idea of global IP loopbacks. 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 ? > But if there is practical problem with them, I'm happy to root for this range+index solution. Right now I get feeling rationale is 'lets do it like this, because it's been like this before' and I think how it is like today was wrong decision to begin with. 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." -- --- > > On 25 April 2013 14:46, Hannes Gredler <hannes <at> juniper.net> wrote: > saku, et al, > > the main question is why do we need to have a need for a domain-wide > label allocation pool, if this can be avoided ? > > there are well known techniques where every router independently > advertises a label block and an ordinal for himself. > see http://tools.ietf.org/html/rfc4761 for a working example > of this. > > label-block advertisement would allow to create SPT labels for every > destination *without* the need for a domain-wide punch in the label space. > > see attached an example for this. > an SPT path to R7 is created here. > > /hannes > > <label-block-advertisement.jpg> > > On Apr 16, 2013, at 8:20 AM, Saku Ytti wrote: > >> On 16 April 2013 05:47, Hannes Gredler <hannes <at> juniper.net> wrote: >>> HG> domain-wide labels needs the ability from all *neighboring* potential >>> non-SR routers to *not* use a certain label range. so thats a pre-cursor. >> >> I'm probably confused but can someone open this bit up for me. >> >> As I see it, I would use my SRB(s) only towards SR capable node, all >> other nodes that I may want to reach I have to use [SRB MAGIC] stack? >> Conversely I would not signal to non-SR islands dynamically anything >> from my SRB. >> >> From non-SR POV, does it not look like happy coincidence that entire >> domain has allocated same set of local labels? >> >> I fully accept that label manager today has issue (as you can't tell >> it context from which to allocate, label_manager_register('sr', 1000, >> 10000)) but it does not look like hard to solve problem. >> >> >> >> -- >> ++ytti >> > > > > > -- > ++ytti
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 & DWard.
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/
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
Repeat. Added isis-wg list. Some error in the previous post.
-----Original Message-----
From: Iftekhar Hussain
Sent: Monday, March 25, 2013 10:54 AM
To: 'stefano previdi'
Cc: draft-previdi-filsfils-isis-segment-routing <at> tools.ietf.org; 'isis-wg <at> ietf.org.'
Subject: RE: draft-previdi-filsfils-isis-segment-routing
Thanks Stefano. Sorry I thought that the isis-wg list is copied. This time I have explicitly added isis-wg
list to the cc.
Please see few comments in-line.
-----Original Message-----
From: stefano previdi [mailto:sprevidi <at> cisco.com]
Sent: Monday, March 25, 2013 3:23 AM
To: Iftekhar Hussain
Cc: draft-previdi-filsfils-isis-segment-routing <at> tools.ietf.org
Subject: Re: draft-previdi-filsfils-isis-segment-routing
Hi Iftekhar,
thanks for you comments.
Note that you addressed your email only to the authors. Maybe, next time, let's also include the ISIS WG
mailing list.
See below some answers.
On Mar 23, 2013, at 12:25 AM, Iftekhar Hussain wrote:
> Hi Authors,
> Interesting work. Few clarification questions and comments:
> Section 1:
> a) "These segments act as topological sub-paths that can be combined together to form the desired path."
> So the advertising node would need to first find/compute these sub-paths before advertising the
segments? Does this mean a change to the existing IGP processing logic?
The IGP processing logic doesn't change. What we added on top of it is the ability of using paths that are in
fact an assembly of portion of different SPTs.
This is not substantially different fro what PCALC algorithm does today for RSVP-TE.
Obviously, the ISIS operations and algorithm does NOT change otherwise you won't be backward compatible.
SR is NOT disruptive.
In its default behavior, a SR capable router will just compute SPT and find that for each leaf of the SPT it has
a segment identifier (the Node-SID of the router advertising the leaf).
Now, think what you could do if you take portion of shortest paths (i.e.:
portion == segment) and combine them together. This doesn't impact at all ISIS SPF computation. It's a
decision the ingress router (or an SDN orchestration system) can take.
A----B----C----D----Z
\ /
\ /
X----Y
Example:
. Router A's shortest path to Z is: A-B-C-D-Z
. However, C has another path (not shortest) to Z: C-X-Y-Z
. Also, X's shortest path to Z is: X-Y-Z
. If router A wants to use shortest pat to C and then diverge
from shortest in C it can combine both and put the following
label stack: X, Z
. Label X will bring the packet along to SPT into X and label Z
will bring the packet to its final destination.
. Router A has combined two segments from two shortest paths:
. Path-1: A to X
. Path-2: X to Z
As you can see, router A has computed its normal topology (set of shortest paths) and picked up some segments
of them, combined them together in order to have an explicit path.
Again, from a path perspective is no different from PCALC. However, the big difference here is that, once
computed, the path requires NO signaling.
[Iftekhar] Thanks for the clarification. It is now much clear. Suppose a user (CLI or SDN) requests an
arbitrary explicit path (e.g., manually specifies a list of nodes to traverse) which diverges from all
available SPTs, what would be the expected behavior for an ingress LSR using SR (just trying to contrast it
with regular RSVP-TE)?
> b) "In Figure 1, all the nodes must be configured with the same Segment Routing Identifiers Block (called
SRB Node Registry)."
> Would there be periods during which segment numbers can collide? For example node A and B advertise the
same segment.
Node-SID values must be unique in the ISIS domain, same as ip addresses. By default, you need one Node-SID
per router (i.e.: not a big deal). We have defined dynamic/automatic mechanisms for ensuring the unicity
but most of operators (if not all of them) do not perceive the need to automate this process. Again, we're
talking about one Node-SID per box so it can be handled exactly in the same way IP address allocation is done today.
[Iftekhar] I guess what you mean is that through manual provisioning the operator would need to ensure that
each node has a unique Node-SID. It would be helpful to clarify this operational aspect in the draft.
> Section 2/2.1:
> c) "Segment Routing is applicable to the following use-cases: simplicity, TE, FRR and SDN"
> Does the segment-routing control plane also intended to address PW label distributions?
of course, you can use SR to distribute PW end-points. It's just another SID.
[Iftekhar] I think, it would be very useful to add this use case and the corresponding SR
operational/behavioral details.
> d) "An adjancey segment is instantiated as a crossconnect entry pointing to a specific egress".
> To me, a crossconnect implies an ingress to egress data path through a node. Can you provide an example of
the crossconnect in the MPLS data plane?
maybe "cross-connect" is not the best word...
We can say the Adj-SID determines a one-hop path from a router to one of its adjacent neighbors. Using the
Adj-SID on top of a packet will make you sure the packet is going from the node that advertised the Adj-SID up
to the adjacent neighbor represented by the Adj-SID value, no matter what the SPT and routing table says in
the node.
This allows you, if needed it, to support some form explicit paths. I intentionally say "some form of"
because most of the explicit path cases can be easily handled through Node-SID (without any Adj-SID).
However, Adj-SID is one more option in SR.
[Iftekhar] OK, I see. It would be good to add an example with the use of Adj-SID.
> e) "Node segments must be globally unique within the network domain".
> So the maximum allowable range in a network will be determined by the node with the minimum range?
yes.
> f) Do you plan to allow multiple disjoint ranges or just one range?
multiple.
> Section 2.2:
> g) "...A single node segment enumerates all the ECMP paths along the shortest-path".
> So in Fig 3, there would be single node segment A to M for all six paths?
yes. Think about how ISIS works. When you compute SPT the shortest path to a given leaf node is just one. Then,
when computing SPT algorithm and moving nodes from TENT to PATHS, you compute the set of adjacencies the
leaf node is reachable through. At this stage you populate your set of available next-hops.
Still, from a SPF algorithm perspective, you have computed shortest path to a leaf node.
This doesn't mean you lose control on which path you take of course.
Using Node-SIDs you may explicit state which of the ECMP members you want to use.
[Iftekhar] OK.
> h) "Alternatively, a three-label stack with adjacency segments FI, IK and KM could have been used".
> What is the maximum label stack depth needed in an arbitrary topology using this option?
Worst case scenario: as many labels you have adjacencies in the network.
But if you come to that, your network has a design flaw
In practice, you will use (most of the time and in most of the
topologies) explicit paths through concatenation of segments of shortest paths (see my example). This
substantially compresses the label stack depth.
> i) For the Fig 3 example, how does node A or other nodes determine (or build the label stack)? It is not clear
just based on segments how nodes infer/learn to instantiate correct label stack in the MPLS data plane?
ISIS SPF and explicit path computation. Exactly as it is done today in
MPLS:
. ISIS computes SPT
. You populate your RIB
. SR gives also the SID values for each leaf node . MPLS FIB is them populated with the SID values coming from ISIS
(rather than LDP).
For explicit routing, you will use PCALC the same as today. When your explicit path is computed, the ISIS
LSDB will also tell you which SID to use (i.e.: the label stack you have to push prior to send out the packet).
[Iftekhar] Now it is much clear. I assume no BW CAC as there is no explicit signaling of path unlike RSVP-TE?
> j) "The network does not hold any signaling state for the traffic engineered flows..."
> Won't there be some state for explicit routes somewhere?
no, that's the beauty of SR.
The statement is clear: no "signaling" state for the explicit paths.
This means that the router computing the explicit path will obviously keep knowledge (i.e.: state) of that
path but it will not signal it anywhere.
> Availability Implications: Any drawback of combining the IGP/MPLS control planes:
> = Now with MPLS and IP control planes combined, a failure will affect both IP and MPLS control planes?
It has been ALWAYS the case,m nothing new here. Before SR, at any failure, you need to wait for ISIS to
converge and then LDP has to figure out that it has to re-advertise or withdrawn labels, not to mention the
RSVP signaling storms that would happen during convergence.
Now, SR brings a substantial advantage: MPLS forwarding plane benefits from ISIS convergence
performance. This is WAY better than the interaction between LDP and ISIS.
Before SR, at any failure, you needed to wait for ISIS to converge and then LDP to figure out that it has to
re-advertise or withdrawn labels (not to mention the RSVP signaling storms that would happen during convergence).
With SR, everything is done inside ISIS convergence.
s.
[Iftekhar] OK. Suppose there is a SR control plane failure a remote node in a network, a given local node who
is using some SIDs its data plane, it will keep forwarding oblivious of that failure until its local SR
control plane decides to update/remove that entry?
>
> Thanks,
> Iftekhar
RSS Feed7 | |
|---|---|
18 | |
17 | |
61 | |
2 | |
3 | |
7 | |
16 | |
20 | |
11 | |
5 | |
3 | |
1 | |
7 | |
26 | |
1 | |
3 | |
2 | |
17 | |
8 | |
8 | |
11 | |
7 | |
14 | |
46 | |
16 | |
31 | |
55 | |
38 | |
32 | |
22 | |
137 | |
52 | |
13 | |
24 | |
46 | |
62 | |
48 | |
4 | |
3 | |
7 | |
4 | |
1 | |
11 | |
3 | |
1 | |
3 | |
2 | |
69 | |
27 | |
14 | |
14 | |
2 | |
5 | |
21 | |
5 | |
15 | |
21 | |
14 | |
3 | |
26 | |
22 | |
18 | |
3 | |
4 | |
22 | |
18 | |
8 | |
7 | |
3 | |
20 | |
7 | |
17 | |
22 | |
19 | |
8 | |
12 | |
11 | |
9 | |
3 | |
7 | |
14 | |
16 | |
4 | |
19 | |
11 | |
13 | |
4 | |
34 | |
14 | |
37 | |
27 | |
3 | |
11 | |
14 | |
26 | |
11 | |
34 | |
42 | |
22 | |
17 | |
16 | |
62 | |
16 | |
38 | |
26 | |
48 | |
28 | |
27 | |
7 | |
21 | |
7 | |
4 | |
1 | |
13 | |
6 | |
7 | |
67 | |
98 | |
71 | |
56 | |
12 | |
54 | |
70 | |
7 | |
54 | |
136 | |
128 | |
69 | |
118 | |
75 | |
90 | |
137 |
