Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Hi Acee De : Acee Lindem (acee) [mailto:a...@cisco.com] Envoyé : mercredi 12 août 2015 11:48 À : GUEDREZ Rabah IMT/OLN; Les Ginsberg (ginsberg); Pushpasis Sarkar; LITKOWSKI Stephane SCE/IBNF; Jeff Tantsura; spring@ietf.org Objet : Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Rabah, From: spring spring-boun...@ietf.orgmailto:spring-boun...@ietf.org on behalf of rabah.gued...@orange.commailto:rabah.gued...@orange.com rabah.gued...@orange.commailto:rabah.gued...@orange.com Date: Wednesday, August 12, 2015 at 4:09 AM To: Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com, Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net, Stephane Litkowski stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, Jeff Tantsura jeff.tants...@ericsson.commailto:jeff.tants...@ericsson.com, spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Les The discussion that you pointed out does not discuss the conflicting SRGB scenario that I explained, rather it is about the conflicting index ranges which is another problem. To clarify : 1) The Index range conflict result in having two IGP prefixes with same Index value. The SR YANG model configures the node-sids outside the IGPs - https://www.ietf.org/id/draft-ietf-spring-sr-yang-00.txt. If you advertise the same prefix in multiple protocols in the same topology, it should use the same index value. The case where you need to partition the SID space between protocols is the exception rather than the rule. [Rabah] I totally agree, but the Problem still exists, please refer to the discussion about that subject. 2)SRGB range overlapping problem happens only when we consider the scenario where a SPRING node runs two or more IGPs, and every IGP has its own SRGB, Unless you have completely separate routing domains with completely separate SID spaces, you’d want to use a consistent SRGB across protocols. [Rabah] will see what option the authors will go with : a single SRGB per node or per-protocol instance SRGB. I did raise the problem of per-protocol SRGBs overlapping, because Option 2 seems the one that got more support. Thanks, Acee PS As stephane one of the authors of SR-yang said the consensus is to adopt the per-protocol SRGB space option. Bests, RABAH. De : Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Envoyé : mardi 11 août 2015 20:48 À : Pushpasis Sarkar; GUEDREZ Rabah IMT/OLN; LITKOWSKI Stephane SCE/IBNF; Jeff Tantsura; spring@ietf.orgmailto:spring@ietf.org Objet : RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Pushpasis/Rabah – The conflicting SRGB range issue is neither new nor specific to protocol specific SRGBs. There is already a (somewhat lively) discussion going on about what to do w conflicting SRGB ranges when received (see attached email). IMO if you want to discuss this issue it would be better done in the context of the attached thread – not this one. Les From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Pushpasis Sarkar Sent: Tuesday, August 11, 2015 9:54 AM To: rabah.gued...@orange.commailto:rabah.gued...@orange.com; LITKOWSKI Stephane SCE/IBNF; Jeff Tantsura; spring@ietf.orgmailto:spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Rabah, Totally agree to your point. And that is why IMO, the configuration module on any router MUST NOT allow any of the per-protocol SRGBs to overlap. All the per-protcol SRGBs MUST be non-overlapping. Thanks -Pushpasis From: spring spring-boun...@ietf.orgmailto:spring-boun...@ietf.org on behalf of rabah.gued...@orange.commailto:rabah.gued...@orange.com rabah.gued...@orange.commailto:rabah.gued...@orange.com Date: Tuesday, August 11, 2015 at 8:00 PM To: LITKOWSKI Stephane SCE/IBNF stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, Jeff Tantsura jeff.tants...@ericsson.commailto:jeff.tants...@ericsson.com, spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang I strongly support option #2 but a Problem may occur in that case, if the per-protocol SRGBs share a subSpace. so let us consider the following example where node N is a SPRING node with two SR-IGP instances SR-OSPF and SR-ISIS running, if we configure OSPF-SRGB [8000, 1] and ISIS-SRGB [9000, 11000]. actually accepting this configuration may result in the same label for two IGP prefixes (EX : OSPF-Prefix-index 1001 and ISIS-prefix-index 1 will have the label 9001) which get translated into two entries in the forwarding table. to solve that I suggest to add a new notification of type let's say “SRGB-collusion-detected “ which will be raised upon the detection of the SRGBs collusion Rabah De : spring [mailto:spring-boun
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Hi Rabah, From: spring spring-boun...@ietf.orgmailto:spring-boun...@ietf.org on behalf of rabah.gued...@orange.commailto:rabah.gued...@orange.com rabah.gued...@orange.commailto:rabah.gued...@orange.com Date: Wednesday, August 12, 2015 at 4:09 AM To: Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com, Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net, Stephane Litkowski stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, Jeff Tantsura jeff.tants...@ericsson.commailto:jeff.tants...@ericsson.com, spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Les The discussion that you pointed out does not discuss the conflicting SRGB scenario that I explained, rather it is about the conflicting index ranges which is another problem. To clarify : 1) The Index range conflict result in having two IGP prefixes with same Index value. The SR YANG model configures the node-sids outside the IGPs - https://www.ietf.org/id/draft-ietf-spring-sr-yang-00.txt. If you advertise the same prefix in multiple protocols in the same topology, it should use the same index value. The case where you need to partition the SID space between protocols is the exception rather than the rule. 2)SRGB range overlapping problem happens only when we consider the scenario where a SPRING node runs two or more IGPs, and every IGP has its own SRGB, Unless you have completely separate routing domains with completely separate SID spaces, you’d want to use a consistent SRGB across protocols. Thanks, Acee PS As stephane one of the authors of SR-yang said the consensus is to adopt the per-protocol SRGB space option. Bests, RABAH. De : Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Envoyé : mardi 11 août 2015 20:48 À : Pushpasis Sarkar; GUEDREZ Rabah IMT/OLN; LITKOWSKI Stephane SCE/IBNF; Jeff Tantsura; spring@ietf.orgmailto:spring@ietf.org Objet : RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Pushpasis/Rabah – The conflicting SRGB range issue is neither new nor specific to protocol specific SRGBs. There is already a (somewhat lively) discussion going on about what to do w conflicting SRGB ranges when received (see attached email). IMO if you want to discuss this issue it would be better done in the context of the attached thread – not this one. Les From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Pushpasis Sarkar Sent: Tuesday, August 11, 2015 9:54 AM To: rabah.gued...@orange.commailto:rabah.gued...@orange.com; LITKOWSKI Stephane SCE/IBNF; Jeff Tantsura; spring@ietf.orgmailto:spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Rabah, Totally agree to your point. And that is why IMO, the configuration module on any router MUST NOT allow any of the per-protocol SRGBs to overlap. All the per-protcol SRGBs MUST be non-overlapping. Thanks -Pushpasis From: spring spring-boun...@ietf.orgmailto:spring-boun...@ietf.org on behalf of rabah.gued...@orange.commailto:rabah.gued...@orange.com rabah.gued...@orange.commailto:rabah.gued...@orange.com Date: Tuesday, August 11, 2015 at 8:00 PM To: LITKOWSKI Stephane SCE/IBNF stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, Jeff Tantsura jeff.tants...@ericsson.commailto:jeff.tants...@ericsson.com, spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang I strongly support option #2 but a Problem may occur in that case, if the per-protocol SRGBs share a subSpace. so let us consider the following example where node N is a SPRING node with two SR-IGP instances SR-OSPF and SR-ISIS running, if we configure OSPF-SRGB [8000, 1] and ISIS-SRGB [9000, 11000]. actually accepting this configuration may result in the same label for two IGP prefixes (EX : OSPF-Prefix-index 1001 and ISIS-prefix-index 1 will have the label 9001) which get translated into two entries in the forwarding table. to solve that I suggest to add a new notification of type let's say “SRGB-collusion-detected “ which will be raised upon the detection of the SRGBs collusion Rabah De : spring [mailto:spring-boun...@ietf.org] De la part de stephane.litkow...@orange.commailto:stephane.litkow...@orange.com Envoyé : vendredi 31 juillet 2015 10:52 À : Jeff Tantsura; spring@ietf.orgmailto:spring@ietf.org Objet : Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Looks that consensus is for option#2, so let’s move SRGB to protocol configuration. From: Jeff Tantsura [mailto:jeff.tants...@ericsson.com] Sent: Friday, July 31, 2015 08:04 To: LITKOWSKI Stephane SCE/IBNF; spring@ietf.orgmailto:spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi, Architecturally I agree – label manager shouldn’t
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
hi les, On Fri, Jul 31, 2015 at 11:26:56PM +, Les Ginsberg (ginsberg) wrote: | Hannes - | | As a datapoint, we are able to successfully manage a reserved label space among multiple SR clients. | | As regards GR I am not sure why you think SR introduces new requirements. If your forwarding plane is to be persistent (NSF) then the router has to have a way of supporting label persistence across control plane restarts. In this context SR clients should be making use of whatever infrastructure already exists to support label persistence. What do you think is new here? in the pre-SR days upon graceful restart the routing system was re-reading the forwarding table and could derive from pre-incaranation meta-information which protocol owned this label before and suggest to the new-incranation protocol to re-use that label. in most implementations i have seen that mapping of label2protocol was a 1:1 and not 1:N mapping. of course 1:N mapping *can* be done, but you may loose some of the goodies of SR which is to re-use the existing MPLS eco-system. changing the scheme from 1:1 to 1:N has for certain ISSU/NSR implications. mandating a single SRGB to rule them all, reminds me a bit to the early SR debates where we've figured out that a single global SRGB is desirable but practically not doable due to the various local label-allocations behaviors. the analogy here is that we're about to change a 15 year old paradigm which is that labels are not reused across protocols. i am not saying it can not be done, i am just saying that there is a cost to it that not everybody is willing to bear. its cool that your implementation can obviously do 1:N mapping, but no harm is being done to your implementation if we keep the exisiting 1:1 paradigm and go ahead with one SRGB per protocol. /hannes | 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. I would be interested in other implementation experience on this point. | |Les | | | -Original Message- | From: Hannes Gredler (han...@juniper.net) [mailto:han...@juniper.net] | Sent: Friday, July 31, 2015 7:02 AM | To: stephane.litkow...@orange.com | Cc: Les Ginsberg (ginsberg); Uma Chunduri; Aissaoui, Mustapha (Mustapha); | spring@ietf.org; Shraddha Hegde (shrad...@juniper.net); Pushpasis Sarkar | (psar...@juniper.net) | Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr- | yang | | one further point is that implementations MAY reuse exisiting MPLS label- | managing software for SR. label-management software has often this label- | per-client (singular) and not-label-per-clients (plural) bookkeeping in the | sense that it cannot track multiple 'owners' of a certain label value. | | it would be interesting to hear from other implementers if their software can | easily track 'multiple client' ownership per label (and if not) what are the | implications to non-SR code-paths e.g. graceful restart scenarios ? | | /hannes | | On Thu, Jul 30, 2015 at 01:18:43PM +, stephane.litkow...@orange.com | wrote: | |As mentioned by others, there may be some operational gain. | | | |IGP migration example given is a good example, today with pure IP, | there's | |some tricky cases because we need to manage it with admin distance and | |their may be some differences in best path computation between IGPs | |(implementation dependant, but it's a reality). | | | |Here we have the opportunity to overcome this issue by letting the | |possibility to create two parallel forwarding planes using different | |labels. I agree that it consumes twice the number of required label, but | |it may be a transient solution (for migration case) and also it's a design | |choice of the operator. | | | |The last comment from Robert of virtualization , especially using | |containers or part of router OS running on COTS (just OSPF or ISIS or BGP | |code), may require some more independency between router software | |components. | | | | | | | | | | | |Now from an architectural perspective, what is Segment Routing ? | | | |Segment routing is just an architecture, like MPLS is. We see that segment | |routing has more and more controlplanes (ISIS and OSPF first, now BGP | |...), like MPLS does. Moreover using segment routing in an MPLS | |environment leads to adding new controlplanes to MPLS. | | | |So I like the comment from Pushpasis talking about BGP, LDP, RSVP which | |are different controlplane of MPLS. Do we advertise the same label value | |for the same prefix FEC advertised in LDP, BGP and RSVP ? No ... so why | |doing it with OSPF and ISIS ? | | | | | | | | | | | |From: Les Ginsberg (ginsberg) [mailto:ginsb
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
I strongly support option #2 but a Problem may occur in that case, if the per-protocol SRGBs share a subSpace. so let us consider the following example where node N is a SPRING node with two SR-IGP instances SR-OSPF and SR-ISIS running, if we configure OSPF-SRGB [8000, 1] and ISIS-SRGB [9000, 11000]. actually accepting this configuration may result in the same label for two IGP prefixes (EX : OSPF-Prefix-index 1001 and ISIS-prefix-index 1 will have the label 9001) which get translated into two entries in the forwarding table. to solve that I suggest to add a new notification of type let's say SRGB-collusion-detected which will be raised upon the detection of the SRGBs collusion Rabah De : spring [mailto:spring-boun...@ietf.org] De la part de stephane.litkow...@orange.com Envoyé : vendredi 31 juillet 2015 10:52 À : Jeff Tantsura; spring@ietf.org Objet : Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Looks that consensus is for option#2, so let's move SRGB to protocol configuration. From: Jeff Tantsura [mailto:jeff.tants...@ericsson.com] Sent: Friday, July 31, 2015 08:04 To: LITKOWSKI Stephane SCE/IBNF; spring@ietf.orgmailto:spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi, Architecturally I agree - label manager shouldn't care less how labels have been learnt Operationally I'm strongly for #2, in case of ISIS possibly under AF. Cheers, Jeff From: spring spring-boun...@ietf.orgmailto:spring-boun...@ietf.org on behalf of Stephane Litkowski stephane.litkow...@orange.commailto:stephane.litkow...@orange.com Date: Wednesday, July 22, 2015 at 7:19 PM To: spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is configured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label range shared between protocols could lead to. During discussion in our design team, some point was also raised on routing protocol migrations that may be safer using a per protocol SRGB (so configuration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for both approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol manages its own label space. Thanks to provide your feedback in order to solve this issue and have a consensus. [Orange logo]http://www.orange.com/ Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20 mobile: +33 6 37 86 97 52 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20 stephane.litkow...@orange.commailto:stephane.litkow...@orange.com _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
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.commailto: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.commailto:rras...@gmail.com [mailto:rras...@gmail.commailto: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.commailto:stephane.litkow...@orange.com; Aissaoui, Mustapha (Mustapha); spring@ietf.orgmailto: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.commailto:ginsb...@cisco.com wrote: Pushpasis - -Original Message- From: Pushpasis Sarkar [mailto:psar...@juniper.netmailto:psar...@juniper.net] Sent: Monday, August 03, 2015 11:40 PM To: Les Ginsberg (ginsberg); Hannes Gredler; stephane.litkow...@orange.commailto:stephane.litkow...@orange.com Cc: Uma Chunduri; Aissaoui, Mustapha (Mustapha); spring@ietf.orgmailto: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.commailto: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/32http://2.2.2.2/32 is 10
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
One SRGB is sufficient for all protocols. FWIW – I agree with most of the folks supporting per protocol SRGB in this thread and the same should be represented in the Yang model at least as a feature (the point of this thread). For operational reasons it’s always good to have per protocols, per instance, per MT (AF), and per algorithm SRGBs (with the capability to add additional ranges based on the need). Some of the issues if we don’t do this are clearly highlighted in the per algorithm SRGB draft recently presented. -- Uma C. From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Tuesday, August 04, 2015 2:50 PM To: Robert Raszuk 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 Robert - From: rras...@gmail.commailto: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.commailto:stephane.litkow...@orange.com; Aissaoui, Mustapha (Mustapha); spring@ietf.orgmailto: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.commailto: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.commailto:rras...@gmail.com [mailto:rras...@gmail.commailto: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.commailto:stephane.litkow...@orange.com; Aissaoui, Mustapha (Mustapha); spring@ietf.orgmailto: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.commailto:ginsb...@cisco.com wrote: Pushpasis - -Original Message- From: Pushpasis Sarkar [mailto:psar...@juniper.netmailto:psar...@juniper.net] Sent: Monday, August 03, 2015 11:40 PM To: Les Ginsberg (ginsberg); Hannes Gredler; stephane.litkow...@orange.commailto:stephane.litkow...@orange.com Cc: Uma Chunduri; Aissaoui, Mustapha (Mustapha); spring@ietf.orgmailto: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.commailto: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
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 wrote: 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:10SID:10 1.1.1.1/322.2.2.2/32 D1N1--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
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
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] 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; Aissaoui, Mustapha (Mustapha); 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.commailto:ginsb...@cisco.com wrote: Pushpasis - -Original Message- From: Pushpasis Sarkar [mailto:psar...@juniper.netmailto:psar...@juniper.net] Sent: Monday, August 03, 2015 11:40 PM To: Les Ginsberg (ginsberg); Hannes Gredler; stephane.litkow...@orange.commailto:stephane.litkow...@orange.com Cc: Uma Chunduri; Aissaoui, Mustapha (Mustapha); spring@ietf.orgmailto: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.commailto: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/32http://2.2.2.2/32 is 10 (for example). But this SID has already been assigned to 1.1.1.1/32http://1.1.1.1/32 in Network A. So when IS-IS advertises 2.2.2.2/32http://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:10SID:10 1.1.1.1/32http://1.1.1.1/322.2.2.2/32http://2.2.2.2/32 D1N1--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
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Robert – Labels are a shared resource – the problem you mention below has to be addressed independent of how many SRGBs are used in any solution. No protocol implementation – whether part of a monolithic router product or an independent implementation – can assume that it has free rein to use whatever SRGB range it wants. Les From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk Sent: Thursday, July 30, 2015 2:19 AM To: Les Ginsberg (ginsberg) Cc: Pushpasis Sarkar; stephane.litkow...@orange.com; spring@ietf.org; Shraddha Hegde; Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Les, One additional point ... Assume I am using a virtual router with BGP module from vendor A and OSPF module from vendor B. Assume the traditinal monolithic physical or virtual router is not being used. Who and where would implement this notion of global SRGB concept ? How would it talk to protocols ? Why do I need to pay now for this from perhaps yet one more vendor ? As long as I have SR control plane contained within protocols and have each of them feeding dataplane (directly or via RIB) I should be fine. So I am not sure why do I need yet one more umbrella SR coordinator subsystem Best, Robert. On Thu, Jul 30, 2015 at 9:46 AM, Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com wrote: Pushpassis – It is clear to me that what you propose is more complex to implement and more costly in its consumption of labels. What I do not yet appreciate is what capabilities protocol specific SRGBs provide which cannot be supported using a protocol independent SRGB. Could you please provide some specific examples? Please do not use an RSVP/LDP analogy – please use a proposed SR deployment case. BTW, why do I say your proposal is more complex/costly? On a node where redistribution of routes is occurring, the source of redistribution (the “best route”) obviously allocates a local label based on its SRGB. But now the destination protocol for redistribution also has to allocate a local label based on its SRGB because it is expected that neighbors of the destination protocol will use a label from the destination protocol SRGB. So, you now have new requirements on the destination protocol and you have consumed twice as many local labels. Your forwarding plane now has to deal with the added complexity/cost – and your label manager has to manage more label ranges. What I want to know is what do we gain for this added complexity? Thanx. Les From: Pushpasis Sarkar [mailto:psar...@juniper.netmailto:psar...@juniper.net] Sent: Wednesday, July 29, 2015 11:16 PM To: Les Ginsberg (ginsberg); stephane.litkow...@orange.commailto:stephane.litkow...@orange.com; Uma Chunduri; Aissaoui, Mustapha (Mustapha); spring@ietf.orgmailto:spring@ietf.org; Shraddha Hegde; Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Les, From: Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com Date: Wednesday, July 29, 2015 at 11:01 PM To: stephane.litkow...@orange.commailto:stephane.litkow...@orange.com stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, Uma Chunduri uma.chund...@ericsson.commailto:uma.chund...@ericsson.com, Aissaoui, Mustapha (Mustapha) mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com, spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org, Shraddha Hegde shrad...@juniper.netmailto:shrad...@juniper.net, Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net, Hannes Gredler han...@juniper.netmailto:han...@juniper.net Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Stephane – What is the requirement to have a per-protocol SRGB config? This makes no sense to me operationally or architecturally. [Pushpasis] In current MPLS architecture, the same label is not allocated by both RSVP and LDP in a given box. With SR mapped to MPLS data-plane, we would like to retain the same behavior. For the same destination the label allocated by ISIS should be different than the label allocated by OSPF. This can be achieved in two ways: 1. ISIS and OSPF using same SRGBs but different index ranges. 2. ISIS and OSPF using different SRGBs but can have the same index ranges. I prefer option 2, as the operator does not need to maintain two different index ranges (one per-protocol). (I am not talking about what may or may not have been implemented by vendors – the YANG model should be architecturally correct) Les From: stephane.litkow...@orange.commailto:stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com] Sent: Wednesday, July 29, 2015 5:11 AM To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); spring@ietf.orgmailto:spring@ietf.org; Shraddha Hegde (shrad...@juniper.netmailto:shrad...@juniper.net); Pushpasis
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Looks that consensus is for option#2, so let's move SRGB to protocol configuration. From: Jeff Tantsura [mailto:jeff.tants...@ericsson.com] Sent: Friday, July 31, 2015 08:04 To: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi, Architecturally I agree - label manager shouldn't care less how labels have been learnt Operationally I'm strongly for #2, in case of ISIS possibly under AF. Cheers, Jeff From: spring spring-boun...@ietf.orgmailto:spring-boun...@ietf.org on behalf of Stephane Litkowski stephane.litkow...@orange.commailto:stephane.litkow...@orange.com Date: Wednesday, July 22, 2015 at 7:19 PM To: spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is configured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label range shared between protocols could lead to. During discussion in our design team, some point was also raised on routing protocol migrations that may be safer using a per protocol SRGB (so configuration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for both approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol manages its own label space. Thanks to provide your feedback in order to solve this issue and have a consensus. [Orange logo]http://www.orange.com/ Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20 mobile: +33 6 37 86 97 52 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20 stephane.litkow...@orange.commailto:stephane.litkow...@orange.com _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Hi Pushpasis, On Jul 30, 2015, at 2:22 AM, Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net wrote: HI Acee, From: Acee Lindem (acee) a...@cisco.commailto:a...@cisco.com Date: Thursday, July 30, 2015 at 2:03 AM To: Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com Cc: Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net, Stephane Litkowski stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org, Shraddha Hegde shrad...@juniper.netmailto:shrad...@juniper.net, Uma Chunduri uma.chund...@ericsson.commailto:uma.chund...@ericsson.com, Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net, Aissaoui, Mustapha (Mustapha) mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com, Hannes Gredler han...@juniper.netmailto:han...@juniper.net Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang On Jul 29, 2015, at 6:28 PM, Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com wrote: Robert - From: rras...@gmail.commailto:rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk Sent: Wednesday, July 29, 2015 2:45 PM To: Les Ginsberg (ginsberg) Cc: stephane.litkow...@orange.commailto:stephane.litkow...@orange.com; Uma Chunduri; Aissaoui, Mustapha (Mustapha); spring@ietf.orgmailto:spring@ietf.org; Shraddha Hegde (shrad...@juniper.netmailto:shrad...@juniper.net); Pushpasis Sarkar (psar...@juniper.netmailto:psar...@juniper.net); Hannes Gredler (han...@juniper.netmailto:han...@juniper.net) Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Les, This makes no sense to me operationally or architecturally. Fundamentally I fully agree with you. However architecturally: However at least looking at group of folks who claim that it is impossible to get same SRGB block in *any* network between two or more vendors I think Stephane's intention would be to at least get it per one protocol even if platform wide the intersecting pool may be mission impossible. [Les:] This is an unrelated issue. Placing SRGB in global context does not mean all routers have to have the same SRGB. There is no controversy here. and now operationally: Another reason would be idea of dual overlapping SRGBs perhaps quite useful during migrations between protocols where the exact same SRGB is set on both then just based on admin distance one vs the other protocol is chosen. While a standard practice in protocol migrations not sure if anyone looked at that from SR perspective. [Les:] Not sure what you are trying to say. If the two SRGBs are the same – why do we need to configure them per protocol? If the two SRGBs are not the same, other routers in the network have no idea which protocol is going to win on your box. So your neighbor has no idea whether it should use the SRGB advertised by OSPF or the SRGB advertised by IS-IS. Actually, if the same prefix in the same topology is advertised by two protocols, I would think that the SID should map to the same label. I see no advantage at all in having separate labels. [Pushpasis] We are talking about the MPLS transit label for the destination FEC here. Like RSVP and LDP, in MPLS data plane today, the FEC maybe same but the transit label allocated by each protocol are different. This is not a good analogy. LDP normally follows the IP routed path while RSVP is used to set up a TE engineered path. Similarly for SR mapped to MPLS data plane the transit label allocated by ISIS and OSPF for the same destination FEC should be different. Hence the need of per-protocol SRGB. This is a circular argument. Why would the IP unicast routed path require a different label for ISIS vs OSPF? Acee Acee Les Cheers, R. On Wed, Jul 29, 2015 at 11:01 PM, Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com wrote: Stephane – What is the requirement to have a per-protocol SRGB config? This makes no sense to me operationally or architecturally. (I am not talking about what may or may not have been implemented by vendors – the YANG model should be architecturally correct) Les ___ spring mailing list spring@ietf.orgmailto:spring@ietf.org https://www.ietf.org/mailman/listinfo/spring ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Hi Acee, From: Acee Lindem (acee) a...@cisco.commailto:a...@cisco.com Date: Thursday, July 30, 2015 at 8:37 PM To: Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net Cc: Shraddha Hegde shrad...@juniper.netmailto:shrad...@juniper.net, Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com, Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net, Aissaoui, Mustapha (Mustapha) mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com, Stephane Litkowski stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org, Uma Chunduri uma.chund...@ericsson.commailto:uma.chund...@ericsson.com, Hannes Gredler han...@juniper.netmailto:han...@juniper.net Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Pushpasis, On Jul 30, 2015, at 10:54 AM, Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net wrote: Hi Acee, From: Acee Lindem (acee) a...@cisco.commailto:a...@cisco.com Date: Thursday, July 30, 2015 at 7:18 PM To: Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net Cc: Shraddha Hegde shrad...@juniper.netmailto:shrad...@juniper.net, Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com, Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net, Aissaoui, Mustapha (Mustapha) mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com, Stephane Litkowski stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org, Uma Chunduri uma.chund...@ericsson.commailto:uma.chund...@ericsson.com, Hannes Gredler han...@juniper.netmailto:han...@juniper.net Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Robert, Pushpasis, Shraddha, I guess I don't understand why this gives you any operational advantage when you are migrating between protocol (e.g., from IS-IS to OSPF ;^). In fact, if you are using separate label spaces it will make migration more difficult and you will have to migrate your routing domain in shot rather than incrementally. [Pushpasis] All routers will program both transit mpls labels and create two parallel MPLS data planes well before the last step when all the ingress router will be instructed to switch traffic onto the new MPLS data plane (programmed by the new protocol) by changing the admin distance. That way the migration shall become seamless. And then once all ingreess routers has been swicthed to the new protocol and new MPLS dataplane, the old protocol and old MPLS data plane can be just removed from all the routers. Hope it is clear now... Normally only the protocol with the lower preference or admin distance would install a route to a particular prefix (including the label) into the RIB/LIB for the base IP unicast topology. I guess you are envisioning separate RIBs per protocol as well? [Pushpasis] What you are saying is true for the IP/V6-MPLS route in RIB/FIB on ingress routers. It is NOT TRUE for MPLS transit routes in LFIB. In MPLS architecture no two protocols installs the same label in LFIB. Each protocol (LDP/RSVP) uses different transit labels for the same destination IP/V6 FEC. Thanks, Acee Thanks, Acee On Jul 30, 2015, at 3:11 AM, Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net wrote: +1 From: Shraddha Hegde shrad...@juniper.netmailto:shrad...@juniper.net Date: Thursday, July 30, 2015 at 8:58 AM To: Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com, Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net Cc: stephane.litkow...@orange.commailto:stephane.litkow...@orange.com stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, Uma Chunduri uma.chund...@ericsson.commailto:uma.chund...@ericsson.com, Aissaoui, Mustapha (Mustapha) mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com, spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org, Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net, Hannes Gredler han...@juniper.netmailto:han...@juniper.net Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang [Shraddha] route preference is local to router and the neighbor never knows what the other is going to choose. If there are inconsistencies in two protocols, there are going to be loops even when they use same SRGB. Keeping different labels makes it easier to troubleshoot. ___ spring mailing list spring@ietf.orgmailto:spring@ietf.org https://www.ietf.org/mailman/listinfo/spring ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Hi Acee, From: Acee Lindem (acee) a...@cisco.commailto:a...@cisco.com Date: Thursday, July 30, 2015 at 7:18 PM To: Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net Cc: Shraddha Hegde shrad...@juniper.netmailto:shrad...@juniper.net, Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com, Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net, Aissaoui, Mustapha (Mustapha) mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com, Stephane Litkowski stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org, Uma Chunduri uma.chund...@ericsson.commailto:uma.chund...@ericsson.com, Hannes Gredler han...@juniper.netmailto:han...@juniper.net Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Robert, Pushpasis, Shraddha, I guess I don't understand why this gives you any operational advantage when you are migrating between protocol (e.g., from IS-IS to OSPF ;^). In fact, if you are using separate label spaces it will make migration more difficult and you will have to migrate your routing domain in shot rather than incrementally. [Pushpasis] All routers will program both transit mpls labels and create two parallel MPLS data planes well before the last step when all the ingress router will be instructed to switch traffic onto the new MPLS data plane (programmed by the new protocol) by changing the admin distance. That way the migration shall become seamless. And then once all ingreess routers has been swicthed to the new protocol and new MPLS dataplane, the old protocol and old MPLS data plane can be just removed from all the routers. Hope it is clear now... Thanks, Acee On Jul 30, 2015, at 3:11 AM, Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net wrote: +1 From: Shraddha Hegde shrad...@juniper.netmailto:shrad...@juniper.net Date: Thursday, July 30, 2015 at 8:58 AM To: Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com, Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net Cc: stephane.litkow...@orange.commailto:stephane.litkow...@orange.com stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, Uma Chunduri uma.chund...@ericsson.commailto:uma.chund...@ericsson.com, Aissaoui, Mustapha (Mustapha) mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com, spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org, Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net, Hannes Gredler han...@juniper.netmailto:han...@juniper.net Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang [Shraddha] route preference is local to router and the neighbor never knows what the other is going to choose. If there are inconsistencies in two protocols, there are going to be loops even when they use same SRGB. Keeping different labels makes it easier to troubleshoot. ___ spring mailing list spring@ietf.orgmailto:spring@ietf.org https://www.ietf.org/mailman/listinfo/spring ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
My strong preference is Option 2. It simplifies migration and network consolidation usecases. Also it is very relevant in MSDC kind of use cases where a single node can be part of two different topologies running two different SR protocol. Index-management becomes much easier in each of the usecases. From: spring spring-boun...@ietf.orgmailto:spring-boun...@ietf.org on behalf of stephane.litkow...@orange.commailto:stephane.litkow...@orange.com stephane.litkow...@orange.commailto:stephane.litkow...@orange.com Date: Wednesday, July 22, 2015 at 10:49 PM To: spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is configured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label range shared between protocols could lead to. During discussion in our design team, some point was also raised on routing protocol migrations that may be safer using a per protocol SRGB (so configuration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for both approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol manages its own label space. Thanks to provide your feedback in order to solve this issue and have a consensus. [Orange logo]http://www.orange.com/ Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20 mobile: +33 6 37 86 97 52 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20 stephane.litkow...@orange.commailto:stephane.litkow...@orange.com _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
I tend to agree that proposal 2 is for migration, so would vote for option 2. From: spring on behalf of Pushpasis Sarkar Date: Friday 31 July 2015 07:37 To: Stephane Litkowski, spring@ietf.orgmailto:spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang My strong preference is Option 2. It simplifies migration and network consolidation usecases. Also it is very relevant in MSDC kind of use cases where a single node can be part of two different topologies running two different SR protocol. Index-management becomes much easier in each of the usecases. From: spring spring-boun...@ietf.orgmailto:spring-boun...@ietf.org on behalf of stephane.litkow...@orange.commailto:stephane.litkow...@orange.com stephane.litkow...@orange.commailto:stephane.litkow...@orange.com Date: Wednesday, July 22, 2015 at 10:49 PM To: spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is configured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label range shared between protocols could lead to. During discussion in our design team, some point was also raised on routing protocol migrations that may be safer using a per protocol SRGB (so configuration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for both approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol manages its own label space. Thanks to provide your feedback in order to solve this issue and have a consensus. [Orange logo]http://www.orange.com/ Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20 mobile: +33 6 37 86 97 52 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20 stephane.litkow...@orange.commailto:stephane.litkow...@orange.com _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Hi Les, From: Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com Date: Wednesday, July 29, 2015 at 11:01 PM To: stephane.litkow...@orange.commailto:stephane.litkow...@orange.com stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, Uma Chunduri uma.chund...@ericsson.commailto:uma.chund...@ericsson.com, Aissaoui, Mustapha (Mustapha) mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com, spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org, Shraddha Hegde shrad...@juniper.netmailto:shrad...@juniper.net, Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net, Hannes Gredler han...@juniper.netmailto:han...@juniper.net Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Stephane - What is the requirement to have a per-protocol SRGB config? This makes no sense to me operationally or architecturally. [Pushpasis] In current MPLS architecture, the same label is not allocated by both RSVP and LDP in a given box. With SR mapped to MPLS data-plane, we would like to retain the same behavior. For the same destination the label allocated by ISIS should be different than the label allocated by OSPF. This can be achieved in two ways: 1. ISIS and OSPF using same SRGBs but different index ranges. 2. ISIS and OSPF using different SRGBs but can have the same index ranges. I prefer option 2, as the operator does not need to maintain two different index ranges (one per-protocol). (I am not talking about what may or may not have been implemented by vendors - the YANG model should be architecturally correct) Les From: stephane.litkow...@orange.commailto:stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com] Sent: Wednesday, July 29, 2015 5:11 AM To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); spring@ietf.orgmailto:spring@ietf.org; Shraddha Hegde (shrad...@juniper.netmailto:shrad...@juniper.net); Pushpasis Sarkar (psar...@juniper.netmailto:psar...@juniper.net); Hannes Gredler (han...@juniper.netmailto:han...@juniper.net) Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi all, What if we keep the SRGB block config in segment-routing global module, and if we allow for YANG configuration of carving this block inside each protocol (maybe as a feature) ? Stephane From: Uma Chunduri [mailto:uma.chund...@ericsson.com] Sent: Friday, July 24, 2015 16:59 To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Stephane SCE/IBNF; spring@ietf.orgmailto:spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Suggesting that the forwarding instruction (AKA label) needs to be different depending on what protocol provided the instruction is completely unnecessary - it simply wastes label space. [Uma]: Les, No - I never suggested anything like that. SRGB for a routing instance to be advertised should be part of the routing instance provisioning as far as the yang model is concerned. Carving out the label space for SR is a local matter and agree, of course, this can be done in so many ways through CLI, dynamically, statically etc... -- Uma C. _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Hi Pushpasis, On Jul 30, 2015, at 11:11 AM, Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net wrote: Hi Acee, From: Acee Lindem (acee) a...@cisco.commailto:a...@cisco.com Date: Thursday, July 30, 2015 at 8:37 PM To: Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net Cc: Shraddha Hegde shrad...@juniper.netmailto:shrad...@juniper.net, Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com, Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net, Aissaoui, Mustapha (Mustapha) mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com, Stephane Litkowski stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org, Uma Chunduri uma.chund...@ericsson.commailto:uma.chund...@ericsson.com, Hannes Gredler han...@juniper.netmailto:han...@juniper.net Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Pushpasis, On Jul 30, 2015, at 10:54 AM, Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net wrote: Hi Acee, From: Acee Lindem (acee) a...@cisco.commailto:a...@cisco.com Date: Thursday, July 30, 2015 at 7:18 PM To: Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net Cc: Shraddha Hegde shrad...@juniper.netmailto:shrad...@juniper.net, Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com, Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net, Aissaoui, Mustapha (Mustapha) mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com, Stephane Litkowski stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org, Uma Chunduri uma.chund...@ericsson.commailto:uma.chund...@ericsson.com, Hannes Gredler han...@juniper.netmailto:han...@juniper.net Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Robert, Pushpasis, Shraddha, I guess I don’t understand why this gives you any operational advantage when you are migrating between protocol (e.g., from IS-IS to OSPF ;^). In fact, if you are using separate label spaces it will make migration more difficult and you will have to migrate your routing domain in shot rather than incrementally. [Pushpasis] All routers will program both transit mpls labels and create two parallel MPLS data planes well before the last step when all the ingress router will be instructed to switch traffic onto the new MPLS data plane (programmed by the new protocol) by changing the admin distance. That way the migration shall become seamless. And then once all ingreess routers has been swicthed to the new protocol and new MPLS dataplane, the old protocol and old MPLS data plane can be just removed from all the routers. Hope it is clear now… Normally only the protocol with the lower preference or admin distance would install a route to a particular prefix (including the label) into the RIB/LIB for the base IP unicast topology. I guess you are envisioning separate RIBs per protocol as well? [Pushpasis] What you are saying is true for the IP/V6—MPLS route in RIB/FIB on ingress routers. It is NOT TRUE for MPLS transit routes in LFIB. In MPLS architecture no two protocols installs the same label in LFIB. Each protocol (LDP/RSVP) uses different transit labels for the same destination IP/V6 FEC. That is one way to implement it but it makes more sense for the IGP label imposition and label stitching to both be dependent on the route being preferred. However, in another conversation I have been convinced that the network consolidation use case could benefit from configuration of per-protocol SRGB so I’m no longer opposed to this being a feature of the YANG model. Thanks, Acee Thanks, Acee Thanks, Acee On Jul 30, 2015, at 3:11 AM, Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net wrote: +1 From: Shraddha Hegde shrad...@juniper.netmailto:shrad...@juniper.net Date: Thursday, July 30, 2015 at 8:58 AM To: Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com, Robert Raszuk rob...@raszuk.netmailto:rob...@raszuk.net Cc: stephane.litkow...@orange.commailto:stephane.litkow...@orange.com stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, Uma Chunduri uma.chund...@ericsson.commailto:uma.chund...@ericsson.com, Aissaoui, Mustapha (Mustapha) mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com, spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org, Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net, Hannes Gredler han...@juniper.netmailto:han...@juniper.net Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang [Shraddha] route preference is local to router and the neighbor never knows what the other is going to choose. If there are inconsistencies in two protocols, there are going to be loops
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Les, The example that you gave about redistribution of routes from one protocol to another could be result of two different organizations merging into one. These networks being managed by different entities in the past may have same index assigned to nodes and different SRGBs configured in their respective domains. Operationally, it is easier to configure different SRGBs to the two different protocols that they run than mess with Indexes and SRGBs in an attempt to get same SRGB across two protocols. I don't think there is anything wrong architecturally, to have separate labels for different protocols. I believe there should be flexibility and choice for operators to configure the networks. If someone wants to deploy same SRGB for Different protocols or different SRGB for different protocols, the options should be available and providing such an option in YANG model is well justified. Rgds Shraddha From: Pushpasis Sarkar Sent: Thursday, July 30, 2015 1:55 PM To: Les Ginsberg (ginsberg) ginsb...@cisco.com; stephane.litkow...@orange.com; Uma Chunduri uma.chund...@ericsson.com; Aissaoui, Mustapha (Mustapha) mustapha.aissa...@alcatel-lucent.com; spring@ietf.org; Shraddha Hegde shrad...@juniper.net; Hannes Gredler han...@juniper.net Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Les, From: Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com Date: Thursday, July 30, 2015 at 9:46 AM To: Pushpasis Sarkar psar...@juniper.netmailto:psar...@juniper.net, stephane.litkow...@orange.commailto:stephane.litkow...@orange.com stephane.litkow...@orange.commailto:stephane.litkow...@orange.com, Uma Chunduri uma.chund...@ericsson.commailto:uma.chund...@ericsson.com, Aissaoui, Mustapha (Mustapha) mustapha.aissa...@alcatel-lucent.commailto:mustapha.aissa...@alcatel-lucent.com, spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org, Shraddha Hegde shrad...@juniper.netmailto:shrad...@juniper.net, Hannes Gredler han...@juniper.netmailto:han...@juniper.net Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Pushpassis - It is clear to me that what you propose is more complex to implement and more costly in its consumption of labels. [Pushpasis] I read through the entire repsponse and I still don't see why you think this is complex. Also, while distributing from one protocol to another you may want to attach another index with the FEC (in scenarios when you want to keep the index-management of destination protocol independent of the index-management of soruce protocol). Having per-protcol SRGB opens up lots of possibilities. One more point, you are only talking about the IP-route on the ingress box. We need to also consider the MPLS transit labels on transit boxes downloaded by each protocol. Shraddha in a previous thread has already pointed out cases with 'ships in the night' mode of migration from one protocol to another where this simplifies the micgration without causing any unwanted loops. What I do not yet appreciate is what capabilities protocol specific SRGBs provide which cannot be supported using a protocol independent SRGB. Could you please provide some specific examples? Please do not use an RSVP/LDP analogy - please use a proposed SR deployment case. [Pushpasis] One such example (migration from one protocol to another) has already been mentioned by Shraddha. But I can come with another example with BGP-LU prefix segment in Datacenter. A boundary router (between DCN and the DCI) will be running SR on two protocols - BGP-LU towards the home DCN as well as to the boubdray routers on remote DCNs across the DCI - ISIS/OSPF with all the routers within the DCI. If we have to keep the index management of DCNs independent of the index-management of DCI (I.e. Same index can be used on DCN as well as DCI) we need to make sure the transit label allocated on the boundary router by BGP-LU for a destination in DCN is separate from the transit label allocated by ISIS/OSPF for another destination in DCI network, even though BGP-LU and ISIS may use the same index for these two different destination routers. BTW, why do I say your proposal is more complex/costly? On a node where redistribution of routes is occurring, the source of redistribution (the best route) obviously allocates a local label based on its SRGB. But now the destination protocol for redistribution also has to allocate a local label based on its SRGB because it is expected that neighbors of the destination protocol will use a label from the destination protocol SRGB. So, you now have new requirements on the destination protocol and you have consumed twice as many local labels. Your forwarding plane now has to deal with the added complexity/cost - and your label manager has to manage more label ranges. [Pushpasis] I still don't get what added complexity is involved here. How does it matter if the label-manager has
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Hi Les, One additional point ... Assume I am using a virtual router with BGP module from vendor A and OSPF module from vendor B. Assume the traditinal monolithic physical or virtual router is not being used. Who and where would implement this notion of global SRGB concept ? How would it talk to protocols ? Why do I need to pay now for this from perhaps yet one more vendor ? As long as I have SR control plane contained within protocols and have each of them feeding dataplane (directly or via RIB) I should be fine. So I am not sure why do I need yet one more umbrella SR coordinator subsystem Best, Robert. On Thu, Jul 30, 2015 at 9:46 AM, Les Ginsberg (ginsberg) ginsb...@cisco.com wrote: Pushpassis – It is clear to me that what you propose is more complex to implement and more costly in its consumption of labels. What I do not yet appreciate is what capabilities protocol specific SRGBs provide which cannot be supported using a protocol independent SRGB. Could you please provide some specific examples? Please do not use an RSVP/LDP analogy – please use a proposed SR deployment case. BTW, why do I say your proposal is more complex/costly? On a node where redistribution of routes is occurring, the source of redistribution (the “best route”) obviously allocates a local label based on its SRGB. But now the destination protocol for redistribution also has to allocate a local label based on its SRGB because it is expected that neighbors of the destination protocol will use a label from the destination protocol SRGB. So, you now have new requirements on the destination protocol and you have consumed twice as many local labels. Your forwarding plane now has to deal with the added complexity/cost – and your label manager has to manage more label ranges. What I want to know is what do we gain for this added complexity? Thanx. Les *From:* Pushpasis Sarkar [mailto:psar...@juniper.net] *Sent:* Wednesday, July 29, 2015 11:16 PM *To:* Les Ginsberg (ginsberg); stephane.litkow...@orange.com; Uma Chunduri; Aissaoui, Mustapha (Mustapha); spring@ietf.org; Shraddha Hegde; Hannes Gredler *Subject:* Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Les, *From: *Les Ginsberg (ginsberg) ginsb...@cisco.com *Date: *Wednesday, July 29, 2015 at 11:01 PM *To: *stephane.litkow...@orange.com stephane.litkow...@orange.com, Uma Chunduri uma.chund...@ericsson.com, Aissaoui, Mustapha (Mustapha) mustapha.aissa...@alcatel-lucent.com, spring@ietf.org spring@ietf.org, Shraddha Hegde shrad...@juniper.net, Pushpasis Sarkar psar...@juniper.net, Hannes Gredler han...@juniper.net *Subject: *RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Stephane – What is the requirement to have a per-protocol SRGB config? This makes no sense to me operationally or architecturally. [Pushpasis] In current MPLS architecture, the same label is not allocated by both RSVP and LDP in a given box. With SR mapped to MPLS data-plane, we would like to retain the same behavior. For the same destination the label allocated by ISIS should be different than the label allocated by OSPF. This can be achieved in two ways: 1. ISIS and OSPF using same SRGBs but different index ranges. 2. ISIS and OSPF using different SRGBs but can have the same index ranges. I prefer option 2, as the operator does not need to maintain two different index ranges (one per-protocol). (I am not talking about what may or may not have been implemented by vendors – the YANG model should be architecturally correct) Les *From:* stephane.litkow...@orange.com [ mailto:stephane.litkow...@orange.com stephane.litkow...@orange.com] *Sent:* Wednesday, July 29, 2015 5:11 AM *To:* Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); spring@ietf.org; Shraddha Hegde (shrad...@juniper.net); Pushpasis Sarkar (psar...@juniper.net); Hannes Gredler (han...@juniper.net ) *Subject:* RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi all, What if we keep the SRGB block config in “segment-routing” global module, and if we allow for YANG configuration of carving this block inside each protocol (maybe as a feature) ? Stephane *From:* Uma Chunduri [mailto:uma.chund...@ericsson.com uma.chund...@ericsson.com] *Sent:* Friday, July 24, 2015 16:59 *To:* Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Stephane SCE/IBNF; spring@ietf.org *Subject:* RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Suggesting that the forwarding instruction (AKA label) needs to be different depending on what protocol provided the instruction is completely unnecessary – it simply wastes label space. [Uma]: Les, No - I never suggested anything like that. SRGB for a routing instance to be advertised should be part of the routing instance provisioning as far
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
One of the objective of the YANG Model is to manage devices. Hence the flexibility of having a separate SRGB per protocol is necessary, at least for operational reasons Ahmed On 7/29/2015 2:01 PM, Les Ginsberg (ginsberg) wrote: Stephane -- What is the requirement to have a per-protocol SRGB config? This makes no sense to me operationally or architecturally. (I am not talking about what may or may not have been implemented by vendors -- the YANG model should be architecturally correct) Les *From:*stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com] *Sent:* Wednesday, July 29, 2015 5:11 AM *To:* Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); spring@ietf.org; Shraddha Hegde (shrad...@juniper.net); Pushpasis Sarkar (psar...@juniper.net); Hannes Gredler (han...@juniper.net) *Subject:* RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi all, What if we keep the SRGB block config in segment-routing global module, and if we allow for YANG configuration of carving this block inside each protocol (maybe as a feature) ? Stephane *From:*Uma Chunduri [mailto:uma.chund...@ericsson.com] *Sent:* Friday, July 24, 2015 16:59 *To:* Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Stephane SCE/IBNF; spring@ietf.org mailto:spring@ietf.org *Subject:* RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Suggesting that the forwarding instruction (AKA label) needs to be different depending on what protocol provided the instruction is completely unnecessary -- it simply wastes label space. [Uma]: Les, No - I never suggested anything like that. SRGB for a routing instance to be advertised should be part of the routing instance provisioning as far as the yang model is concerned. Carving out the label space for SR is a local matter and agree, of course, this can be done in so many ways through CLI, dynamically, statically etc... -- Uma C. _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Robert - From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk Sent: Wednesday, July 29, 2015 2:45 PM To: Les Ginsberg (ginsberg) Cc: stephane.litkow...@orange.com; Uma Chunduri; Aissaoui, Mustapha (Mustapha); spring@ietf.org; Shraddha Hegde (shrad...@juniper.net); Pushpasis Sarkar (psar...@juniper.net); Hannes Gredler (han...@juniper.net) Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Les, This makes no sense to me operationally or architecturally. Fundamentally I fully agree with you. However architecturally: However at least looking at group of folks who claim that it is impossible to get same SRGB block in *any* network between two or more vendors I think Stephane's intention would be to at least get it per one protocol even if platform wide the intersecting pool may be mission impossible. [Les:] This is an unrelated issue. Placing SRGB in global context does not mean all routers have to have the same SRGB. There is no controversy here. and now operationally: Another reason would be idea of dual overlapping SRGBs perhaps quite useful during migrations between protocols where the exact same SRGB is set on both then just based on admin distance one vs the other protocol is chosen. While a standard practice in protocol migrations not sure if anyone looked at that from SR perspective. [Les:] Not sure what you are trying to say. If the two SRGBs are the same – why do we need to configure them per protocol? If the two SRGBs are not the same, other routers in the network have no idea which protocol is going to win on your box. So your neighbor has no idea whether it should use the SRGB advertised by OSPF or the SRGB advertised by IS-IS. Les Cheers, R. On Wed, Jul 29, 2015 at 11:01 PM, Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com wrote: Stephane – What is the requirement to have a per-protocol SRGB config? This makes no sense to me operationally or architecturally. (I am not talking about what may or may not have been implemented by vendors – the YANG model should be architecturally correct) Les ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Hi all, What if we keep the SRGB block config in segment-routing global module, and if we allow for YANG configuration of carving this block inside each protocol (maybe as a feature) ? Stephane From: Uma Chunduri [mailto:uma.chund...@ericsson.com] Sent: Friday, July 24, 2015 16:59 To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Stephane SCE/IBNF; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Suggesting that the forwarding instruction (AKA label) needs to be different depending on what protocol provided the instruction is completely unnecessary - it simply wastes label space. [Uma]: Les, No - I never suggested anything like that. SRGB for a routing instance to be advertised should be part of the routing instance provisioning as far as the yang model is concerned. Carving out the label space for SR is a local matter and agree, of course, this can be done in so many ways through CLI, dynamically, statically etc... -- Uma C. _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
On Jul 29, 2015, at 6:28 PM, Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com wrote: Robert - From: rras...@gmail.commailto:rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk Sent: Wednesday, July 29, 2015 2:45 PM To: Les Ginsberg (ginsberg) Cc: stephane.litkow...@orange.commailto:stephane.litkow...@orange.com; Uma Chunduri; Aissaoui, Mustapha (Mustapha); spring@ietf.orgmailto:spring@ietf.org; Shraddha Hegde (shrad...@juniper.netmailto:shrad...@juniper.net); Pushpasis Sarkar (psar...@juniper.netmailto:psar...@juniper.net); Hannes Gredler (han...@juniper.netmailto:han...@juniper.net) Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Les, This makes no sense to me operationally or architecturally. Fundamentally I fully agree with you. However architecturally: However at least looking at group of folks who claim that it is impossible to get same SRGB block in *any* network between two or more vendors I think Stephane's intention would be to at least get it per one protocol even if platform wide the intersecting pool may be mission impossible. [Les:] This is an unrelated issue. Placing SRGB in global context does not mean all routers have to have the same SRGB. There is no controversy here. and now operationally: Another reason would be idea of dual overlapping SRGBs perhaps quite useful during migrations between protocols where the exact same SRGB is set on both then just based on admin distance one vs the other protocol is chosen. While a standard practice in protocol migrations not sure if anyone looked at that from SR perspective. [Les:] Not sure what you are trying to say. If the two SRGBs are the same – why do we need to configure them per protocol? If the two SRGBs are not the same, other routers in the network have no idea which protocol is going to win on your box. So your neighbor has no idea whether it should use the SRGB advertised by OSPF or the SRGB advertised by IS-IS. Actually, if the same prefix in the same topology is advertised by two protocols, I would think that the SID should map to the same label. I see no advantage at all in having separate labels. Acee Les Cheers, R. On Wed, Jul 29, 2015 at 11:01 PM, Les Ginsberg (ginsberg) ginsb...@cisco.commailto:ginsb...@cisco.com wrote: Stephane – What is the requirement to have a per-protocol SRGB config? This makes no sense to me operationally or architecturally. (I am not talking about what may or may not have been implemented by vendors – the YANG model should be architecturally correct) Les ___ spring mailing list spring@ietf.orgmailto:spring@ietf.org https://www.ietf.org/mailman/listinfo/spring ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Les, It is really for ease of management that one provides a single context where the user can manage the label space for the platform. You can assign blocks of labels for static labels, SRGB, and some BGP based L2 VPN. The rest of the range is available for assignment by signaling protocols (RSVP, LDP, BGP, and LDP services). An implementation can certainly implement the label block assignment in each context separately. Regards, Mustapha. From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Thursday, July 23, 2015 5:11 PM To: Aissaoui, Mustapha (Mustapha); Uma Chunduri; stephane.litkow...@orange.com; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Mustapha/Uma - SRGB is an attribute of segment-routing - if that feature is not enabled there is no need for an SRGB. Conceptually (your box is free to implement it differently of course) Segment Routing talks to your label manager to request a reservation of the configured SRGB so none of the labels in that range can be used for a purpose other than segment routing. That does not mean the SRGB configuration is associated w the label manager. It would be just as logical to argue that all objects should be owned by your memory management module because everything we configure requires a memory block to be allocated to store the attribute information. Uma -labels are instructions to forwarding as to how to forward packets to a given (set of) destination(s). In forwarding we do not care what protocol was used to learn the path to that destination. Suggesting that the forwarding instruction (AKA label) needs to be different depending on what protocol provided the instruction is completely unnecessary - it simply wastes label space. Les From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Aissaoui, Mustapha (Mustapha) Sent: Thursday, July 23, 2015 11:24 AM To: Uma Chunduri; stephane.litkow...@orange.commailto:stephane.litkow...@orange.com; spring@ietf.orgmailto:spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Umma, I am saying that SRGB be should configured globally and under the router label management since that is where one assigns label blocks to various applications. If you want IGP instances to uses separate sub-ranges of the globally configured SRGB, you can still achieve that without moving the SRGB configuration into the IGP instance. You just need to configure within the IGP instance which SID ranges and which label offset it uses and make sure you manage any overlap when you request a label from the global SRGB. It is the SID range and the label offset parameters which are advertised by the IGP instance in the router SR capabilities sub-TLV. Mustapha. From: Uma Chunduri [mailto:uma.chund...@ericsson.com] Sent: Thursday, July 23, 2015 1:56 PM To: Aissaoui, Mustapha (Mustapha); stephane.litkow...@orange.commailto:stephane.litkow...@orange.com; spring@ietf.orgmailto:spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang I do not see it being configured under segment routing. Precisely. Having said that, I think implementations can still partition the global label sub-range assigned to the SRGB among multiple IGP instances and manage the collisions. And that is what would be advertised in the respective routing area/domain through respective protocol mechanisms (a.k.a capability TLVs). -- Uma C. From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Aissaoui, Mustapha (Mustapha) Sent: Thursday, July 23, 2015 10:42 AM To: stephane.litkow...@orange.commailto:stephane.litkow...@orange.com; spring@ietf.orgmailto:spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Stephane and all, The SRGB in the case of MPLS data plane is a dedicated label range to be assigned for global segments. So, it is part of label management on a router. Implementations already allow configuring the label range and assigning specific blocks for static LSPs and other applications. Segment routing is yet another application and as such the SRGB should just be configured where the label management on the router is configured. I do not see it being configured under segment routing. Having said that, I think implementations can still partition the global label sub-range assigned to the SRGB among multiple IGP instances and manage the collisions. Regards, Mustapha. From: spring [mailto:spring-boun...@ietf.org] On Behalf Of stephane.litkow...@orange.commailto:stephane.litkow...@orange.com Sent: Wednesday, July 22, 2015 1:20 PM To: spring@ietf.orgmailto:spring@ietf.org Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is configured at SR top level, so it is agnostic to the routing protocol. We had some comment
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Mustapha/Uma - SRGB is an attribute of segment-routing - if that feature is not enabled there is no need for an SRGB. Conceptually (your box is free to implement it differently of course) Segment Routing talks to your label manager to request a reservation of the configured SRGB so none of the labels in that range can be used for a purpose other than segment routing. That does not mean the SRGB configuration is associated w the label manager. It would be just as logical to argue that all objects should be owned by your memory management module because everything we configure requires a memory block to be allocated to store the attribute information. Uma -labels are instructions to forwarding as to how to forward packets to a given (set of) destination(s). In forwarding we do not care what protocol was used to learn the path to that destination. Suggesting that the forwarding instruction (AKA label) needs to be different depending on what protocol provided the instruction is completely unnecessary - it simply wastes label space. Les From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Aissaoui, Mustapha (Mustapha) Sent: Thursday, July 23, 2015 11:24 AM To: Uma Chunduri; stephane.litkow...@orange.com; spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Umma, I am saying that SRGB be should configured globally and under the router label management since that is where one assigns label blocks to various applications. If you want IGP instances to uses separate sub-ranges of the globally configured SRGB, you can still achieve that without moving the SRGB configuration into the IGP instance. You just need to configure within the IGP instance which SID ranges and which label offset it uses and make sure you manage any overlap when you request a label from the global SRGB. It is the SID range and the label offset parameters which are advertised by the IGP instance in the router SR capabilities sub-TLV. Mustapha. From: Uma Chunduri [mailto:uma.chund...@ericsson.com] Sent: Thursday, July 23, 2015 1:56 PM To: Aissaoui, Mustapha (Mustapha); stephane.litkow...@orange.commailto:stephane.litkow...@orange.com; spring@ietf.orgmailto:spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang I do not see it being configured under segment routing. Precisely. Having said that, I think implementations can still partition the global label sub-range assigned to the SRGB among multiple IGP instances and manage the collisions. And that is what would be advertised in the respective routing area/domain through respective protocol mechanisms (a.k.a capability TLVs). -- Uma C. From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Aissaoui, Mustapha (Mustapha) Sent: Thursday, July 23, 2015 10:42 AM To: stephane.litkow...@orange.commailto:stephane.litkow...@orange.com; spring@ietf.orgmailto:spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Stephane and all, The SRGB in the case of MPLS data plane is a dedicated label range to be assigned for global segments. So, it is part of label management on a router. Implementations already allow configuring the label range and assigning specific blocks for static LSPs and other applications. Segment routing is yet another application and as such the SRGB should just be configured where the label management on the router is configured. I do not see it being configured under segment routing. Having said that, I think implementations can still partition the global label sub-range assigned to the SRGB among multiple IGP instances and manage the collisions. Regards, Mustapha. From: spring [mailto:spring-boun...@ietf.org] On Behalf Of stephane.litkow...@orange.commailto:stephane.litkow...@orange.com Sent: Wednesday, July 22, 2015 1:20 PM To: spring@ietf.orgmailto:spring@ietf.org Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is configured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label range shared between protocols could lead to. During discussion in our design team, some point was also raised on routing protocol migrations that may be safer using a per protocol SRGB (so configuration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for both approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol manages its own label space. Thanks to provide your feedback in order to solve this issue and have a consensus. [Orange logo]http://www.orange.com/ Stephane Litkowski Network Architect Orange
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
I strongly prefer option 1. The purpose of the SRGB range is to allow devices in the segment routing domain to use different MPLS label ranges for segment routing. This is necessary either due to the devices having allocated MPLS label ranges for other purposes (e.g., LDP or static LSPs) or the devices not supporting the full MPLS label range. SRGB is not meant to be used to allocate unique label ranges to various protocols or purposes. Thanks, Acee From: spring spring-boun...@ietf.orgmailto:spring-boun...@ietf.org on behalf of Stephane Litkowski stephane.litkow...@orange.commailto:stephane.litkow...@orange.com Date: Wednesday, July 22, 2015 at 7:19 PM To: spring@ietf.orgmailto:spring@ietf.org spring@ietf.orgmailto:spring@ietf.org Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is configured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label range shared between protocols could lead to. During discussion in our design team, some point was also raised on routing protocol migrations that may be safer using a per protocol SRGB (so configuration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for both approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol manages its own label space. Thanks to provide your feedback in order to solve this issue and have a consensus. [Orange logo]http://www.orange.com/ Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20 mobile: +33 6 37 86 97 52 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20 stephane.litkow...@orange.commailto:stephane.litkow...@orange.com _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Mustapha - I am not telling you what your CLI should look like - trust me - getting folks within my own company to agree on CLI is difficult enough. :) We are discussing whether the placement of SRGB in the YANG model under segment-routing is appropriate. IMO it absolutely is correct. Placing it anywhere else is wrong. That does not prevent you from using a label manager CLI in your router to configure SRGB. Les From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissa...@alcatel-lucent.com] Sent: Thursday, July 23, 2015 2:56 PM To: Les Ginsberg (ginsberg); Uma Chunduri; stephane.litkow...@orange.com; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Les, It is really for ease of management that one provides a single context where the user can manage the label space for the platform. You can assign blocks of labels for static labels, SRGB, and some BGP based L2 VPN. The rest of the range is available for assignment by signaling protocols (RSVP, LDP, BGP, and LDP services). An implementation can certainly implement the label block assignment in each context separately. Regards, Mustapha. From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Thursday, July 23, 2015 5:11 PM To: Aissaoui, Mustapha (Mustapha); Uma Chunduri; stephane.litkow...@orange.commailto:stephane.litkow...@orange.com; spring@ietf.orgmailto:spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Mustapha/Uma - SRGB is an attribute of segment-routing - if that feature is not enabled there is no need for an SRGB. Conceptually (your box is free to implement it differently of course) Segment Routing talks to your label manager to request a reservation of the configured SRGB so none of the labels in that range can be used for a purpose other than segment routing. That does not mean the SRGB configuration is associated w the label manager. It would be just as logical to argue that all objects should be owned by your memory management module because everything we configure requires a memory block to be allocated to store the attribute information. Uma -labels are instructions to forwarding as to how to forward packets to a given (set of) destination(s). In forwarding we do not care what protocol was used to learn the path to that destination. Suggesting that the forwarding instruction (AKA label) needs to be different depending on what protocol provided the instruction is completely unnecessary - it simply wastes label space. Les From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Aissaoui, Mustapha (Mustapha) Sent: Thursday, July 23, 2015 11:24 AM To: Uma Chunduri; stephane.litkow...@orange.commailto:stephane.litkow...@orange.com; spring@ietf.orgmailto:spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Umma, I am saying that SRGB be should configured globally and under the router label management since that is where one assigns label blocks to various applications. If you want IGP instances to uses separate sub-ranges of the globally configured SRGB, you can still achieve that without moving the SRGB configuration into the IGP instance. You just need to configure within the IGP instance which SID ranges and which label offset it uses and make sure you manage any overlap when you request a label from the global SRGB. It is the SID range and the label offset parameters which are advertised by the IGP instance in the router SR capabilities sub-TLV. Mustapha. From: Uma Chunduri [mailto:uma.chund...@ericsson.com] Sent: Thursday, July 23, 2015 1:56 PM To: Aissaoui, Mustapha (Mustapha); stephane.litkow...@orange.commailto:stephane.litkow...@orange.com; spring@ietf.orgmailto:spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang I do not see it being configured under segment routing. Precisely. Having said that, I think implementations can still partition the global label sub-range assigned to the SRGB among multiple IGP instances and manage the collisions. And that is what would be advertised in the respective routing area/domain through respective protocol mechanisms (a.k.a capability TLVs). -- Uma C. From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Aissaoui, Mustapha (Mustapha) Sent: Thursday, July 23, 2015 10:42 AM To: stephane.litkow...@orange.commailto:stephane.litkow...@orange.com; spring@ietf.orgmailto:spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Stephane and all, The SRGB in the case of MPLS data plane is a dedicated label range to be assigned for global segments. So, it is part of label management on a router. Implementations already allow configuring the label range and assigning specific blocks for static LSPs and other applications. Segment routing is yet another application and as such the SRGB should just
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Hi Umma, I am saying that SRGB be should configured globally and under the router label management since that is where one assigns label blocks to various applications. If you want IGP instances to uses separate sub-ranges of the globally configured SRGB, you can still achieve that without moving the SRGB configuration into the IGP instance. You just need to configure within the IGP instance which SID ranges and which label offset it uses and make sure you manage any overlap when you request a label from the global SRGB. It is the SID range and the label offset parameters which are advertised by the IGP instance in the router SR capabilities sub-TLV. Mustapha. From: Uma Chunduri [mailto:uma.chund...@ericsson.com] Sent: Thursday, July 23, 2015 1:56 PM To: Aissaoui, Mustapha (Mustapha); stephane.litkow...@orange.com; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang I do not see it being configured under segment routing. Precisely. Having said that, I think implementations can still partition the global label sub-range assigned to the SRGB among multiple IGP instances and manage the collisions. And that is what would be advertised in the respective routing area/domain through respective protocol mechanisms (a.k.a capability TLVs). -- Uma C. From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Aissaoui, Mustapha (Mustapha) Sent: Thursday, July 23, 2015 10:42 AM To: stephane.litkow...@orange.commailto:stephane.litkow...@orange.com; spring@ietf.orgmailto:spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Stephane and all, The SRGB in the case of MPLS data plane is a dedicated label range to be assigned for global segments. So, it is part of label management on a router. Implementations already allow configuring the label range and assigning specific blocks for static LSPs and other applications. Segment routing is yet another application and as such the SRGB should just be configured where the label management on the router is configured. I do not see it being configured under segment routing. Having said that, I think implementations can still partition the global label sub-range assigned to the SRGB among multiple IGP instances and manage the collisions. Regards, Mustapha. From: spring [mailto:spring-boun...@ietf.org] On Behalf Of stephane.litkow...@orange.commailto:stephane.litkow...@orange.com Sent: Wednesday, July 22, 2015 1:20 PM To: spring@ietf.orgmailto:spring@ietf.org Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is configured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label range shared between protocols could lead to. During discussion in our design team, some point was also raised on routing protocol migrations that may be safer using a per protocol SRGB (so configuration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for both approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol manages its own label space. Thanks to provide your feedback in order to solve this issue and have a consensus. [Orange logo]http://www.orange.com/ Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20 mobile: +33 6 37 86 97 52 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20 stephane.litkow...@orange.commailto:stephane.litkow...@orange.com _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error
Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Hi Stephane and all, The SRGB in the case of MPLS data plane is a dedicated label range to be assigned for global segments. So, it is part of label management on a router. Implementations already allow configuring the label range and assigning specific blocks for static LSPs and other applications. Segment routing is yet another application and as such the SRGB should just be configured where the label management on the router is configured. I do not see it being configured under segment routing. Having said that, I think implementations can still partition the global label sub-range assigned to the SRGB among multiple IGP instances and manage the collisions. Regards, Mustapha. From: spring [mailto:spring-boun...@ietf.org] On Behalf Of stephane.litkow...@orange.com Sent: Wednesday, July 22, 2015 1:20 PM To: spring@ietf.org Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is configured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label range shared between protocols could lead to. During discussion in our design team, some point was also raised on routing protocol migrations that may be safer using a per protocol SRGB (so configuration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for both approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol manages its own label space. Thanks to provide your feedback in order to solve this issue and have a consensus. [Orange logo]http://www.orange.com/ Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20 mobile: +33 6 37 86 97 52 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20 stephane.litkow...@orange.commailto:stephane.litkow...@orange.com _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
[spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang
Hi WG, In the current version of the config Yang model for SR, the SRGB list is configured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label range shared between protocols could lead to. During discussion in our design team, some point was also raised on routing protocol migrations that may be safer using a per protocol SRGB (so configuration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for both approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol manages its own label space. Thanks to provide your feedback in order to solve this issue and have a consensus. [Orange logo]http://www.orange.com/ Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20 mobile: +33 6 37 86 97 52 https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20 stephane.litkow...@orange.commailto:stephane.litkow...@orange.com _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
