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 - 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. 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. 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. 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
