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:[email protected]] Sent: Wednesday, July 29, 2015 11:16 PM To: Les Ginsberg (ginsberg); [email protected]; Uma Chunduri; Aissaoui, Mustapha (Mustapha); [email protected]; Shraddha Hegde; Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Les, From: "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>> Date: Wednesday, July 29, 2015 at 11:01 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Uma Chunduri <[email protected]<mailto:[email protected]>>, "Aissaoui, Mustapha (Mustapha)" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[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 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: [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.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
