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? 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 +0000, 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...@cisco.com] > | Sent: Wednesday, July 29, 2015 23:01 > | To: LITKOWSKI Stephane SCE/IBNF; 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 > | > | > | > | 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: [1]stephane.litkow...@orange.com > | [[2]mailto:stephane.litkow...@orange.com] > | Sent: Wednesday, July 29, 2015 5:11 AM > | To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha > (Mustapha); > | [3]spring@ietf.org; Shraddha Hegde ([4]shrad...@juniper.net); > Pushpasis > | Sarkar ([5]psar...@juniper.net); Hannes Gredler > ([6]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 [[7]mailto:uma.chund...@ericsson.com] > | Sent: Friday, July 24, 2015 16:59 > | To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI > | Stephane SCE/IBNF; [8]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. > | > | > | > __________________________________________________________ > ____________ > | ___________________________________________________ > | > | 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. > | > | References > | > | Visible links > | 1. mailto:stephane.litkow...@orange.com > | 2. mailto:stephane.litkow...@orange.com > | 3. mailto:spring@ietf.org > | 4. mailto:shrad...@juniper.net > | 5. mailto:psar...@juniper.net > | 6. mailto:han...@juniper.net > | 7. mailto:uma.chund...@ericsson.com > | 8. mailto:spring@ietf.org _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
