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: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com] Sent: Wednesday, July 29, 2015 5:11 AM To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); spring@ietf.org; Shraddha Hegde (shrad...@juniper.net); Pushpasis Sarkar (psar...@juniper.net); Hannes Gredler (han...@juniper.net) 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:uma.chund...@ericsson.com] Sent: Friday, July 24, 2015 16:59 To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Stephane SCE/IBNF; spring@ietf.org<mailto:spring@ietf.org> 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 spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
