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

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 3 Aug 2015 10:13:56 +0000

Hi Les,	

On 8/1/15, 4:56 AM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

>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.
[Pushpasis] If we can support multiple protocol routes (each providing an
IP next hop) per IP prefix, I don¹t see why there should be problem
supporting multiple protocol routes (each providing a labeled next hop)
for the same IP prefix.

Thanks
-Pushpasis

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 3 Aug 2015 10:41:27 +0000

Hi Pushpasis, 

>supporting multiple protocol routes (each providing a labeled next hop)

In the simple next-hop case, only the most preferred protocol (lowest
admin distance or precedence) route will be installed in the data plane.
If I understand correctly, in this case the most preferred protocol would
install the NHLFE and a cross-connect. Additionally, other less preferred
protocols would install additional cross-connects using different labels.
Correct? 

Thanks,
Acee

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

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 3 Aug 2015 11:19:35 +0000

Hi Acee,

>admin distance or precedence) route will be installed in the data plane.
[Pushpasis] You are right as long the route we are talking is the IP/V6
prefix applicable on the ingress which encapsulates an incoming IP/V6
packet into the MPLS packet. What we are saying is that all routers
participating in SR with multiple protcols (whenever there is at all a
need) can setup parallel MPLS data planes and the ingress can inject the
incoming IP/V6 packets into a MPLS data plane of their choice indicated by
the protocol preference.

>protocols would install additional cross-connects using different labels.
[Pushpasis] Yes that is correct for a given ingress router. However if the
protocol preference is different on different ingress routers (which might
be the case in migration scenarios) they are pushed in using different
MPLS labels.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 3 Aug 2015 15:35:08 +0000

Pushpasis -

Your descriptions are not accurately reflecting what is required. This isn't about multiple protocols contributing a next hop to the same route (which in itself is not normal behavior and can potentially cause loops) - nor is it about different protocols being the best route on different routers.

Let's take a simple example:

I have network A running IS-IS. It uses default SRGB (16000-23999) and has assigned SIDs (0-100) to the prefixes it is advertising.

I have network B running OSPF. It also uses default SRGB (16000-23999) and has also assigned SIDs (0 - 100) to the prefixes it is advertising.

To make things simple assume Network A and Network B have no IP address /subnet conflicts. (If they do the conflicts  would have to be resolved first.)

Now you want to merge the two networks into one. And - at least at first - you don't want to have to migrate routing protocols in either network nor have to reassign SIDs for the existing prefixes. So, what do you do?

You connect the two networks via one or more ABRs. On these ABRs you run an instance of both IS-IS and OSPF - enabled on the interfaces connected to Network A and Network B respectively. And you redistribute routes between the two protocols. But - you have a problem. The SID for Network B address 2.2.2.2/32 is 10 (for example). But this SID has already been assigned to 1.1.1.1/32 in Network A. So when IS-IS advertises 2.2.2.2/32 it cannot advertise SID 10 - it has to advertise a different SID - let's say that it is 210. (There are various ways to assign that SID - we don't have to specify that here.) But since traffic for 2.2.2.2/32 will be arriving at the ABR from Network A routers with SID 210 there has to be an entry in the forwarding plane for both SID 210 and SID 10 that will forward the traffic to the interface specified by OSPF (which is the ONLY protocol installing a route in the RIB for 2.2.2.2/32 on the ABR). So not only does the forwarding plane have to support this - but the destination protocol for redistribution (IS-IS in this example) has to install the label associated w SID 210 NOT because it is installing a path into the RIB - but simply because it is advertising a redistributed route.

Now, is all of this possible? Yes...but certainly is not a trivial issue to address. And, for the operators, they have the complication of having multiple SIDs, multiple labels, and possibly multiple SRGBs associated with a single prefix.

Maybe all of this is still desirable i.e., the benefits of being able to merge two networks w/o having to address SID conflicts is worth it - that is a judgment call on which the operators need to provide some insight. 

I am willing to allow - as Acee's post from last week mentioned - that this might be a useful thing - but let's not  make the mistake of treating this as a simple case - nor as the way that is most desirable to run networks. 

   Les

> -----Original Message-----
> From: Pushpasis Sarkar [mailto:[email-masked]]
> Sent: Monday, August 03, 2015 3:14 AM
> To: Les Ginsberg (ginsberg); Hannes Gredler;
> [email-masked]
> Cc: Uma Chunduri; Aissaoui, Mustapha (Mustapha); [email-masked];
> Shraddha Hegde
> Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-
> yang
> 
> Hi Les,
> 
> >approach. I am not saying this is unsupportable - just that it is a
> >more difficult problem to solve.
> [Pushpasis] If we can support multiple protocol routes (each providing an IP
> next hop) per IP prefix, I don¹t see why there should be problem supporting
> multiple protocol routes (each providing a labeled next hop) for the same IP
> prefix.
> 
> Thanks
> -Pushpasis
> >

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 4 Aug 2015 06:40:30 +0000

Hi Les,

I see that you have taken the network consolidation as the example :)
Please find some more comments inline..

Thanks
-Pushpasis

On 8/3/15, 9:05 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

>Pushpasis -
>
>Your descriptions are not accurately reflecting what is required. This
>isn't about multiple protocols contributing a next hop to the same route
>(which in itself is not normal behavior and can potentially cause loops)
>- nor is it about different protocols being the best route on different
>routers.
>
>I have network A running IS-IS. It uses default SRGB (16000-23999) and
>has assigned SIDs (0-100) to the prefixes it is advertising.
>
>I have network B running OSPF. It also uses default SRGB (16000-23999)
>and has also assigned SIDs (0 - 100) to the prefixes it is advertising.
>
>To make things simple assume Network A and Network B have no IP address
>/subnet conflicts. (If they do the conflicts  would have to be resolved
>first.)
>
>Now you want to merge the two networks into one. And - at least at first
>- you don't want to have to migrate routing protocols in either network
>nor have to reassign SIDs for the existing prefixes. So, what do you do?
>
>You connect the two networks via one or more ABRs. On these ABRs you run
>an instance of both IS-IS and OSPF - enabled on the interfaces connected
>to Network A and Network B respectively. And you redistribute routes
>between the two protocols. But - you have a problem. The SID for Network
>B address 2.2.2.2/32 is 10 (for example). But this SID has already been
>assigned to 1.1.1.1/32 in Network A. So when IS-IS advertises 2.2.2.2/32
>it cannot advertise SID 10 -

[Pushpasis] Adding a diagram to illustrate the scenario you explained
above..

|-----Network A(ISIS) SRGB:16000-23999------|-----Network B(OSPF)
SRGB:16000-23999-----|

SID:10	SID:10
1.1.1.1/32	2.2.2.2/32
D1--------------------N1------ABR------N2---------------------D2

In our proposal for handling network consolidation scenario, what Shraddha
and I proposed was to change the SRGB range for one of the networks
without needing to change the SID indexes. To understand why that is
needed, consider the MPLS transit routes on the ABR in the above example.
Following are MPLS transit routes applicable on ABR.

 ISIS: Incoming label 16010, Swap 16010, Fwd to N1,
 OSPF: Incoming label 16010, Swap 16010, Fwd to N2

The above two are conflicting entries. In certain implementations, having
two route entries for the same incoming label is not even possible.
However if we change the SRGB on network B to 24000-31999, then we have
two different transit routes.

 ISIS: Incoming label 16010, Swap 16010, Fwd to N1
 OSPF: Incoming label 24010, Swap 24010, Fwd to N2

The above two entries can now easily co-exist in the FIB on ABR.

>it has to advertise a different SID - let's say that it is 210. (There
>are various ways to assign that SID - we don't have to specify that
>here.) But since traffic for 2.2.2.2/32 will be arriving at the ABR from
>Network A routers with SID 210 there has to be an entry in the forwarding
>plane for both SID 210 and SID 10 that will forward the traffic to the
>interface specified by OSPF (which is the ONLY protocol installing a
>route in the RIB for 2.2.2.2/32 on the ABR). So not only does the
>forwarding plane have to support this - but the destination protocol for
>redistribution (IS-IS in this example) has to install the label
>associated w SID 210 NOT because it is installing a path into the RIB -
>but simply because it is advertising a redistributed route.

[Pushpasis] I agree that when 2.2.2.2/32(SID 10) from network B is
re-advertised/re-distributed to network A, it needs to be assigned another
unique SID (210 in your example). Also, such advertisement will go with
No-PHP flag set (to 1). So when a source from network A tries to reach
2.2.2.2/32 it will send the packet with the label 16210 (and not 16010).
And since SID 210 was advertised with No-PHP=1, the packet will reach ABR
with the label 16210. The same route entry should already have been
programmed on ABR as follows.

 ISIS: Incoming label 16210, Swap 24010, Fwd to N2

Similarly if 1.1.1.1/32(SID 10) from network A is
re-advertised/re-distributed to network B, it may be assigned another
unique SID (say again 210). The corresponding route entry on ABR should
look like.

 OSPF: Incoming label 24210, Swap 16010, Fwd to N1

Now coming to the IP-to-MPLS routes on ABR there should not be any
confusion, and they should look like..

 ISIS: Prefix: 1.1.1.1/32, Push 16010, Fwd to N1
 OSPF: Prefix: 2.2.2.2/32, Push 24010, Fwd to N2

>
>Now, is all of this possible? Yes...but certainly is not a trivial issue
>to address. And, for the operators, they have the complication of having
>multiple SIDs, multiple labels, and possibly multiple SRGBs associated
>with a single prefix.
>
>Maybe all of this is still desirable i.e., the benefits of being able to
>merge two networks w/o having to address SID conflicts is worth it - that
>is a judgment call on which the operators need to provide some insight.
[Pushpasis] IMO, it is easier for the operator to change all the nodes in
network B(or A) to a different single SRGB range without much overhead.

> 
>
>I am willing to allow - as Acee's post from last week mentioned - that
>this might be a useful thing - but let's not  make the mistake of
>treating this as a simple case - nor as the way that is most desirable to
>run networks.
[Pushpasis] I am fine with a instance-level SRGB range config knob as
well. In fact that is what I suggested in ISIS YANG design disucssion
meeting few months back. My suggestion was on the same lines as what Acee
mentioned in his mail (protocol-specific config overriding the
instance-level one).

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 4 Aug 2015 16:05:45 +0000

Pushpasis -

> Sent: Monday, August 03, 2015 11:40 PM
> I see that you have taken the network consolidation as the example :) Please
> find some more comments inline..
> 
> Thanks
> -Pushpasis
> 
> >isn't about multiple protocols contributing a next hop to the same
> >route (which in itself is not normal behavior and can potentially cause
> >loops)
> >You connect the two networks via one or more ABRs. On these ABRs you
> >run an instance of both IS-IS and OSPF - enabled on the interfaces
> >connected to Network A and Network B respectively. And you redistribute
> >routes between the two protocols. But - you have a problem. The SID for
> >Network B address 2.2.2.2/32 is 10 (for example). But this SID has
> >already been assigned to 1.1.1.1/32 in Network A. So when IS-IS
> >advertises 2.2.2.2/32 it cannot advertise SID 10 -
> 
> [Pushpasis] Adding a diagram to illustrate the scenario you explained above..
> 
> The above two are conflicting entries. In certain implementations, having two
> route entries for the same incoming label is not even possible.

[Les:] I agree that in addition to what I described one of the SRGBs has to be changed. So, let's see what we are left with:

The merge is done disruptively (because changing one of the SRGBs cannot be done hitlessly).
For each of  the prefixes which are advertised into both Network A and Network B we have:

1)Two different SIDs advertised
2)Two different labels installed in the forwarding plane
3)Two different SRGBs on a single node

Does this work? Yes - with some implementation extensions that I have previously described.
Is this easy to manage and troubleshoot? I will let others comment on that.
But certainly it is not as easy to manage and troubleshoot as a network where for each prefix we have:

1 SID
1 label installed in the forwarding plane
No SID mapping associated w redistribution
1 SRGB
Possibly even the same SRGB on all nodes

I have already acknowledged that if folks see the first alternative as useful then we should look at supporting it - but I think it is also important to note its complexity and insure that in order to handle this case that we do not abandon the much simpler use of a protocol independent SRGB.
I hope we can agree on that.

   Les

> >here.) But since traffic for 2.2.2.2/32 will be arriving at the ABR
> >from Network A routers with SID 210 there has to be an entry in the
> >forwarding plane for both SID 210 and SID 10 that will forward the
> >traffic to the interface specified by OSPF (which is the ONLY protocol
> >installing a route in the RIB for 2.2.2.2/32 on the ABR). So not only
> >does the forwarding plane have to support this - but the destination
> >protocol for redistribution (IS-IS in this example) has to install the
> >label associated w SID 210 NOT because it is installing a path into the
> >RIB - but simply because it is advertising a redistributed route.
> 
> [Pushpasis] I agree that when 2.2.2.2/32(SID 10) from network B is re-
> advertised/re-distributed to network A, it needs to be assigned another
> unique SID (210 in your example). Also, such advertisement will go with No-
> PHP flag set (to 1). So when a source from network A tries to reach
> Similarly if 1.1.1.1/32(SID 10) from network A is re-advertised/re-distributed
> to network B, it may be assigned another unique SID (say again 210). The
> corresponding route entry on ABR should look like.
> 
> >Now, is all of this possible? Yes...but certainly is not a trivial
> >issue to address. And, for the operators, they have the complication of
> >having multiple SIDs, multiple labels, and possibly multiple SRGBs
> >associated with a single prefix.
> >
> >Maybe all of this is still desirable i.e., the benefits of being able
> >to merge two networks w/o having to address SID conflicts is worth it -
> >that is a judgment call on which the operators need to provide some insight.
> >treating this as a simple case - nor as the way that is most desirable
> >to run networks.
> [Pushpasis] I am fine with a instance-level SRGB range config knob as well. In
> fact that is what I suggested in ISIS YANG design disucssion meeting few
> months back. My suggestion was on the same lines as what Acee mentioned
> in his mail (protocol-specific config overriding the instance-level one).
> 
> >
> >
> >   Les
> >
> >> [Pushpasis] If we can support multiple protocol routes (each
> >>providing an IP  next hop) per IP prefix, I don¹t see why there should
> >>be problem supporting  multiple protocol routes (each providing a
> >>labeled next hop) for the same IP  prefix.
> >>
> >> Thanks
> >> -Pushpasis
> >> >
> >

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 4 Aug 2015 19:07:02 +0200

Hi Les,

Wouldn't you agree that for Multi-topology or Multi_Instance you already
need multiple SIDs ?

Assuming that you support the above I find it a bit quite bizzare that you
are arguing for global SRGB rather then having this explicit under protocol
instance or topology.

Keep in mind that systems that decide for the operator on what ranges (from
global SRGB) are advertised where in a magical way are not that always that
welcome :)

Best,
r.

On Tue, Aug 4, 2015 at 6:05 PM, Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> [Les:] I agree that in addition to what I described one of the SRGBs has
> to be changed. So, let's see what we are left with:
>
> I have already acknowledged that if folks see the first alternative as
> useful then we should look at supporting it - but I think it is also
> important to note its complexity and insure that in order to handle this
> case that we do not abandon the much simpler use of a protocol independent
> SRGB.
> No-
> re-advertised/re-distributed
> well. In

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 4 Aug 2015 19:07:53 +0000

Robert –

I fail to see the relevance of your comments.

Yes – SR supports/requires different SIDs/topology. But topologies are NOT protocol specific. The “base unicast topology” which is implied when we talk outside the context of MT is the glaring example of that.

As for “magic” – please point out one word or phrase in this entire discussion (either by myself or Pushpasis) that has suggested that SRGBs are defined in a way which is outside of the operator’s control.

   Les

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, August 04, 2015 10:07 AM
To: Les Ginsberg (ginsberg)
Cc: Pushpasis Sarkar; Hannes Gredler; [email-masked]; Aissaoui, Mustapha (Mustapha); [email-masked]; Uma Chunduri; Shraddha Hegde
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Les,

Wouldn't you agree that for Multi-topology or Multi_Instance you already need multiple SIDs ?

Assuming that you support the above I find it a bit quite bizzare that you are arguing for global SRGB rather then having this explicit under protocol instance or topology.

Keep in mind that systems that decide for the operator on what ranges (from global SRGB) are advertised where in a magical way are not that always that welcome :)

Best,
r.

On Tue, Aug 4, 2015 at 6:05 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Pushpasis -

> From: Pushpasis Sarkar [mailto:[email-masked]<mailto:[email-masked]>]
> [email-masked]<mailto:[email-masked]>
> Cc: Uma Chunduri; Aissaoui, Mustapha (Mustapha); [email-masked]<mailto:[email-masked]>;
> Shraddha Hegde
> On 8/3/15, 9:05 PM, "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>> wrote:
>
> >Pushpasis -
> >
> >Network B address 2.2.2.2/32<http://2.2.2.2/32> is 10 (for example). But this SID has
> >already been assigned to 1.1.1.1/32<http://1.1.1.1/32> in Network A. So when IS-IS
> >advertises 2.2.2.2/32<http://2.2.2.2/32> it cannot advertise SID 10 -
>
> 1.1.1.1/32<http://1.1.1.1/32>    2.2.2.2/32<http://2.2.2.2/32>

1 SID

   Les

> >here.) But since traffic for 2.2.2.2/32<http://2.2.2.2/32> will be arriving at the ABR
> >installing a route in the RIB for 2.2.2.2/32<http://2.2.2.2/32> on the ABR). So not only
> [Pushpasis] I agree that when 2.2.2.2/32(SID<http://2.2.2.2/32(SID> 10) from network B is re-
> 2.2.2.2/32<http://2.2.2.2/32> it will send the packet with the label 16210 (and not 16010).
> Similarly if 1.1.1.1/32(SID<http://1.1.1.1/32(SID> 10) from network A is re-advertised/re-distributed
>  ISIS: Prefix: 1.1.1.1/32<http://1.1.1.1/32>, Push 16010, Fwd to N1
>  OSPF: Prefix: 2.2.2.2/32<http://2.2.2.2/32>, Push 24010, Fwd to N2
>
> >
> >> From: Pushpasis Sarkar [mailto:[email-masked]<mailto:[email-masked]>]
> >>[email-masked]<mailto:[email-masked]>
> >> Cc: Uma Chunduri; Aissaoui, Mustapha (Mustapha); [email-masked]<mailto:[email-masked]>;
> >>Shraddha Hegde
> >> On 8/1/15, 4:56 AM, "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
> >>wrote:
> >>

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

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 4 Aug 2015 22:17:08 +0200

Les,

It is protocols which as used to construct and signal topologies. If I have
two topologies where in your model of global SRGB do I allocate a block of
A to one topo and block of B to the other ?

Now as to the "magic" part if I have global SRGB where do I allocate a
block of it for one protocol/instance vs another ?

Maybe this will clarify a lot and close this thread ...

Best,
R.

On Tue, Aug 4, 2015 at 9:07 PM, Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Yes – SR supports/requires different SIDs/topology. But topologies are NOT
> protocol specific. The “base unicast topology” which is implied when we
> talk outside the context of MT is the glaring example of that.
>
>
>
> As for “magic” – please point out one word or phrase in this entire
> discussion (either by myself or Pushpasis) that has suggested that SRGBs
> are defined in a way which is outside of the operator’s control.
>
>
>
>    Les
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Tuesday, August 04, 2015 10:07 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Pushpasis Sarkar; Hannes Gredler; [email-masked];
> Aissaoui, Mustapha (Mustapha); [email-masked]; Uma Chunduri; Shraddha
> Hegde
>
> *Subject:* Re: [spring] Modeling SRGB configuration for
> draft-ietf-spring-sr-yang
>
>
>
> Hi Les,
>
>
>
> Keep in mind that systems that decide for the operator on what ranges
> (from global SRGB) are advertised where in a magical way are not that
> always that welcome :)
>
>
>
> Best,
>
> r.
>
>
>
>
>
>
>
>
>
> On Tue, Aug 4, 2015 at 6:05 PM, Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
> Pushpasis -
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 4 Aug 2015 21:50:18 +0000

Robert -

Sent: Tuesday, August 04, 2015 1:17 PM

Les,

It is protocols which as used to construct and signal topologies. If I have two topologies where in your model of global SRGB do I allocate a block of A to one topo and block of B to the other ?
[Les:] It is up to the vendor to define a config model. But there is no need for topology specific SRGBs – only SIDs specific to a given prefix/topology pair. One can imagine many possible config models.

Now as to the "magic" part if I have global SRGB where do I allocate a block of it for one protocol/instance vs another ?
[Les:] You don’t. SIDs are a property of the prefix – not the protocol advertising the prefix. IN this way only one incoming label is required/prefix in the forwarding plane. One SRGB is sufficient for all protocols.
Please read my recent response to Pushpasis for further details.

   Les

Best,
R.

On Tue, Aug 4, 2015 at 9:07 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert –

   Les

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Tuesday, August 04, 2015 10:07 AM
To: Les Ginsberg (ginsberg)
Cc: Pushpasis Sarkar; Hannes Gredler; [email-masked]<mailto:[email-masked]>; Aissaoui, Mustapha (Mustapha); [email-masked]<mailto:[email-masked]>; Uma Chunduri; Shraddha Hegde

Hi Les,

Best,
r.

1 SID

   Les

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 4 Aug 2015 23:30:00 +0000

> One SRGB is sufficient for all protocols.

FWIW –
I agree with most of the folks supporting per protocol SRGB in this thread and the same  should be represented in the Yang model at least as a feature (the point of this thread).

For operational reasons it’s always good to have per protocols, per instance, per MT (AF), and per algorithm SRGBs (with the capability to add additional ranges based on the need).
Some of the issues if we don’t do this are clearly highlighted in the per algorithm SRGB draft recently presented.

--
Uma C.

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Tuesday, August 04, 2015 2:50 PM
To: Robert Raszuk
Cc: Pushpasis Sarkar; Hannes Gredler; [email-masked]; Aissaoui, Mustapha (Mustapha); [email-masked]; Uma Chunduri; Shraddha Hegde
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Robert -

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk

Les,

   Les

Best,
R.

   Les

Hi Les,

Best,
r.

1 SID

   Les

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 4 Aug 2015 23:30:14 +0000

+1
--
Uma C.

From: spring [mailto:[email-masked]] On Behalf Of Ahmed Bashandy (bashandy)
Sent: Wednesday, July 29, 2015 2:23 PM
To: [email-masked]
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

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

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

>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

---

From: "Hannes Gredler ([email-masked])" <[email-masked]>
Date: Tue, 11 Aug 2015 17:12:49 +0200

hi les,

On Fri, Jul 31, 2015 at 11:26:56PM +0000, Les Ginsberg (ginsberg) wrote:
| 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?

in the pre-SR days upon graceful restart the routing system
was re-reading the forwarding table and could derive from pre-incaranation
meta-information which protocol "owned" this label before and suggest to the
new-incranation protocol to re-use that label.
in most implementations i have seen that mapping of label2protocol was a 1:1
and not 1:N mapping. of course 1:N mapping *can* be done, but you may loose some
of the goodies of SR which is to re-use the existing MPLS eco-system.
changing the scheme from 1:1 to 1:N has for certain ISSU/NSR implications.

mandating "a single SRGB to rule them all", reminds me a bit to
the early SR debates where we've figured out that a single global SRGB
is desirable but practically not doable due to the various local
label-allocations behaviors.
the analogy here is that we're about to change a 15 year old paradigm
which is that "labels are not reused across protocols". i am not saying it
can not be done, i am just saying that there is a cost to it that not
everybody is willing to bear.

its cool that your implementation can obviously do 1:N mapping,
but no harm is being done to your implementation if we keep
the exisiting 1:1 paradigm and go ahead with one SRGB per protocol.

/hannes

| 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])
| > Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-
| > yang
| > 
| > 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: Tue, 11 Aug 2015 16:44:02 +0000

Hannes -

Your reply adds some confusion - largely because you have connected different topics inappropriately.

I will try to unravel this - inline.

> From: Hannes Gredler ([email-masked]) [mailto:[email-masked]]

> Sent: Tuesday, August 11, 2015 8:13 AM

> Cc: [email-masked]; Uma Chunduri; Aissaoui, Mustapha

> (Mustapha); [email-masked]; Shraddha Hegde ([email-masked]);

> Pushpasis Sarkar ([email-masked])

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

> in the pre-SR days upon graceful restart the routing system was re-reading

> the forwarding table and could derive from pre-incaranation meta-

> information which protocol "owned" this label before and suggest to the

> in most implementations i have seen that mapping of label2protocol was a

> 1:1 and not 1:N mapping. of course 1:N mapping *can* be done, but you may

> loose some of the goodies of SR which is to re-use the existing MPLS eco-

> system.

[Les:] The "1:N" problem comes about because of the introduction of "protocol specific SRGBs" - which as this thread has agreed leads to multiple labels for the same prefix. It isn't something inherent w SR itself. In particular it does not arise if you are able to use a protocol independent SRGB - so this is yet another point emphasizing the added complexity of protocol specific SRGBs.

> mandating "a single SRGB to rule them all", reminds me a bit to the early SR

> debates where we've figured out that a single global SRGB is desirable but

> practically not doable due to the various local label-allocations behaviors.

> the analogy here is that we're about to change a 15 year old paradigm which

> is that "labels are not reused across protocols". i am not saying it can not be

> done, i am just saying that there is a cost to it that not everybody is willing to

> bear.

[Les:] The initial "single SRGB" discussion had nothing to do w protocol specific SRGBs. It had to do with whether a single label range (16000-23999 was the proposal) could be reserved for SR purposes on every router. If it could be then there would have been no need for indeces - we simply could have assigned absolute labels to a prefix within a given domain. Allowing each router to choose and advertise its own protocol independent SRGB range does NOT lead to multiple labels per prefix on ingress. So comparing the two discussions is quite inappropriate.

> its cool that your implementation can obviously do 1:N mapping, but no harm

> is being done to your implementation if we keep the exisiting 1:1 paradigm

> and go ahead with one SRGB per protocol.

[Les:] You have completely misrepresented my position as well as the problem space.

You made the comment/query:

> | > it would be interesting to hear from other implementers if their

> | > software can easily track 'multiple client' ownership per label

to which I replied

> | As a datapoint, we are able to successfully manage a reserved label space

> among multiple SR clients.

This has nothing to do w multiple labels/prefix.

I then also commented

> | What is more problematic is supporting multiple labels for the same prefix -

> which is one of the consequences of the per-protocol SRGB approach.

Please note that it is the proponents of the per-protocol SRGB that are introducing the 1:N mapping issue - and I have tried to explain in my replies why this is more complex. Note also that I did NOT say this was unsupportable - in fact something roughly equivalent is required for SR-LDP interworking - but it does add complexity both in the implementations and in the manageability of the network. Please see my replies to Pushpasis for further detail.

   Les

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

> | > From: Hannes Gredler ([email-masked]<mailto:[email-masked]>)

> | > [mailto:[email-masked]]

> | > To: [email-masked]<mailto:[email-masked]>

> | > Cc: Les Ginsberg (ginsberg); Uma Chunduri; Aissaoui, Mustapha

> | > (Mustapha); [email-masked]<mailto:[email-masked]>; Shraddha Hegde ([email-masked]<mailto:[email-masked]>);

> | > Pushpasis Sarkar

> | > ([email-masked]<mailto:[email-masked]>)

> | > Subject: Re: [spring] Modeling SRGB configuration for

> | > draft-ietf-spring-sr- yang

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

> | > On Thu, Jul 30, 2015 at 01:18:43PM +0000,

> | > [email-masked]<mailto:[email-masked]>

> | > |    IGP migration example given is a good example, today with pure

> | > | IP,

> | > |    some tricky cases because we need to manage it with admin distance

> and

> | > |    their may be some differences in best path computation between

> IGPs

> | > |    labels. I agree that it consumes twice the number of required label,

> but

> | > |    containers or part of router OS running on COTS (just OSPF or ISIS or

> BGP

> | > |    code), may require some more independency between router

> software

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

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

> | > |    To: LITKOWSKI Stephane SCE/IBNF; 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]>)

> | > |    (I am not talking about what may or may not have been implemented

> by

> | > |    From: [1][email-masked]<mailto:[email-masked]>

> | > |    [3][email-masked]<mailto:[email-masked]>; Shraddha Hegde ([4][email-masked]<mailto:[email-masked]>);

> | > |    Sarkar ([5][email-masked]<mailto:[email-masked]>); Hannes Gredler

> | > ([6][email-masked]<mailto:[email-masked]>)

> | > |    What if we keep the SRGB block config in "segment-routing"

> | > | global

> | > |    To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha);

> LITKOWSKI

> | > |    Stephane SCE/IBNF; [8][email-masked]<mailto:[email-masked]>

> | > |    >the instruction is completely unnecessary - it simply wastes label

> space.

> | > |    SRGB for a routing instance to be advertised should be part of the

> routing

> | > |    Carving out the label space for SR is a local matter and agree, of

> course,

> __________________________________________________________

> | > |  Ce message et ses pieces jointes peuvent contenir des

> | > | informations confidentielles ou privilegiees et ne doivent donc

> | > |  Orange decline toute responsabilite si ce message a ete altere,

> | > | deforme ou

> | > |  If you have received this email in error, please notify the

> | > | sender and

> | > |  As emails may be altered, Orange is not liable for messages that

> | > | have been

> __________________________________________________________

> | > |  Ce message et ses pieces jointes peuvent contenir des

> | > | informations confidentielles ou privilegiees et ne doivent donc

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

> | > | privileged information that may be protected by law;  they should

> | > | not be

> | > |  If you have received this email in error, please notify the

> | > | sender and

> | > |  As emails may be altered, Orange is not liable for messages that

> | > | have been

---

From: "Hannes Gredler ([email-masked])" <[email-masked]>
Date: Wed, 12 Aug 2015 08:54:26 +0200

hi les,

see inline prefixed by HG>

On Tue, Aug 11, 2015 at 04:44:02PM +0000, Les Ginsberg (ginsberg) wrote:
| 
|    Your reply adds some confusion - largely because you have connected
|    different topics inappropriately.
| 
|    I will try to unravel this - inline.
| 
| 
| 
|    > -----Original Message-----
| 
|    > From: Hannes Gredler ([email-masked]) [mailto:[email-masked]]
| 
|    > Sent: Tuesday, August 11, 2015 8:13 AM
| 
|    > To: Les Ginsberg (ginsberg)
| 
|    > Cc: [email-masked]; Uma Chunduri; Aissaoui, Mustapha
| 
|    > (Mustapha); [email-masked]; Shraddha Hegde ([email-masked]);
| 
|    > Pushpasis Sarkar ([email-masked])
| 
|    > Subject: Re: [spring] Modeling SRGB configuration for
|    draft-ietf-spring-sr-
| 
|    > yang
| 
|    >
| 
|    > hi les,
| 
|    >
| 
|    > On Fri, Jul 31, 2015 at 11:26:56PM +0000, Les Ginsberg (ginsberg) wrote:
| 
|    > | 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?
| 
|    >
| 
|    > in the pre-SR days upon graceful restart the routing system was
|    re-reading
| 
|    > the forwarding table and could derive from pre-incaranation meta-
| 
|    > information which protocol "owned" this label before and suggest to the
| 
|    > new-incranation protocol to re-use that label.
| 
|    > in most implementations i have seen that mapping of label2protocol was a
| 
|    > 1:1 and not 1:N mapping. of course 1:N mapping *can* be done, but you
|    may
| 
|    > loose some of the goodies of SR which is to re-use the existing MPLS
|    eco-
| 
|    > system.
| 
|    > changing the scheme from 1:1 to 1:N has for certain ISSU/NSR
|    implications.
| 
|    >
| 
| 
| 
|    [Les:] The "1:N" problem comes about because of the introduction of
|    "protocol specific SRGBs" - which as this thread has agreed leads to
|    multiple labels for the same prefix. It isn't something inherent w SR
|    itself. In particular it does not arise if you are able to use a protocol
|    independent SRGB - so this is yet another point emphasizing the added
|    complexity of protocol specific SRGBs.

HG> you're mistaken - 1:N comes from the fact that a label may belong now
    to more than one protocol (e.g. OSPF and IS-IS) now the label allocation
    software needs to get extended to support two "owners"

    in the exisiting (15 year old) scheme (one label belongs to one protocol)
    you do not have that hassle.    

| 
| 
|    > mandating "a single SRGB to rule them all", reminds me a bit to the
|    early SR
| 
|    > debates where we've figured out that a single global SRGB is desirable
|    but
| 
|    > practically not doable due to the various local label-allocations
|    behaviors.
| 
|    > the analogy here is that we're about to change a 15 year old paradigm
|    which
| 
|    > is that "labels are not reused across protocols". i am not saying it can
|    not be
| 
|    > done, i am just saying that there is a cost to it that not everybody is
|    willing to
| 
|    > bear.
| 
| 
| 
|    [Les:] The initial "single SRGB" discussion had nothing to do w protocol
|    specific SRGBs. It had to do with whether a single label range
|    (16000-23999 was the proposal) could be reserved for SR purposes on every
|    router. If it could be then there would have been no need for indeces - we
|    simply could have assigned absolute labels to a prefix within a given
|    domain. Allowing each router to choose and advertise its own protocol
|    independent SRGB range does NOT lead to multiple labels per prefix on
|    ingress. So comparing the two discussions is quite inappropriate.

HG> point is: the common thinking flaw here is that 15 year old
    agreeed upon schemes:

    1) labels are local
    2) one label per protocol

    can get easily changed without much ramifications.
    we have already proof that 1) is not easy to change 
    and i am pretty certain that 2) is in the same category.
    
| 
| 
|    >
| 
|    > its cool that your implementation can obviously do 1:N mapping, but no
|    harm
| 
|    > is being done to your implementation if we keep the exisiting 1:1
|    paradigm
| 
|    > and go ahead with one SRGB per protocol.
| 
| 
| 
|    [Les:] You have completely misrepresented my position as well as the
|    problem space.
| 
| 
| 
|    You made the comment/query:
| 
| 
| 
|    > | > it would be interesting to hear from other implementers if their
| 
|    > | > software can easily track 'multiple client' ownership per label
| 
| 
| 
| 
| 
|    to which I replied
| 
| 
| 
|    > | As a datapoint, we are able to successfully manage a reserved label
|    space
| 
|    > among multiple SR clients.
| 
| 
| 
|    This has nothing to do w multiple labels/prefix.
| 
| 
| 
|    I then also commented
| 
| 
| 
|    > | What is more problematic is supporting multiple labels for the same
|    prefix -
| 
|    > which is one of the consequences of the per-protocol SRGB approach.
| 
| 
| 
|    Please note that it is the proponents of the per-protocol SRGB that are
|    introducing the 1:N mapping issue - and I have tried to explain in my
|    replies why this is more complex. Note also that I did NOT say this was
|    unsupportable - in fact something roughly equivalent is required for
|    SR-LDP interworking - but it does add complexity both in the
|    implementations and in the manageability of the network. Please see my
|    replies to Pushpasis for further detail.

HG> its the other way around ... breaking the one label per protocol paradigm
    by a single SRGB across protocols makes things (GR as an example) really messy.
    suggest not to go there and not touch this 15 year old convention for no big benefit.

| 
|    > | 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 ([1][email-masked])
| 
|    > | > [[2]mailto:[email-masked]]
| 
|    > | > Sent: Friday, July 31, 2015 7:02 AM
| 
|    > | > To: [3][email-masked]
| 
|    > | > Cc: Les Ginsberg (ginsberg); Uma Chunduri; Aissaoui, Mustapha
| 
|    > | > (Mustapha); [4][email-masked]; Shraddha Hegde
|    ([5][email-masked]);
| 
|    > | > Pushpasis Sarkar
| 
|    > | > ([6][email-masked])
| 
|    > | > Subject: Re: [spring] Modeling SRGB configuration for
| 
|    > | > draft-ietf-spring-sr- yang
| 
|    > | >
| 
|    > | > 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,
| 
|    > | > [7][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) [[8]mailto:[email-masked]]
| 
|    > | > |    Sent: Wednesday, July 29, 2015 23:01
| 
|    > | > |    To: LITKOWSKI Stephane SCE/IBNF; Uma Chunduri; Aissaoui,
| 
|    > Mustapha
| 
|    > | > |    (Mustapha); [9][email-masked]; Shraddha Hegde
| 
|    > ([10][email-masked]);
| 
|    > | > |    Pushpasis Sarkar ([11][email-masked]); Hannes Gredler
| 
|    > | > |    ([12][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][13][email-masked]
| 
|    > | > |    [[2][14]mailto:[email-masked]]
| 
|    > | > |    Sent: Wednesday, July 29, 2015 5:11 AM
| 
|    > | > |    To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha
| 
|    > | > (Mustapha);
| 
|    > | > |    [3][15][email-masked]; Shraddha Hegde
|    ([4][16][email-masked]);
| 
|    > | > Pushpasis
| 
|    > | > |    Sarkar ([5][17][email-masked]); Hannes Gredler
| 
|    > | > ([6][18][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][19]mailto:[email-masked]]
| 
|    > | > |    Sent: Friday, July 24, 2015 16:59
| 
|    > | > |    To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha);
| 
|    > LITKOWSKI
| 
|    > | > |    Stephane SCE/IBNF; [8][20][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. [21]mailto:[email-masked]
| 
|    > | > |    2. [22]mailto:[email-masked]
| 
|    > | > |    3. [23]mailto:[email-masked]
| 
|    > | > |    4. [24]mailto:[email-masked]
| 
|    > | > |    5. [25]mailto:[email-masked]
| 
|    > | > |    6. [26]mailto:[email-masked]
| 
|    > | > |    7. [27]mailto:[email-masked]
| 
|    > | > |    8. [28]mailto:[email-masked]
| 
| 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]
|    9. mailto:[email-masked]
|   10. mailto:[email-masked]
|   11. mailto:[email-masked]
|   12. mailto:[email-masked]
|   13. mailto:[email-masked]
|   14. mailto:[email-masked]
|   15. mailto:[email-masked]
|   16. mailto:[email-masked]
|   17. mailto:[email-masked]
|   18. mailto:[email-masked]
|   19. mailto:[email-masked]
|   20. mailto:[email-masked]
|   21. mailto:[email-masked]
|   22. mailto:[email-masked]
|   23. mailto:[email-masked]
|   24. mailto:[email-masked]
|   25. mailto:[email-masked]
|   26. mailto:[email-masked]
|   27. mailto:[email-masked]
|   28. mailto:[email-masked]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 12 Aug 2015 13:12:05 +0000

Hannes -

We disagree on pretty much everything. :-)

I would like to point out a couple of main points:

SID advertisements are "global" i.e. they are advertised area/domain wide. This is fundamentally different from the "LDP model" where labels are exchanged only between point-point peers and are therefore scoped only by that neighbor relationship. This in turn means that what is possible to do when using LDP is not the same as what is possible to do when using SR. It is obviously impossible to share labels between LDP and some other protocols because of the scope of the LDP advertisement. This limitation does not apply to SR.

Multiple implementations have already demonstrated that it is possible to share SR labels among multiple protocols.

Unless we agree on the above points it won't be possible to have a useful discussion between us.

What the thread (of which our discussion is a part) is discussing are cases where folks may not want to use the same label for the same prefix across multiple protocols. This does not alter the fact that it is feasible to do so and - as a number of folks on the thread have been advocating - is desirable in most cases. 

   Les

> Sent: Tuesday, August 11, 2015 11:54 PM
> |    > | > |    From: Uma Chunduri
> [[7][19]mailto:[email-masked]]
> |