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

From: <[email-masked]>
Date: Wed, 22 Jul 2015 17:19:59 +0000

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: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 23 Jul 2015 17:41:31 +0000

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-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 22, 2015 1:20 PM
To: [email-masked]
Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 23 Jul 2015 17:56:24 +0000

>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-masked]] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Thursday, July 23, 2015 10:42 AM
To: [email-masked]; [email-masked]
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Stephane and all,

Regards,
Mustapha.

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, July 22, 2015 1:20 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 23 Jul 2015 18:24:22 +0000

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-masked]]
Sent: Thursday, July 23, 2015 1:56 PM
To: Aissaoui, Mustapha (Mustapha); [email-masked]; [email-masked]
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Precisely.

--
Uma C.

From: spring [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Thursday, July 23, 2015 10:42 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 Stephane and all,

Regards,
Mustapha.

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 23 Jul 2015 21:10:30 +0000

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-masked]] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Thursday, July 23, 2015 11:24 AM
To: Uma Chunduri; [email-masked]; [email-masked]
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Umma,

Mustapha.

From: Uma Chunduri [mailto:[email-masked]]
Sent: Thursday, July 23, 2015 1:56 PM
To: Aissaoui, Mustapha (Mustapha); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Precisely.

--
Uma C.

Hi Stephane and all,

Regards,
Mustapha.

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Thu, 23 Jul 2015 21:56:27 +0000

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-masked]]
Sent: Thursday, July 23, 2015 5:11 PM
To: Aissaoui, Mustapha (Mustapha); Uma Chunduri; [email-masked]; [email-masked]
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Mustapha/Uma -

   Les

From: spring [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Thursday, July 23, 2015 11:24 AM
To: Uma Chunduri; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Umma,

Mustapha.

Precisely.

--
Uma C.

Hi Stephane and all,

Regards,
Mustapha.

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

---

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

Mustapha -

I am not telling you what your CLI should look like - trust me - getting folks within my own company to agree on CLI is difficult enough. :)

We are discussing whether the placement of SRGB in the YANG model under segment-routing is appropriate. IMO it absolutely is correct. Placing it anywhere else is wrong.

That does not prevent you from using a label manager CLI in your router to configure SRGB.

   Les

From: Aissaoui, Mustapha (Mustapha) [mailto:[email-masked]]
Sent: Thursday, July 23, 2015 2:56 PM
To: Les Ginsberg (ginsberg); Uma Chunduri; [email-masked]; [email-masked]
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Les,

Regards,
Mustapha.

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Thursday, July 23, 2015 5:11 PM
To: Aissaoui, Mustapha (Mustapha); Uma Chunduri; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Mustapha/Uma -

   Les

Hi Umma,

Mustapha.

Precisely.

--
Uma C.

Hi Stephane and all,

Regards,
Mustapha.

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 24 Jul 2015 14:49:48 +0000

>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.

[Uma]: Mustapha, yes of course, this is the only thing that matters for  rest of the nodes in the area/domain and these are indeed SRGB descriptors.
            Provisioning here obviously belong to the routing protocol instance. For rest of the nodes PoV  this is your "global SRGB".

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 24 Jul 2015 14:59:25 +0000

>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.

---

From: <[email-masked]>
Date: Wed, 29 Jul 2015 12:10:39 +0000

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-masked]]
Sent: Friday, July 24, 2015 16:59
To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Stephane SCE/IBNF; [email-masked]
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

--
Uma C.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 29 Jul 2015 21:01:29 +0000

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-masked] [mailto:[email-masked]]
Sent: Wednesday, July 29, 2015 5:11 AM
To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); [email-masked]; Shraddha Hegde ([email-masked]); Pushpasis Sarkar ([email-masked]); Hannes Gredler ([email-masked])
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi all,

Stephane

From: Uma Chunduri [mailto:[email-masked]]
Sent: Friday, July 24, 2015 16:59
To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Stephane SCE/IBNF; [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

--
Uma C.

Thank you.

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Wed, 29 Jul 2015 14:22:56 -0700

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 --
> (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-masked] 
> [mailto:[email-masked]]
> *Sent:* Wednesday, July 29, 2015 5:11 AM
> *To:* Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha 
> (Mustapha); [email-masked]; Shraddha Hegde ([email-masked]); 
> Pushpasis Sarkar ([email-masked]); Hannes Gredler 
> ([email-masked])
> *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-masked]]
> *Sent:* Friday, July 24, 2015 16:59
> *To:* Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); 
> LITKOWSKI Stephane SCE/IBNF; [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [spring] Modeling SRGB configuration for 
> draft-ietf-spring-sr-yang
>
> >the instruction is completely unnecessary -- it simply wastes label space.
>
> 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.
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 29 Jul 2015 23:45:04 +0200

Hi Les,

> ​

Fundamentally I fully agree with you.

However architecturally:

However at least looking at group of folks who claim that it is impossible
to get same SRGB block in *any* network between two or more vendors  I
think Stephane's intention would be to at least get it per one protocol
even if platform wide the intersecting pool may be mission impossible.

and now operationally:

Another reason would be idea of dual overlapping SRGBs perhaps quite useful
during migrations between protocols where the exact same SRGB is set on
both then just based on admin distance one vs the other protocol is chosen.
While a standard practice in protocol migrations not sure if anyone looked
at that from SR perspective.

Cheers,
R.

On Wed, Jul 29, 2015 at 11:01 PM, Les Ginsberg (ginsberg) <
[email-masked]> wrote:

>  Stephane –
> ​​
> vendors – the YANG model should be architecturally correct)
>
>
>
>    Les
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 29 Jul 2015 22:28:56 +0000

Robert -

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, July 29, 2015 2:45 PM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]; Uma Chunduri; Aissaoui, Mustapha (Mustapha); [email-masked]; Shraddha Hegde ([email-masked]); Pushpasis Sarkar ([email-masked]); Hannes Gredler ([email-masked])
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Les,

However architecturally:

However at least looking at group of folks who claim that it is impossible to get same SRGB block in *any* network between two or more vendors  I think Stephane's intention would be to at least get it per one protocol even if platform wide the intersecting pool may be mission impossible.

[Les:] This is an unrelated issue. Placing SRGB in global context does not mean all routers have to have the same SRGB. There is no controversy here.

and now operationally:

Another reason would be idea of dual overlapping SRGBs perhaps quite useful during migrations between protocols where the exact same SRGB is set on both then just based on admin distance one vs the other protocol is chosen. While a standard practice in protocol migrations not sure if anyone looked at that from SR perspective.
[Les:] Not sure what you are trying to say. If the two SRGBs are the same – why do we need to configure them per protocol?
If the two SRGBs are not the same, other routers in the network have  no idea which protocol is going to win on your box. So your neighbor has no idea whether it should use the SRGB advertised by OSPF or the SRGB advertised by IS-IS.

   Les

Cheers,
R.

On Wed, Jul 29, 2015 at 11:01 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Stephane –

(I am not talking about what may or may not have been implemented by vendors – the YANG model should be architecturally correct)

   Les

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 30 Jul 2015 00:03:38 +0000

On Jul 29, 2015, at 6:28 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

Robert -

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, July 29, 2015 2:45 PM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]<mailto:[email-masked]>; Uma Chunduri; Aissaoui, Mustapha (Mustapha); [email-masked]<mailto:[email-masked]>; Shraddha Hegde ([email-masked]<mailto:[email-masked]>); Pushpasis Sarkar ([email-masked]<mailto:[email-masked]>); Hannes Gredler ([email-masked]<mailto:[email-masked]>)
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Les,

However architecturally:

and now operationally:

Actually, if the same prefix in the same topology is advertised by two protocols, I would think that the SID should map to the same label. I see no advantage at all in having separate labels.

Acee

   Les

Cheers,
R.

   Les

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 30 Jul 2015 06:15:43 +0000

Hi Les,

From: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 29, 2015 at 11:01 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Uma Chunduri <[email-masked]<mailto:[email-masked]>>, "Aissaoui, Mustapha (Mustapha)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Shraddha Hegde <[email-masked]<mailto:[email-masked]>>, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>, Hannes Gredler <[email-masked]<mailto:[email-masked]>>
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).

   Les

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, July 29, 2015 5:11 AM
To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); [email-masked]<mailto:[email-masked]>; Shraddha Hegde ([email-masked]<mailto:[email-masked]>); Pushpasis Sarkar ([email-masked]<mailto:[email-masked]>); Hannes Gredler ([email-masked]<mailto:[email-masked]>)
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi all,

Stephane

--
Uma C.

Thank you.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 30 Jul 2015 06:22:17 +0000

HI Acee,

From: "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 30, 2015 at 2:03 AM
To: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]>>, Stephane Litkowski <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Shraddha Hegde <[email-masked]<mailto:[email-masked]>>, Uma Chunduri <[email-masked]<mailto:[email-masked]>>, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>, "Aissaoui, Mustapha (Mustapha)" <[email-masked]<mailto:[email-masked]>>, Hannes Gredler <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Robert -

Hi Les,

However architecturally:

and now operationally:

Actually, if the same prefix in the same topology is advertised by two protocols, I would think that the SID should map to the same label. I see no advantage at all in having separate labels.
[Pushpasis] We are talking about the MPLS transit label for the destination FEC here. Like RSVP and LDP, in MPLS data plane today, the FEC maybe same but the transit label allocated by each protocol are different. Similarly for SR mapped to MPLS data plane the transit label allocated by ISIS and OSPF for the same destination FEC should be different. Hence the need of per-protocol SRGB.

Acee

   Les

Cheers,
R.

   Les

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 30 Jul 2015 06:48:21 +0000

Les/Acee,

I believe that it's useful to keep the labels separate for the protocols especially for operational reasons.
As Robert mentioned, protocol migrations is an important operational scenario to be considered.

Protocol migrations are generally done using "ships in the night"  model where both protocols are run with
One protocol being preferred over the other. Migration exercises in the past  have shown that the two protocols
Sometimes differ in their behavior due to inconsistencies in implementation.

I think operators should have a choice of "choosing separate SRGBs for protocols" if they want to and support
It in the YANG data model.

Rgds
Shraddha

From: Pushpasis Sarkar
Sent: Thursday, July 30, 2015 11:46 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]; Uma Chunduri <[email-masked]>; Aissaoui, Mustapha (Mustapha) <[email-masked]>; [email-masked]; Shraddha Hegde <[email-masked]>; Hannes Gredler <[email-masked]>
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Les,

Stephane -

   Les

Hi all,

Stephane

--
Uma C.

Thank you.

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 30 Jul 2015 06:58:02 +0000

Les,

Pls see inline…

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Thursday, July 30, 2015 3:59 AM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]; Uma Chunduri <[email-masked]>; Aissaoui, Mustapha (Mustapha) <[email-masked]>; [email-masked]; Shraddha Hegde <[email-masked]>; Pushpasis Sarkar <[email-masked]>; Hannes Gredler <[email-masked]>
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Robert -

Hi Les,

However architecturally:

and now operationally:

[Shraddha] route preference is local to router and the neighbor never knows what the other is going to choose.  If there are inconsistencies in two protocols, there are going to be loops even when they use same SRGB. Keeping different labels makes it easier to troubleshoot.

   Les

Cheers,
R.

   Les

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 30 Jul 2015 07:11:06 +0000

+1

From: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 30, 2015 at 8:58 AM
To: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Uma Chunduri <[email-masked]<mailto:[email-masked]>>, "Aissaoui, Mustapha (Mustapha)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>, Hannes Gredler <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 30 Jul 2015 07:46:35 +0000

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-masked]]
Sent: Wednesday, July 29, 2015 11:16 PM
To: Les Ginsberg (ginsberg); [email-masked]; Uma Chunduri; Aissaoui, Mustapha (Mustapha); [email-masked]; Shraddha Hegde; Hannes Gredler
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Les,

Stephane -

   Les

Hi all,

Stephane

--
Uma C.

Thank you.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 30 Jul 2015 08:24:45 +0000

Hi Les,

From: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 30, 2015 at 9:46 AM
To: Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Uma Chunduri <[email-masked]<mailto:[email-masked]>>, "Aissaoui, Mustapha (Mustapha)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Shraddha Hegde <[email-masked]<mailto:[email-masked]>>, Hannes Gredler <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Pushpassis –

It is clear to me that what you propose is more complex to implement and more costly in its consumption of labels.
[Pushpasis] I read through the entire repsponse and I still don’t see why you think this is complex. Also, while distributing from one protocol to another you may want to attach another index with the FEC (in scenarios when you want to keep the index-management of destination protocol independent of the index-management of soruce protocol). Having per-protcol SRGB opens up lots of possibilities. One more point, you are only talking about the IP-route on the ingress box. We need to also consider the MPLS transit labels on transit boxes downloaded by each protocol. Shraddha in a previous thread has already pointed out cases with ‘ships in the night’ mode of migration from one protocol to another where this simplifies the micgration without causing any unwanted loops.

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.
[Pushpasis] One such example (migration from one protocol to another) has already been mentioned by Shraddha. But I can come with another example with BGP-LU prefix segment in Datacenter. A boundary router (between DCN and the DCI) will be running SR on two protocols
— BGP-LU towards the home DCN as well as to the boubdray routers on remote DCNs across the DCI
— ISIS/OSPF with all the routers within the DCI.
If we have to keep the index management of DCNs independent of the index-management of DCI (I.e. Same index can be used on DCN as well as DCI) we need to make sure the transit label allocated on the boundary router by BGP-LU for a destination in DCN is separate from the transit label allocated by ISIS/OSPF for another destination in DCI network, even though BGP-LU and ISIS may use the same index for these two different destination routers.

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.
[Pushpasis] I still don’t get what added complexity is involved here. How does it matter if the label-manager has to manage 1 partition or N partitions? The complexity involved is same. I agree that we will need added labels, but if you see, we will need to enable SR on multiple protocols, only in the following cases. I cannot foresee any other scenarios as of now.
— Migrating from IGP1to IGP2.
— Border routers in MSDC environment running BGP-LU + some IGP.

[Pushpasis]

  1.  Index-management in a one protocol can be completely independent of the index-mamagement in another protocol even if the same router participates in multiple protocols with different topologies.
  2.  Eases debuggability and avoids routing loops in case of migration scenarios

Thanks
-Pushpasis

   Les

From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: Wednesday, July 29, 2015 11:16 PM
To: Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>; Uma Chunduri; Aissaoui, Mustapha (Mustapha); [email-masked]<mailto:[email-masked]>; Shraddha Hegde; Hannes Gredler
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Les,

Stephane –

   Les

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, July 29, 2015 5:11 AM
To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); [email-masked]<mailto:[email-masked]>; Shraddha Hegde ([email-masked]<mailto:[email-masked]>); Pushpasis Sarkar ([email-masked]<mailto:[email-masked]>); Hannes Gredler ([email-masked]<mailto:[email-masked]>)
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

>the instruction is completely unnecessary – it simply wastes label space.

--
Uma C.

Thank you.

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 30 Jul 2015 09:04:31 +0000

Les,

The example that you gave about redistribution of routes from one protocol to another could be result of two different organizations merging into one.
These networks being managed by different entities in the past may have same index assigned to nodes and different SRGBs configured
in their respective domains. Operationally, it is easier to configure different SRGBs to the two different protocols that they run than mess with
Indexes and SRGBs in an attempt to get same SRGB across two protocols.

I don't think there is anything wrong architecturally, to have separate labels for different protocols.
I believe there should be flexibility and choice for operators to configure the networks. If someone wants to deploy same SRGB for
Different protocols or different SRGB for different protocols, the options should be available  and providing such an option in YANG model is well justified.

Rgds
Shraddha

From: Pushpasis Sarkar
Sent: Thursday, July 30, 2015 1:55 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]; Uma Chunduri <[email-masked]>; Aissaoui, Mustapha (Mustapha) <[email-masked]>; [email-masked]; Shraddha Hegde <[email-masked]>; Hannes Gredler <[email-masked]>
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Les,

Pushpassis -

It is clear to me that what you propose is more complex to implement and more costly in its consumption of labels.
[Pushpasis] I read through the entire repsponse and I still don't see why you think this is complex. Also, while distributing from one protocol to another you may want to attach another index with the FEC (in scenarios when you want to keep the index-management of destination protocol independent of the index-management of soruce protocol). Having per-protcol SRGB opens up lots of possibilities. One more point, you are only talking about the IP-route on the ingress box. We need to also consider the MPLS transit labels on transit boxes downloaded by each protocol. Shraddha in a previous thread has already pointed out cases with 'ships in the night' mode of migration from one protocol to another where this simplifies the micgration without causing any unwanted loops.

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.
[Pushpasis] One such example (migration from one protocol to another) has already been mentioned by Shraddha. But I can come with another example with BGP-LU prefix segment in Datacenter. A boundary router (between DCN and the DCI) will be running SR on two protocols
- BGP-LU towards the home DCN as well as to the boubdray routers on remote DCNs across the DCI
- ISIS/OSPF with all the routers within the DCI.
If we have to keep the index management of DCNs independent of the index-management of DCI (I.e. Same index can be used on DCN as well as DCI) we need to make sure the transit label allocated on the boundary router by BGP-LU for a destination in DCN is separate from the transit label allocated by ISIS/OSPF for another destination in DCI network, even though BGP-LU and ISIS may use the same index for these two different destination routers.

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.
[Pushpasis] I still don't get what added complexity is involved here. How does it matter if the label-manager has to manage 1 partition or N partitions? The complexity involved is same. I agree that we will need added labels, but if you see, we will need to enable SR on multiple protocols, only in the following cases. I cannot foresee any other scenarios as of now.
- Migrating from IGP1to IGP2.
- Border routers in MSDC environment running BGP-LU + some IGP.

Thanks
-Pushpasis

   Les

Hi Les,

Stephane -

   Les

Hi all,

Stephane

--
Uma C.

Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 30 Jul 2015 11:18:53 +0200

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-masked]
> 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.
>
>
>
> 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.
>
>
>
> *From:* Pushpasis Sarkar [mailto:[email-masked]]
> *Sent:* Wednesday, July 29, 2015 11:16 PM
> *To:* Les Ginsberg (ginsberg); [email-masked]; Uma
> Chunduri; Aissaoui, Mustapha (Mustapha); [email-masked]; Shraddha Hegde;
> Hannes Gredler
> *Subject:* Re: [spring] Modeling SRGB configuration for
> *From: *"Les Ginsberg (ginsberg)" <[email-masked]>
> *Date: *Wednesday, July 29, 2015 at 11:01 PM
> *To: *"[email-masked]" <[email-masked]>,
> Uma Chunduri <[email-masked]>, "Aissaoui, Mustapha (Mustapha)"
> <[email-masked]>, "[email-masked]" <[email-masked]>,
> Shraddha Hegde <[email-masked]>, Pushpasis Sarkar <
> [email-masked]>, Hannes Gredler <[email-masked]>
> *Subject: *RE: [spring] Modeling SRGB configuration for
> [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:
>
>  I prefer option 2, as the operator does not need to maintain two
> different index ranges (one per-protocol).
>
>
>
> *From:* [email-masked] [
> mailto:[email-masked] <[email-masked]>]
> Pushpasis Sarkar ([email-masked]); Hannes Gredler ([email-masked]
> )
> 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-masked]
> <[email-masked]>]
> *To:* Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI
> Stephane SCE/IBNF; [email-masked]
> >Suggesting that the forwarding instruction (AKA label)  needs to be
> different depending on what protocol provided
>
> 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.
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 30 Jul 2015 13:16:59 +0000

Hi Pushpasis,

On Jul 30, 2015, at 2:22 AM, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>> wrote:

HI Acee,

Robert -

Hi Les,

However architecturally:

and now operationally:

Actually, if the same prefix in the same topology is advertised by two protocols, I would think that the SID should map to the same label. I see no advantage at all in having separate labels.
[Pushpasis] We are talking about the MPLS transit label for the destination FEC here. Like RSVP and LDP, in MPLS data plane today, the FEC maybe same but the transit label allocated by each protocol are different.

This is not  a good analogy. LDP normally follows the IP routed path while RSVP is used to set up a TE engineered path.

Similarly for SR mapped to MPLS data plane the transit label allocated by ISIS and OSPF for the same destination FEC should be different. Hence the need of per-protocol SRGB.

This is a circular argument. Why would the IP unicast routed path require a different label for ISIS vs OSPF?

Acee

Acee

   Les

Cheers,
R.

   Les

---

From: <[email-masked]>
Date: Thu, 30 Jul 2015 13:18:43 +0000

As mentioned by others, there may be some operational gain.
IGP migration example given is a good example, today with pure IP, there's some tricky cases because we need to manage it with admin distance and their may be some differences in best path computation between IGPs (implementation dependant, but it's a reality).
Here we have the opportunity to overcome this issue by letting the possibility to create two parallel forwarding planes using different labels. I agree that it consumes twice the number of required label, but it may be a transient solution (for migration case) and also it's a design choice of the operator.
The last comment from Robert of virtualization , especially using containers or part of router OS running on COTS (just OSPF or ISIS or BGP code), may require some more independency between router software components.

Now from an architectural perspective, what is Segment Routing ?
Segment routing is just an architecture, like MPLS is. We see that segment routing has more and more controlplanes (ISIS and OSPF first, now BGP ...), like MPLS does. Moreover using segment routing in an MPLS environment leads to adding new controlplanes to MPLS.
So I like the comment from Pushpasis talking about BGP, LDP, RSVP which are different controlplane of MPLS. Do we advertise the same label value for the same prefix FEC advertised in LDP, BGP and RSVP ? No ... so why doing it with OSPF and ISIS ?

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Wednesday, July 29, 2015 23:01
To: LITKOWSKI Stephane SCE/IBNF; Uma Chunduri; Aissaoui, Mustapha (Mustapha); [email-masked]; Shraddha Hegde ([email-masked]); Pushpasis Sarkar ([email-masked]); Hannes Gredler ([email-masked])
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Stephane -

   Les

Hi all,

Stephane

--
Uma C.

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 30 Jul 2015 13:48:13 +0000

Robert, Pushpasis, Shraddha,

I guess I don’t understand why this gives you any operational advantage when you are migrating between protocol (e.g., from IS-IS to OSPF ;^). In fact, if you are using separate label spaces it will make migration more difficult and you will have to migrate your routing domain in shot rather than incrementally.

Thanks,
Acee

On Jul 30, 2015, at 3:11 AM, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>> wrote:

+1

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 30 Jul 2015 14:54:23 +0000

Hi Acee,

From: "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 30, 2015 at 7:18 PM
To: Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>
Cc: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>, "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>, "Aissaoui, Mustapha (Mustapha)" <[email-masked]<mailto:[email-masked]>>, Stephane Litkowski <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Uma Chunduri <[email-masked]<mailto:[email-masked]>>, Hannes Gredler <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

I guess I don't understand why this gives you any operational advantage when you are migrating between protocol (e.g., from IS-IS to OSPF ;^). In fact, if you are using separate label spaces it will make migration more difficult and you will have to migrate your routing domain in shot rather than incrementally.
[Pushpasis] All routers will program both transit mpls labels and create two parallel MPLS data planes well before the last step when all the ingress router will be instructed to switch traffic onto the new MPLS data plane (programmed by the new protocol) by changing the admin distance. That way the migration shall become seamless. And then once all ingreess routers has been swicthed to the new protocol and new MPLS dataplane, the old protocol and old MPLS data plane can be just removed from all the routers. Hope it is clear now...

Thanks,
Acee

+1

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 30 Jul 2015 15:07:18 +0000

Hi Pushpasis,

On Jul 30, 2015, at 10:54 AM, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>> wrote:

Hi Acee,

I guess I don’t understand why this gives you any operational advantage when you are migrating between protocol (e.g., from IS-IS to OSPF ;^). In fact, if you are using separate label spaces it will make migration more difficult and you will have to migrate your routing domain in shot rather than incrementally.
[Pushpasis] All routers will program both transit mpls labels and create two parallel MPLS data planes well before the last step when all the ingress router will be instructed to switch traffic onto the new MPLS data plane (programmed by the new protocol) by changing the admin distance. That way the migration shall become seamless. And then once all ingreess routers has been swicthed to the new protocol and new MPLS dataplane, the old protocol and old MPLS data plane can be just removed from all the routers. Hope it is clear now…

Normally only the protocol with the lower preference or admin distance would install a route to a particular prefix (including the label) into the RIB/LIB for the base IP unicast topology. I guess you are envisioning separate RIBs per protocol as well?

Thanks,
Acee

Thanks,
Acee

+1

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 30 Jul 2015 15:11:54 +0000

Hi Acee,

Date: Thursday, July 30, 2015 at 8:37 PM

Hi Pushpasis,

Hi Acee,

Normally only the protocol with the lower preference or admin distance would install a route to a particular prefix (including the label) into the RIB/LIB for the base IP unicast topology. I guess you are envisioning separate RIBs per protocol as well?
[Pushpasis] What you are saying is true for the IP/V6->MPLS route in RIB/FIB on ingress routers. It is NOT TRUE for MPLS transit routes in LFIB. In MPLS architecture no two protocols installs the same label in LFIB. Each protocol (LDP/RSVP) uses different transit labels for the same destination IP/V6 FEC.

Thanks,
Acee

Thanks,
Acee

+1

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 30 Jul 2015 16:13:57 +0000

Hi Pushpasis,

On Jul 30, 2015, at 11:11 AM, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>> wrote:

Hi Acee,

Hi Pushpasis,

Hi Acee,

Normally only the protocol with the lower preference or admin distance would install a route to a particular prefix (including the label) into the RIB/LIB for the base IP unicast topology. I guess you are envisioning separate RIBs per protocol as well?
[Pushpasis] What you are saying is true for the IP/V6—>MPLS route in RIB/FIB on ingress routers. It is NOT TRUE for MPLS transit routes in LFIB. In MPLS architecture no two protocols installs the same label in LFIB. Each protocol (LDP/RSVP) uses different transit labels for the same destination IP/V6 FEC.

That is one way to implement it but it makes more sense for the IGP label imposition and label stitching to both be dependent on the route being preferred.
However, in another conversation I have been convinced that the network consolidation use case could benefit from configuration of per-protocol SRGB so I’m no longer opposed to this being a feature of the YANG model.

Thanks,
Acee

Thanks,
Acee

Thanks,
Acee

+1

---

From: "Hannes Gredler ([email-masked])" <[email-masked]>
Date: Fri, 31 Jul 2015 16:01:53 +0200

one further point is that implementations MAY reuse exisiting MPLS label-managing
software for SR. label-management software has often this label-per-client (singular)
and not-label-per-clients (plural) bookkeeping in the sense that it
cannot track multiple 'owners' of a certain label value.

it would be interesting to hear from other implementers if their software
can easily track 'multiple client' ownership per label (and if not) what
are the implications to non-SR code-paths e.g. graceful restart scenarios ?

/hannes

On Thu, Jul 30, 2015 at 01:18:43PM +0000, [email-masked] wrote:
|    As mentioned by others, there may be some operational gain.
| 
|    IGP migration example given is a good example, today with pure IP, there's
|    some tricky cases because we need to manage it with admin distance and
|    their may be some differences in best path computation between IGPs
|    (implementation dependant, but it's a reality).
| 
|    Here we have the opportunity to overcome this issue by letting the
|    possibility to create two parallel forwarding planes using different
|    labels. I agree that it consumes twice the number of required label, but
|    it may be a transient solution (for migration case) and also it's a design
|    choice of the operator.
| 
|    The last comment from Robert of virtualization , especially using
|    containers or part of router OS running on COTS (just OSPF or ISIS or BGP
|    code), may require some more independency between router software
|    components.
| 
| 
| 
| 
| 
|    Now from an architectural perspective, what is Segment Routing ?
| 
|    Segment routing is just an architecture, like MPLS is. We see that segment
|    routing has more and more controlplanes (ISIS and OSPF first, now BGP
|    ...), like MPLS does. Moreover using segment routing in an MPLS
|    environment leads to adding new controlplanes to MPLS.
| 
|    So I like the comment from Pushpasis talking about BGP, LDP, RSVP which
|    are different controlplane of MPLS. Do we advertise the same label value
|    for the same prefix FEC advertised in LDP, BGP and RSVP ? No ... so why
|    doing it with OSPF and ISIS ?
| 
| 
| 
| 
| 
|    From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
|    Sent: Wednesday, July 29, 2015 23:01
|    To: LITKOWSKI Stephane SCE/IBNF; Uma Chunduri; Aissaoui, Mustapha
|    (Mustapha); [email-masked]; Shraddha Hegde ([email-masked]);
|    Pushpasis Sarkar ([email-masked]); Hannes Gredler
|    ([email-masked])
|    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.
| 
| 
| 
|    (I am not talking about what may or may not have been implemented by
|    vendors - the YANG model should be architecturally correct)
| 
| 
| 
|       Les
| 
| 
| 
| 
| 
|    From: [1][email-masked]
|    [[2]mailto:[email-masked]]
|    Sent: Wednesday, July 29, 2015 5:11 AM
|    To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha);
|    [3][email-masked]; Shraddha Hegde ([4][email-masked]); Pushpasis
|    Sarkar ([5][email-masked]); Hannes Gredler ([6][email-masked])
|    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 [[7]mailto:[email-masked]]
|    Sent: Friday, July 24, 2015 16:59
|    To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI
|    Stephane SCE/IBNF; [8][email-masked]
|    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.
| 
|  _________________________________________________________________________________________________________________________
| 
|  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.
| 
| References
| 
|    Visible links
|    1. mailto:[email-masked]
|    2. mailto:[email-masked]
|    3. mailto:[email-masked]
|    4. mailto:[email-masked]
|    5. mailto:[email-masked]
|    6. mailto:[email-masked]
|    7. mailto:[email-masked]
|    8. mailto:[email-masked]

---

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

Robert –

Labels are a shared resource – the problem you mention below has to be addressed independent of how many SRGBs are used in any solution. No protocol implementation – whether part of a monolithic router product or an independent implementation – can assume that it has free rein to use whatever SRGB range it wants.

   Les

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, July 30, 2015 2:19 AM
To: Les Ginsberg (ginsberg)
Cc: Pushpasis Sarkar; [email-masked]; [email-masked]; Shraddha Hegde; Hannes Gredler
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

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-masked]<mailto:[email-masked]>> 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.

   Les

From: Pushpasis Sarkar [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, July 29, 2015 11:16 PM
To: Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>; Uma Chunduri; Aissaoui, Mustapha (Mustapha); [email-masked]<mailto:[email-masked]>; Shraddha Hegde; Hannes Gredler
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Les,

Stephane –

   Les

Hi all,

Stephane

--
Uma C.

Thank you.

---

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

Hannes -

As a datapoint, we are able to successfully manage a reserved label space among multiple SR clients.

As regards GR I am not sure why you think SR introduces new requirements. If your forwarding plane is to be persistent (NSF) then the router has to have a way of supporting label persistence across control plane restarts. In this context SR clients should be making use of whatever infrastructure already exists to support label persistence. What do you think is new here?

What is more problematic is supporting multiple labels for the same prefix - which is one of the consequences of the per-protocol SRGB approach. I am not saying this is unsupportable - just that it is a more difficult problem to solve. I would be interested in other implementation experience on this point.

   Les

> -----Original Message-----
> From: Hannes Gredler ([email-masked]) [mailto:[email-masked]]
> Sent: Friday, July 31, 2015 7:02 AM
> To: [email-masked]
> Cc: Les Ginsberg (ginsberg); Uma Chunduri; Aissaoui, Mustapha (Mustapha);
> [email-masked]; Shraddha Hegde ([email-masked]); Pushpasis Sarkar
> ([email-masked])
> one further point is that implementations MAY reuse exisiting MPLS label-
> managing software for SR. label-management software has often this label-
> per-client (singular) and not-label-per-clients (plural) bookkeeping in the
> sense that it cannot track multiple 'owners' of a certain label value.
> 
> it would be interesting to hear from other implementers if their software can
> easily track 'multiple client' ownership per label (and if not) what are the
> implications to non-SR code-paths e.g. graceful restart scenarios ?
> 
> /hannes
> 
> __________________________________________________________
> ____________
> | ___________________________________________________
> |
> |
> |
> |  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,
> |
> |  This message and its attachments may contain confidential or
> | privileged information that may be protected by law;
> |
> __________________________________________________________
> ____________
> | ___________________________________________________
> |
> |  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,
> |  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.