Les, It is protocols which as used to construct and signal topologies. If I have two topologies where in your model of global SRGB do I allocate a block of A to one topo and block of B to the other ?
Now as to the "magic" part if I have global SRGB where do I allocate a block of it for one protocol/instance vs another ? Maybe this will clarify a lot and close this thread ... Best, R. On Tue, Aug 4, 2015 at 9:07 PM, Les Ginsberg (ginsberg) <[email protected]> wrote: > Robert – > > > > I fail to see the relevance of your comments. > > > > Yes – SR supports/requires different SIDs/topology. But topologies are NOT > protocol specific. The “base unicast topology” which is implied when we > talk outside the context of MT is the glaring example of that. > > > > As for “magic” – please point out one word or phrase in this entire > discussion (either by myself or Pushpasis) that has suggested that SRGBs > are defined in a way which is outside of the operator’s control. > > > > Les > > > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Robert > Raszuk > *Sent:* Tuesday, August 04, 2015 10:07 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* Pushpasis Sarkar; Hannes Gredler; [email protected]; > Aissaoui, Mustapha (Mustapha); [email protected]; Uma Chunduri; Shraddha > Hegde > > *Subject:* Re: [spring] Modeling SRGB configuration for > draft-ietf-spring-sr-yang > > > > Hi Les, > > > > Wouldn't you agree that for Multi-topology or Multi_Instance you already > need multiple SIDs ? > > > > Assuming that you support the above I find it a bit quite bizzare that you > are arguing for global SRGB rather then having this explicit under protocol > instance or topology. > > > > Keep in mind that systems that decide for the operator on what ranges > (from global SRGB) are advertised where in a magical way are not that > always that welcome :) > > > > Best, > > r. > > > > > > > > > > On Tue, Aug 4, 2015 at 6:05 PM, Les Ginsberg (ginsberg) < > [email protected]> wrote: > > Pushpasis - > > > -----Original Message----- > > From: Pushpasis Sarkar [mailto:[email protected]] > > Sent: Monday, August 03, 2015 11:40 PM > > To: Les Ginsberg (ginsberg); Hannes Gredler; > > [email protected] > > Cc: Uma Chunduri; Aissaoui, Mustapha (Mustapha); [email protected]; > > 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)" <[email protected]> > 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:[email protected]] > > >> Sent: Monday, August 03, 2015 3:14 AM > > >> To: Les Ginsberg (ginsberg); Hannes Gredler; > > >>[email protected] > > >> Cc: Uma Chunduri; Aissaoui, Mustapha (Mustapha); [email protected]; > > >>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)" <[email protected]> > > >>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 > [email protected] > https://www.ietf.org/mailman/listinfo/spring > > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
