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