Pushpasis - > -----Original Message----- > From: Pushpasis Sarkar [mailto:psar...@juniper.net] > Sent: Monday, August 03, 2015 11:40 PM > To: Les Ginsberg (ginsberg); Hannes Gredler; > stephane.litkow...@orange.com > Cc: Uma Chunduri; Aissaoui, Mustapha (Mustapha); spring@ietf.org; > Shraddha Hegde > Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr- > yang > > Hi Les, > > I see that you have taken the network consolidation as the example :) Please > find some more comments inline.. > > Thanks > -Pushpasis > > On 8/3/15, 9:05 PM, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> wrote: > > >Pushpasis - > > > >Your descriptions are not accurately reflecting what is required. This > >isn't about multiple protocols contributing a next hop to the same > >route (which in itself is not normal behavior and can potentially cause > >loops) > >- nor is it about different protocols being the best route on different > >routers. > > > >Let's take a simple example: > > > >I have network A running IS-IS. It uses default SRGB (16000-23999) and > >has assigned SIDs (0-100) to the prefixes it is advertising. > > > >I have network B running OSPF. It also uses default SRGB (16000-23999) > >and has also assigned SIDs (0 - 100) to the prefixes it is advertising. > > > >To make things simple assume Network A and Network B have no IP > address > >/subnet conflicts. (If they do the conflicts would have to be resolved > >first.) > > > >Now you want to merge the two networks into one. And - at least at > >first > >- you don't want to have to migrate routing protocols in either network > >nor have to reassign SIDs for the existing prefixes. So, what do you do? > > > >You connect the two networks via one or more ABRs. On these ABRs you > >run an instance of both IS-IS and OSPF - enabled on the interfaces > >connected to Network A and Network B respectively. And you redistribute > >routes between the two protocols. But - you have a problem. The SID for > >Network B address 2.2.2.2/32 is 10 (for example). But this SID has > >already been assigned to 1.1.1.1/32 in Network A. So when IS-IS > >advertises 2.2.2.2/32 it cannot advertise SID 10 - > > [Pushpasis] Adding a diagram to illustrate the scenario you explained above.. > > |-----Network A(ISIS) SRGB:16000-23999------|-----Network B(OSPF) > SRGB:16000-23999-----| > > > SID:10 SID:10 > 1.1.1.1/32 2.2.2.2/32 > D1--------------------N1------ABR------N2---------------------D2 > > > In our proposal for handling network consolidation scenario, what Shraddha > and I proposed was to change the SRGB range for one of the networks > without needing to change the SID indexes. To understand why that is > needed, consider the MPLS transit routes on the ABR in the above example. > Following are MPLS transit routes applicable on ABR. > > ISIS: Incoming label 16010, Swap 16010, Fwd to N1, > OSPF: Incoming label 16010, Swap 16010, Fwd to N2 > > The above two are conflicting entries. In certain implementations, having two > route entries for the same incoming label is not even possible. > However if we change the SRGB on network B to 24000-31999, then we have > two different transit routes. > > ISIS: Incoming label 16010, Swap 16010, Fwd to N1 > OSPF: Incoming label 24010, Swap 24010, Fwd to N2 > > The above two entries can now easily co-exist in the FIB on ABR.
[Les:] I agree that in addition to what I described one of the SRGBs has to be changed. So, let's see what we are left with: The merge is done disruptively (because changing one of the SRGBs cannot be done hitlessly). For each of the prefixes which are advertised into both Network A and Network B we have: 1)Two different SIDs advertised 2)Two different labels installed in the forwarding plane 3)Two different SRGBs on a single node Does this work? Yes - with some implementation extensions that I have previously described. Is this easy to manage and troubleshoot? I will let others comment on that. But certainly it is not as easy to manage and troubleshoot as a network where for each prefix we have: 1 SID 1 label installed in the forwarding plane No SID mapping associated w redistribution 1 SRGB Possibly even the same SRGB on all nodes I have already acknowledged that if folks see the first alternative as useful then we should look at supporting it - but I think it is also important to note its complexity and insure that in order to handle this case that we do not abandon the much simpler use of a protocol independent SRGB. I hope we can agree on that. Les > > > >it has to advertise a different SID - let's say that it is 210. (There > >are various ways to assign that SID - we don't have to specify that > >here.) But since traffic for 2.2.2.2/32 will be arriving at the ABR > >from Network A routers with SID 210 there has to be an entry in the > >forwarding plane for both SID 210 and SID 10 that will forward the > >traffic to the interface specified by OSPF (which is the ONLY protocol > >installing a route in the RIB for 2.2.2.2/32 on the ABR). So not only > >does the forwarding plane have to support this - but the destination > >protocol for redistribution (IS-IS in this example) has to install the > >label associated w SID 210 NOT because it is installing a path into the > >RIB - but simply because it is advertising a redistributed route. > > [Pushpasis] I agree that when 2.2.2.2/32(SID 10) from network B is re- > advertised/re-distributed to network A, it needs to be assigned another > unique SID (210 in your example). Also, such advertisement will go with No- > PHP flag set (to 1). So when a source from network A tries to reach > 2.2.2.2/32 it will send the packet with the label 16210 (and not 16010). > And since SID 210 was advertised with No-PHP=1, the packet will reach ABR > with the label 16210. The same route entry should already have been > programmed on ABR as follows. > > ISIS: Incoming label 16210, Swap 24010, Fwd to N2 > > Similarly if 1.1.1.1/32(SID 10) from network A is re-advertised/re-distributed > to network B, it may be assigned another unique SID (say again 210). The > corresponding route entry on ABR should look like. > > OSPF: Incoming label 24210, Swap 16010, Fwd to N1 > > > Now coming to the IP-to-MPLS routes on ABR there should not be any > confusion, and they should look like.. > > ISIS: Prefix: 1.1.1.1/32, Push 16010, Fwd to N1 > OSPF: Prefix: 2.2.2.2/32, Push 24010, Fwd to N2 > > > > >Now, is all of this possible? Yes...but certainly is not a trivial > >issue to address. And, for the operators, they have the complication of > >having multiple SIDs, multiple labels, and possibly multiple SRGBs > >associated with a single prefix. > > > >Maybe all of this is still desirable i.e., the benefits of being able > >to merge two networks w/o having to address SID conflicts is worth it - > >that is a judgment call on which the operators need to provide some insight. > [Pushpasis] IMO, it is easier for the operator to change all the nodes in > network B(or A) to a different single SRGB range without much overhead. > > > > > > >I am willing to allow - as Acee's post from last week mentioned - that > >this might be a useful thing - but let's not make the mistake of > >treating this as a simple case - nor as the way that is most desirable > >to run networks. > [Pushpasis] I am fine with a instance-level SRGB range config knob as well. In > fact that is what I suggested in ISIS YANG design disucssion meeting few > months back. My suggestion was on the same lines as what Acee mentioned > in his mail (protocol-specific config overriding the instance-level one). > > > > > > > Les > > > >> -----Original Message----- > >> From: Pushpasis Sarkar [mailto:psar...@juniper.net] > >> Sent: Monday, August 03, 2015 3:14 AM > >> To: Les Ginsberg (ginsberg); Hannes Gredler; > >>stephane.litkow...@orange.com > >> Cc: Uma Chunduri; Aissaoui, Mustapha (Mustapha); spring@ietf.org; > >>Shraddha Hegde > >> Subject: Re: [spring] Modeling SRGB configuration for > >>draft-ietf-spring-sr- > >> yang > >> > >> Hi Les, > >> > >> On 8/1/15, 4:56 AM, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com> > >>wrote: > >> > >> >What is more problematic is supporting multiple labels for the same > >> >prefix - which is one of the consequences of the per-protocol SRGB > >> >approach. I am not saying this is unsupportable - just that it is a > >> >more difficult problem to solve. > >> [Pushpasis] If we can support multiple protocol routes (each > >>providing an IP next hop) per IP prefix, I don¹t see why there should > >>be problem supporting multiple protocol routes (each providing a > >>labeled next hop) for the same IP prefix. > >> > >> Thanks > >> -Pushpasis > >> > > > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
