Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 23 Jul 2015 12:49:17 +0000

I strongly prefer option 1. The purpose of the SRGB range is to allow devices in the segment routing domain to use different MPLS label ranges for segment routing. This is necessary either due to the devices having allocated MPLS label ranges for other purposes (e.g., LDP or static LSPs) or the devices not supporting the full MPLS label range. SRGB is not meant to be used to allocate unique label ranges to various protocols or purposes.
Thanks,
Acee

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Stephane Litkowski <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 22, 2015 at 7:19 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

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.

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 23 Jul 2015 16:26:37 +0000

Hi Acee,
Fate sharing of same SRGB space by  multiple protocols may not be a good idea.
IMHO, SRGB configuration should be @ protocols and per instance.

Also you would agree, this has no relevance for the ability to configure any range by the operator to keep the same SRGB in multi-vendor deployments.
--
Uma C.

From: spring [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Thursday, July 23, 2015 5:49 AM
To: [email-masked]; [email-masked]
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 23 Jul 2015 17:24:26 +0000

Uma –

SRGB(s) are an attribute of a router – NOT an individual routing protocol. To believe otherwise is to suggest that when forwarding a packet we should care what protocol (or even according to your response – what protocol instance) installed the best route which makes no sense.

I don’t believe there is a “fate sharing” issue – you would have to explain that one.

   Les

From: spring [mailto:[email-masked]] On Behalf Of Uma Chunduri
Sent: Thursday, July 23, 2015 9:27 AM
To: Acee Lindem (acee); [email-masked]; [email-masked]
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Acee,

From: spring [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Thursday, July 23, 2015 5:49 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 31 Jul 2015 06:03:37 +0000

Hi,

Architecturally I agree – label manager shouldn’t care less how labels have been learnt
Operationally I’m strongly for #2, in case of ISIS possibly under AF.

Cheers,
Jeff

Hi WG,

Stephane Litkowski
Network Architect

---

From: <[email-masked]>
Date: Fri, 31 Jul 2015 08:52:04 +0000

Looks that consensus is for option#2, so let's move SRGB to protocol configuration.

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Friday, July 31, 2015 08:04
To: LITKOWSKI Stephane SCE/IBNF; [email-masked]
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi,

Architecturally I agree - label manager shouldn't care less how labels have been learnt
Operationally I'm strongly for #2, in case of ISIS possibly under AF.

Cheers,
Jeff

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 31 Jul 2015 20:40:51 +0000

Hi Stephane,

While there may be transitional use cases where there is a requirement to allocate different SRGBs to different protocols instances, I don’t believe we should “throw the baby out with the bathwater” and remove the global SRGB configuration. The operational simplicity and managability advantages of having a single SRGB for the node are undeniable. The benefits are multiplied if one can maintain a consistent SRGB throughout the segment routing domain (although I understand that this is not always possible).

Hence, I believe we should retain the global SRGB configuration in the YANG model. In the protocols, the global SRGB would be inherited or, if configured, overwritten by protocol configuration. If we cannot agree on either being mandatory, both could be YANG features.

Thanks,
Acee

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Stephane Litkowski <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 31, 2015 at 3:52 AM
To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Looks that consensus is for option#2, so let’s move SRGB to protocol configuration.

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Friday, July 31, 2015 08:04
To: LITKOWSKI Stephane SCE/IBNF; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi,

Cheers,
Jeff

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 31 Jul 2015 23:18:11 +0000

A very strong “+1” to what Acee has said.

   Les

From: spring [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Friday, July 31, 2015 1:41 PM
To: [email-masked]; Jeff Tantsura; [email-masked]
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Stephane,

Thanks,
Acee

Hi,

Cheers,
Jeff

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

Thank you.