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: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Thursday, July 30, 2015 2:19 AM To: Les Ginsberg (ginsberg) Cc: Pushpasis Sarkar; [email protected]; [email protected]; 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) <[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>] Sent: Wednesday, July 29, 2015 11:16 PM To: Les Ginsberg (ginsberg); [email protected]<mailto:[email protected]>; Uma Chunduri; Aissaoui, Mustapha (Mustapha); [email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
