Les, It is really for ease of management that one provides a single context where the user can manage the label space for the platform. You can assign blocks of labels for static labels, SRGB, and some BGP based L2 VPN. The rest of the range is available for assignment by signaling protocols (RSVP, LDP, BGP, and LDP services).
An implementation can certainly implement the label block assignment in each context separately. Regards, Mustapha. From: Les Ginsberg (ginsberg) [mailto:[email protected]] Sent: Thursday, July 23, 2015 5:11 PM To: Aissaoui, Mustapha (Mustapha); Uma Chunduri; [email protected]; [email protected] Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Mustapha/Uma - SRGB is an attribute of segment-routing - if that feature is not enabled there is no need for an SRGB. Conceptually (your box is free to implement it differently of course) "Segment Routing" talks to your label manager to request a reservation of the configured SRGB so none of the labels in that range can be used for a purpose other than segment routing. That does not mean the SRGB configuration is associated w the label manager. It would be just as logical to argue that all objects should be owned by your memory management module because everything we configure requires a memory block to be allocated to store the attribute information. Uma -labels are instructions to forwarding as to how to forward packets to a given (set of) destination(s). In forwarding we do not care what protocol was used to learn the path to that destination. 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. Les From: spring [mailto:[email protected]] On Behalf Of Aissaoui, Mustapha (Mustapha) Sent: Thursday, July 23, 2015 11:24 AM To: Uma Chunduri; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Umma, I am saying that SRGB be should configured globally and under the router label management since that is where one assigns label blocks to various applications. If you want IGP instances to uses separate sub-ranges of the globally configured SRGB, you can still achieve that without moving the SRGB configuration into the IGP instance. You just need to configure within the IGP instance which SID ranges and which label offset it uses and make sure you manage any overlap when you request a label from the global SRGB. It is the SID range and the label offset parameters which are advertised by the IGP instance in the router SR capabilities sub-TLV. Mustapha. From: Uma Chunduri [mailto:[email protected]] Sent: Thursday, July 23, 2015 1:56 PM To: Aissaoui, Mustapha (Mustapha); [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang >I do not see it being configured under segment routing. Precisely. >Having said that, I think implementations can still partition the global label >sub-range assigned to the SRGB among multiple IGP instances and manage the >collisions. And that is what would be advertised in the respective routing area/domain through respective protocol mechanisms (a.k.a capability TLVs). -- Uma C. From: spring [mailto:[email protected]] On Behalf Of Aissaoui, Mustapha (Mustapha) Sent: Thursday, July 23, 2015 10:42 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi Stephane and all, The SRGB in the case of MPLS data plane is a dedicated label range to be assigned for global segments. So, it is part of label management on a router. Implementations already allow configuring the label range and assigning specific blocks for static LSPs and other applications. Segment routing is yet another application and as such the SRGB should just be configured where the label management on the router is configured. I do not see it being configured under segment routing. Having said that, I think implementations can still partition the global label sub-range assigned to the SRGB among multiple IGP instances and manage the collisions. Regards, Mustapha. From: spring [mailto:[email protected]] On Behalf Of [email protected]<mailto:[email protected]> Sent: Wednesday, July 22, 2015 1:20 PM To: [email protected]<mailto:[email protected]> Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is configured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label range shared between protocols could lead to. During discussion in our design team, some point was also raised on routing protocol migrations that may be safer using a per protocol SRGB (so configuration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for both approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol manages its own label space. Thanks to provide your feedback in order to solve this issue and have a consensus. [Orange logo]<http://www.orange.com/> Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20> mobile: +33 6 37 86 97 52 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20> [email protected]<mailto:[email protected]> _________________________________________________________________________________________________________________________ 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
