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