Robert - From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk Sent: Tuesday, August 04, 2015 1:17 PM To: Les Ginsberg (ginsberg) Cc: Pushpasis Sarkar; Hannes Gredler; stephane.litkow...@orange.com; Aissaoui, Mustapha (Mustapha); spring@ietf.org; Uma Chunduri; Shraddha Hegde Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
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 ? [Les:] It is up to the vendor to define a config model. But there is no need for topology specific SRGBs – only SIDs specific to a given prefix/topology pair. One can imagine many possible config models. 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 ? [Les:] You don’t. SIDs are a property of the prefix – not the protocol advertising the prefix. IN this way only one incoming label is required/prefix in the forwarding plane. One SRGB is sufficient for all protocols. Please read my recent response to Pushpasis for further details. Les Maybe this will clarify a lot and close this thread ... Best, R. On Tue, Aug 4, 2015 at 9:07 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> 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: rras...@gmail.com<mailto:rras...@gmail.com> [mailto:rras...@gmail.com<mailto:rras...@gmail.com>] On Behalf Of Robert Raszuk Sent: Tuesday, August 04, 2015 10:07 AM To: Les Ginsberg (ginsberg) Cc: Pushpasis Sarkar; Hannes Gredler; stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>; Aissaoui, Mustapha (Mustapha); spring@ietf.org<mailto:spring@ietf.org>; 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) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote: Pushpasis - > -----Original Message----- > From: Pushpasis Sarkar > [mailto:psar...@juniper.net<mailto:psar...@juniper.net>] > Sent: Monday, August 03, 2015 11:40 PM > To: Les Ginsberg (ginsberg); Hannes Gredler; > stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> > Cc: Uma Chunduri; Aissaoui, Mustapha (Mustapha); > spring@ietf.org<mailto: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<mailto: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<http://2.2.2.2/32> is 10 (for example). But > >this SID has > >already been assigned to 1.1.1.1/32<http://1.1.1.1/32> in Network A. So when > >IS-IS > >advertises 2.2.2.2/32<http://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<http://1.1.1.1/32> 2.2.2.2/32<http://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<http://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<http://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<http://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<http://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<http://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<http://1.1.1.1/32>, Push 16010, Fwd to N1 > OSPF: Prefix: 2.2.2.2/32<http://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<mailto:psar...@juniper.net>] > >> Sent: Monday, August 03, 2015 3:14 AM > >> To: Les Ginsberg (ginsberg); Hannes Gredler; > >>stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> > >> Cc: Uma Chunduri; Aissaoui, Mustapha (Mustapha); > >> spring@ietf.org<mailto: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<mailto: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<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
