One of the objective of the YANG Model is to manage devices. Hence the
flexibility of having a separate SRGB per protocol is necessary, at
least for operational reasons
Ahmed
On 7/29/2015 2:01 PM, Les Ginsberg (ginsberg) wrote:
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:*[email protected]
[mailto:[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]]
*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
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
