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:[email protected]] Sent: Wednesday, July 29, 2015 23:01 To: LITKOWSKI Stephane SCE/IBNF; Uma Chunduri; Aissaoui, Mustapha (Mustapha); [email protected]; Shraddha Hegde ([email protected]); Pushpasis Sarkar ([email protected]); Hannes Gredler ([email protected]) 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: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Wednesday, July 29, 2015 5:11 AM To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); [email protected]<mailto:[email protected]>; Shraddha Hegde ([email protected]<mailto:[email protected]>); Pushpasis Sarkar ([email protected]<mailto:[email protected]>); Hannes Gredler ([email protected]<mailto:[email protected]>) 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:[email protected]] Sent: Friday, July 24, 2015 16:59 To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Stephane SCE/IBNF; [email protected]<mailto:[email protected]> 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.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
