Subject: [spring] SRGBs, indexes, and topologies within a domain

From: Eric C Rosen <[email-masked]>
Date: Tue, 18 Aug 2015 11:18:05 -0400

I've been following the "Modeling SRGB Configuration for 
draft-ietf-spring-sr-yang" thread on this mailing list.  I think this 
discussion reveals an inconsistency in the architecture (as described in 
draft-ietf-spring-segment-routing-04), and this inconsistency needs to 
be resolved.

 From the spring architecture:

    Global Segment: the related instruction is supported by all the SR- 
capable nodes in the domain.  In the MPLS architecture, a Global Segment 
has a globally-unique index.  The related local label at a given node N 
is found by adding the globally-unique index to the SRGB of node N. In 
the IPv6 architecture, a global segment is a globally- unique IPv6 address.

and

    IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP 
segment attached to an IGP prefix.  An IGP-Prefix Segment is always 
global within the SR/IGP domain and identifies an instruction to forward 
the packet over the ECMP-aware shortest-path computed by the IGP to the 
related prefix.  The Prefix-SID is the SID of the IGP- Prefix Segment.

The first paragraph above makes it pretty clear that a node is supposed 
to have only one SRGB.  So even though there seems to be consensus for 
allowing an SRGB per protocol in the Yang model, that seems to be at 
odds with the architecture.

However, I think the second paragraph quoted above contradicts the first 
paragraph.  A given network may have multiple topologies, and the paths 
for a given prefix may be different in each topology.  There are 
numerous ways to set a network up with multiple topologies.  One can 
have OSPF and ISIS running in parallel, or one can have multiple 
instances of one or the other IGP running in parallel, or one can use 
the explicit multi-topology feature that each IGP has.  An IGP-Prefix 
Segment would then have to be understood as an instruction to forward a 
packet over the ECMP-aware shortest-path computed by a particular IGP 
instance over a particular topology.

I think it is clear that in such a scenario, one cannot use the same 
MPLS label for a given prefix in all the topologies -- the label must be 
per-prefix/per-topology.  Since the label is computed from the 
combination of the prefix-SID and the SRGB, this forces us to make a 
choice between the following two alternatives:

1. Assign multiple SIDs to a given prefix, one per topology (i.e., the 
prefix-SID is not domain-wide unique, but only topology-wide unique), or

2. Assign a different SRGB to each topology (not merely a different one 
to each IGP).

The paragraphs I quoted from the architecture seem to prohibit both 
these alternatives, effectively prohibiting the use of multi-topology 
techniques in a spring domain.  I'm assuming that that was not the 
intention.

Reading the thread on representing the SRGB in the yang model, I'd 
conclude that most folks seem to want to be able to assign a domain-wide 
unique index to the prefixes, which requires alternative 2.  But in this 
case, the index is not "an instruction to forward the packet" over a 
particular path, it's just an abbreviation for the prefix.

My conclusion is that unless we really want to prohibit the use of 
multiple topologies in a spring domain, we need to choose between 
alternatives 1 and 2 above, and the architecture needs to be adjusted 
accordingly.

BTW, I don't think this issue is just a rehash of the old "should we 
have global labels?" argument, and we shouldn't approach it that way.

In a multi-topology scenario, alternative 2 does seem to have some 
operational advantages.  In a scenario where there is a single topology, 
but multiple routing algorithms are combined to create it, one could 
always assign the same SRGB to each algorithm.  Perhaps each node should 
be configurable with a default SRGB and an optional SRGB per topology. 
That would give operators the maximum freedom to support both 
single-topology and multi-topology scenarios as they see fit.

Comments?

---

From: Peter Psenak <[email-masked]>
Date: Tue, 18 Aug 2015 18:20:02 +0200

Hi Eric,

please see inline:

> prefix-SID is not domain-wide unique, but only topology-wide unique), or

for the true multi-topology case with single IGP above is what both OSPF 
and ISIS SR extensions have been assuming - there is no MTID advertised 
with SRGB, but there is one advertised with prefix SID.

For the multiple instances of one or the other IGP running in parallel 
(assuming same topology), same SRGB and SID for prefix could be used by 
all of them, although it should not be mandated.

> be configurable with a default SRGB and an optional SRGB per topology.

I would say optional SRGB per IGP instance - and that is what I believe 
we have concluded so far throughout the discussion.

thanks,
Peter

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

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 19 Aug 2015 05:44:41 +0000

Hi Peter,

>with SRGB, but there is one advertised with prefix SID.
[Pushpasis] What if the same prefix is advertised by same IGP instance
under two different topology? I think the point Eric is trying to make is
valid. The SR architecture document does not really clarify this scenario.
Again, following the same logic as given for per-protocol SRGB (actually
per-protocol per-instance) a separate SRGB should be provisioned
per-protocol per-instance and per-topology instead of assigning a separate
SID-Index for each topology.

>we have concluded so far throughout the discussion.
[Pushpasis] Yes. However if you really see the implication of that
consensus on a router with multiple routing-instances, it means one SRGB
per-protocol per-instance.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 19 Aug 2015 08:31:32 +0200

Hi Pushpasis,

> valid. The SR architecture document does not really clarify this scenario.

SR protocol extensions clearly do - they advertise MTID with the prefix 
SID, not with SRGB.

> per-protocol per-instance.

Did I say anything else?

thanks,
Peter
> .

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 19 Aug 2015 07:05:52 +0000

Hi Peter,

>SR protocol extensions clearly do - they advertise MTID with the prefix
[Pushpasis] Do you mean that a separate index per topology is mandatory?
That won¹t be a good idea in my opinion. Operators SHOULD have flexibility
to choose a separate or same index for the same prefix under different
topology. Not sure how other members (especially the operators) think
about the same. Request SR authors to re-consider this.

Thanks
-Pushpasis

---

From: <[email-masked]>
Date: Wed, 19 Aug 2015 07:36:35 +0000

Hi,

We come back to the same discussion for MT as for per algorithm SRGB. Do we need for operational reason the same index value to be configured for different algorithm or topologies ?
IMO, it is useful operationally otherwise adding a topology or algorithm would be painful ... Adding a new index value is like assigning a new prefix but here we want to use the same prefix.

Stephane

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Pushpasis Sarkar
Sent: Wednesday, August 19, 2015 09:06
To: Peter Psenak; Eric Rosen; SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Hi Peter,

[Pushpasis] Do you mean that a separate index per topology is mandatory?
That won¹t be a good idea in my opinion. Operators SHOULD have flexibility to choose a separate or same index for the same prefix under different topology. Not sure how other members (especially the operators) think about the same. Request SR authors to re-consider this.

Thanks
-Pushpasis

_________________________________________________________________________________________________________________________

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: Peter Psenak <[email-masked]>
Date: Wed, 19 Aug 2015 09:52:48 +0200

Stephane,

there are two things involved here - configuration and advertisement.

If you look at the SR drafts for both IGPs, both MTID and algorithm is 
advertised with Prefix SID, not with SRGB.

That does not mean you have to manually configure prefix SID for each 
MTID or algorithm - there are ways how this can be achieved in an 
automated way while advertising a single topology/algorithm agnostic SRGB.

thanks,
Peter

---

From: <[email-masked]>
Date: Wed, 19 Aug 2015 08:31:17 +0000

Hi Eric,

Regarding MT case, §3.2 states :

" A single Prefix-SID is allocated to an IGP Prefix in a topology.

   In the context of multiple topologies, multiple Prefix-SID's MAY be
   allocated to the same IGP Prefix (e.g.: using the "algorithm" field
   in the IGP advertisement as described in IGP SR extensions
   documents).  However, each prefix-SID MUST be associated with only
   one topology.  In other words: a prefix, within a topology, MUST have
   only a single Prefix-SID.
"

So it favors Alternative #1.

But the text is not really clear because :
- it does not talk about the "per-algorithm" case, just topology case

- it mixes algorithm and topology by saying " e.g.: using the "algorithm" field
   in the IGP advertisement as described in IGP SR extensions
   documents", which is bad as for true MT and even for multiple IGP instances, the MT-ID should be used as discriminator and not the algorithm field. Algorithm is something else. What if I want to do and IPv6 topology with SPT ? Normally I still use algo 0 but with MT-ID corresponding to IPv6 topology ... so algorithm and MT should not be mixed. For the multiple parallel IGP instances case, all of them will also use algo #0 as we want SPT.

I agree that there s a need of consensus on the target solution as you propose alternative #1 or #2 for algorithm, MT and protocol.

Allocating Prefix-SIDs is like allocating IP prefixes, there s should be a registry at SP side to manage that.
In term of allocation method, alternative #1 is like a flat addressing plan, so whatever the target element the IP address will be associated with, I just pick up the next available one (or something like that). Alternative #2 is something like prefix per function (that we usually do), so for a specific function (ex : LNS Loopback or BGP peering loopback ...), I use a particular prefix, but the suffix is the same, we can consider the SID value as the suffix and the SRGB as the prefix and combination of both gives the label. I would agree that here in reality when we see the label we do not see anymore this prefix+suffix. In both cases, the label value would be different.

As I already pointed, from a deployment perspective, it's more painful to reallocate a new SID each time we want to add a topology or algorithm. For sure it will not be a day to day operation, but even if we do this once per 5 years, this has a cost of many man months on a large network because it cannot be fully automated (when OSS does not have API) while deploying a new SRGB can be fully automated as there is no link with OSS at all.

Now another important point is the SRGB management in alternative #1 and #2.
Let's start with alternative #2, if I want to implement a new algorithm or topology or protocol, I need to allocate a new SRGB. So there is a need to configure a new label block.
As the node is maybe running for a while, label space may be fragmented and it may be hard :
- for sure , to allocate the label block the user wants
- in some  rare case, to allocate a single  block with the requested size (due to fragmentation of label space)
So the requested label block will be configured but not allocated, requiring a reboot to allow the allocation. This reboot has also an operational cost expressed in man months. If the user wants to prevent the reboot, it should let the box allocate any SRGB range taking into account the state of the label space available.

Now alternative #1, there is a chance with alternative#1 that the SRGB that has been configured is too small because I will need to twice more indexes. If I already allocated 2000 indexes, I will need 2000 indexes more.
SRGB extension has the same issue as allocating a new SRGB.

In conclusion, why not letting the choice to the user ? so creating an alternative #3, where the encoding allows to have a different SRGB per protocol, per topology, per algorithm but then the user can decide to use the same in configuration. So from encoding perspective it's alternate#2, but from a config perspective it allows for both.

Example : common SRGB for everything 

segment-routing
 srgb 100 1000
!
Router isis
 Topology #1
  Interface eth1
   Index 10 algorithm 0
   Index 20 algorithm 1
 Topology #2
   Interface eth1
     Index 30 algorithm 0
 !
Router ospf
 Interface eth1
  Index 40 algorithm 0
!

Result encoding would be that the same SRGB will be advertised multiple times for each activated protocol/algorithm/topology, in this case the SRGB will be advertised 4 times :
	SRGB 100 1000, algo 0, topo 1 in ISIS protocol
	SRGB 100 1000, algo 1, topo 1 in ISIS protocol
	SRGB 100 1000, algo 0, topo 2 in ISIS protocol
	SRGB 100 1000, algo 0, base topo in OSPF protocol

Example : different SRGB  

segment-routing
 srgb 100 1000
!
Router isis
 Topology #1
  Srgb 2000 3000 algo 0
  Srgb 3000 4000 algo 1
  Interface eth1
   Index 1 algorithm 0
   Index 1 algorithm 1
 Topology #2
  Srgb 4000 5000 algo 0
   Interface eth1
     Index 1 algorithm 0
 !
Router ospf
 Srgb 5000 6000 algo 0
 Interface eth1
  Index 1 algorithm 0
!

Result encoding would be :
	SRGB 2000 3000, algo 0, topo 1 in ISIS protocol
	SRGB 3000 4000, algo 1, topo 1 in ISIS protocol
	SRGB 4000 5000, algo 0, topo 2 in ISIS protocol
	SRGB 5000 6000, algo 0, base topo in OSPF protocol

Best Regards,

Stephane
-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Tuesday, August 18, 2015 17:18
To: SPRING WG
Subject: [spring] SRGBs, indexes, and topologies within a domain

I've been following the "Modeling SRGB Configuration for draft-ietf-spring-sr-yang" thread on this mailing list.  I think this discussion reveals an inconsistency in the architecture (as described in draft-ietf-spring-segment-routing-04), and this inconsistency needs to be resolved.

    Global Segment: the related instruction is supported by all the SR- capable nodes in the domain.  In the MPLS architecture, a Global Segment has a globally-unique index.  The related local label at a given node N is found by adding the globally-unique index to the SRGB of node N. In the IPv6 architecture, a global segment is a globally- unique IPv6 address.

and

Comments?

---

From: <[email-masked]>
Date: Wed, 19 Aug 2015 08:33:02 +0000

Hi Peter,

Inline comments

Stephane

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Wednesday, August 19, 2015 09:53
To: LITKOWSKI Stephane SCE/IBNF; Pushpasis Sarkar; Eric Rosen; SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Stephane,

If you look at the SR drafts for both IGPs, both MTID and algorithm is advertised with Prefix SID, not with SRGB.
[SLI] Agree that this is the way today.

That does not mean you have to manually configure prefix SID for each MTID or algorithm - there are ways how this can be achieved in an automated way while advertising a single topology/algorithm agnostic SRGB.
[SLI] Could you precise how you will do it ? Because using an offset as already proposed causes some collision or unusable indexes within the range. Something else in mind ?

thanks,
Peter

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 19 Aug 2015 08:43:11 +0000

Hi Peter,

>advertised with Prefix SID, not with SRGB.
[Pushpasis] Again IMO, SRGBs published per topology and hence ISIS/OSPF SR
extensions should be modified to add an optional MTID field as well.
>automated way while advertising a single topology/algorithm agnostic SRGB.
[Pushpasis] I am assuming by 'automated way’ you still mean separate
indexes per topology for the same prefix. Right?

Thanks
-Pushpasis
>> We come back to the same discussion for MT as for per algorithm SRGB.
>>Do we need for operational reason the same index value to be configured
>>for different algorithm or topologies ?
>> IMO, it is useful operationally otherwise adding a topology or
>>algorithm would be painful ... Adding a new index value is like
>>assigning a new prefix but here we want to use the same prefix.
>>
>> Stephane
>>
>> That won¹t be a good idea in my opinion. Operators SHOULD have
>>flexibility to choose a separate or same index for the same prefix under
>>different topology. Not sure how other members (especially the
>>operators) think about the same. Request SR authors to re-consider this.
>>
>> Thanks
>> -Pushpasis
>>
>>>
>>
>>_________________________________________________________________________
>>________________________________________________
>>
>> 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;

---

From: Peter Psenak <[email-masked]>
Date: Wed, 19 Aug 2015 11:57:23 +0200

Hi Pushpasis,

> extensions should be modified to add an optional MTID field as well.

please bear in mind that there are implementation out there in the field
with the existing encoding. If you move the MTID/algorithm fileds from
Prefix SID to SRGB, what is the MTID/algorithm fields in prefix SID used
for? Having the MTID/algorithm fileds in both Perfix SID and SRGB would
be redundant and confusing.

> indexes per topology for the same prefix. Right?

advertisement wise yes, config wise no.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Wed, 19 Aug 2015 12:04:56 +0200

Hi Stephane,

> [SLI] Agree that this is the way today.

given  that multiple vendors have shipping implementation using the 
exiting encoding, changing it now may be problematic.

> [SLI] Could you precise how you will do it ? Because using an offset as already proposed causes some collision or unusable indexes within the range. Something else in mind ?

whether you use offset or a new SRGB both have its challenges. I do not 
see a clear advantage of per MTID/algorithm SRGB - definitely not the 
one that would justify the change in existing IGP encoding.

thanks,
Peter

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 19 Aug 2015 10:17:41 +0000

Hi Peter,

On 8/19/15, 3:27 PM, "Peter Psenak" <[email-masked]> wrote:

>with the existing encoding.
[Pushpasis] That’s why I said that MTID in SR-Capability should be
optional. The SRGB for the default topology can be encoded without a MTID
(no impact to current implementation). The SRGB for other topologies can
be encoded with a MTID field.

>If you move the MTID/algorithm fileds from
>for? 

[Pushpasis] The MTID in prefix TLV is for having the index associated with
the prefix. If one uses the same index with differenet MTIDs(different
topologies) the label allocated for the same prefix for the two different
topologies shall be different. If the forwarding path for the prefix for
one topology needs to be different than the other, having the same label
for the same prefix for the two different topology is not an option. Hence
we need a different SRGB for each topology. That’s why we need a MTID in
the SR-Capability. 

>Having the MTID/algorithm fileds in both Perfix SID and SRGB would
[Pushpasis] I did not understand how advertisement can be different from
configuration. In my understanding advertisements are derived from
configurations.

Thanks
-Pushpasis
>>>> Orange decline toute responsabilite si ce message a ete altere,
>>>>deforme
>>>> ou falsifie. Merci.
>>>>

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 19 Aug 2015 11:13:45 +0000

Some corrections/additions in my response earlier…

On 8/19/15, 3:47 PM, "spring on behalf of Pushpasis Sarkar" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Peter,

On 8/19/15, 3:27 PM, "Peter Psenak" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Pushpasis,

On 8/19/15 10:43 , Pushpasis Sarkar wrote:
Hi Peter,
On 8/19/15, 1:22 PM, "Peter Psenak" <[email-masked]<mailto:[email-masked]>> wrote:
Stephane,

If you look at the SR drafts for both IGPs, both MTID and algorithm is
advertised with Prefix SID, not with SRGB.
[Pushpasis] Again IMO, SRGBs published per topology and hence ISIS/OSPF
SR
extensions should be modified to add an optional MTID field as well.

be encoded with a MTID field. Might as well be a separate MT-SRCapabality subTLV.

topologies shall be different same. If the forwarding path for the prefix for

automated way while advertising a single topology/algorithm agnostic
SRGB.

Thanks
-Pushpasis

thanks,
Peter
Thanks
-Pushpasis

thanks,
Peter

On 8/19/15 09:36 , [email-masked]<mailto:[email-masked]> wrote:
Hi,

Do we need for operational reason the same index value to be
configured

Stephane

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Pushpasis
Sarkar
Sent: Wednesday, August 19, 2015 09:06
To: Peter Psenak; Eric Rosen; SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Hi Peter,

On 8/19/15, 12:01 PM, "Peter Psenak" <[email-masked]<mailto:[email-masked]>> wrote:

SR protocol extensions clearly do - they advertise MTID with the
prefix
SID, not with SRGB.

[Pushpasis] Do you mean that a separate index per topology is
mandatory?
That won¹t be a good idea in my opinion. Operators SHOULD have
flexibility to choose a separate or same index for the same prefix
under
different topology. Not sure how other members (especially the
operators) think about the same. Request SR authors to re-consider
this.

Thanks
-Pushpasis

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

_______________________________________________________________________
__
________________________________________________

This message and its attachments may contain confidential or
privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
Thank you.

.

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

---

From: Peter Psenak <[email-masked]>
Date: Wed, 19 Aug 2015 13:55:57 +0200

Hi Pushpasis,

On 8/19/15 13:13 , Pushpasis Sarkar wrote:
> On 8/19/15, 3:47 PM, "spring on behalf of Pushpasis Sarkar" 
> <[email-masked] <mailto:[email-masked]> on behalf of 
> [email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Peter,
> 
>     be encoded with a MTID field. *Might as well be a separate
>     MT-SRCapabality subTLV.*
> 
>     the prefix. 

What you need is a different label for same prefix per MTID/algorithm -
that we agree on.
To achieve that you either need single SID and per MTID/algorithm SRGB
or single SRGB with per MTID/algorithm SIDs.

If you look at OSPF encoding, both MTID and algorithm are inside the
Prefix-SID sub-TLV. ISIS has MTID in the Prefix TLV and algorithm in
Prefix SID sub-TLV. Nevertheless, from the architecture perspective both
IGPs assumed the same. The SR architecture from the very beginning
assumed per MTID/algorithm SID, not per MTID/algorithm SRGB and IGP
encoding has been designed with that in mind.

If you add MTID and algorithm in SRGB as well, you end up with the MTID
and algorithm fields at two different TLVs for the same topology -
inside SRGB and inside the Prefix SID sub-TLV, which is clearly redundant.

> If one uses the same index with differenet MTIDs(different
>     topologies shall be *different* *same*. If the forwarding path for
>     the prefix for

you need different labels for same prefix in different topologies, that
does not mean you need a different SRGB. Please do not present your
solution as a requirement.

thanks,
Peter

>                 On 8/19/15 09:36 , [email-masked]
>                 <mailto:[email-masked]> wrote:
> 
>                     Hi,
> 
>                     On 8/19/15, 12:01 PM, "Peter Psenak"
>                     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>                     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 19 Aug 2015 12:13:58 +0000

Hi Peter,

>inside SRGB and inside the Prefix SID sub-TLV, which is clearly redundant.

[Pushpasis] I am trying give both options to a operator (i.e. Single SRGB
with per-topology SID-index as well as single SID-index with per-topology
SRGB). Depending on which one the operators prefer, one of them becomes
redundant :) Also the MTID is not attached to the prefix-SID but the
prefix with which the SID-index is attached. That is an existing
information outside SR. Again in my opinion, MTID with SRGB will be
preferable than MTID with prefix-SID, in case one needs to be preferred
the other.

>solution as a requirement.
[Pushpasis] Sorry if I sound like that. But I am deducing the proposal out
of a requirement which I think is relevant to most operators. If operators
think they are fine with one SID-index per topology for the same prefix, I
will take back my proposal. But yet again I think that operators will
prefer to have the same index for the same prefix across multiple
topologies and just have one SRGB per topology. I urge all the operators
to provide their preference.

Thanks
-Pushpasis

---

From: Peter Psenak <[email-masked]>
Date: Wed, 19 Aug 2015 14:45:32 +0200

Hi Pushpasis,

On 8/19/15 14:13 , Pushpasis Sarkar wrote:
> redundant :) 

I'm not sure we want to advertise redundant data to allow more
configuration flexibility. From both architecture and encoding
perspective it's preferable to pick single approach. And it looks like
to me one has been picked already by both architecture and encoding.

> Also the MTID is not attached to the prefix-SID but the
> prefix with which the SID-index is attached. 

In OSPF we took an approach of advertising the prefix once and encode
MTID in each attribute. So in OSPF MTID it is attached to Prefix SID.
ISIS uses different approach, where prefix as such is advertised for
each MTID independently with all the MTID specific attributes.

thanks,
Peter

> That is an existing

---

From: Peter Psenak <[email-masked]>
Date: Wed, 19 Aug 2015 18:51:41 +0200

Hi Pushpasis,

> configuration. In my understanding advertisements are derived from

right, but you can make your configuration smart and do not require
prefix SID to be configured for each topology, while still advertising a
unique value for each topology.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 19 Aug 2015 19:33:48 +0200

Hi Peter,

And in that case of smart configuration you describe is there any spring
document describing how do you deal with advertisements collisions where
box A topo X advertised in its smart way identical SID as equally "smart"
box B in the same topo X ?

It could be as simple as box with lower router_id retries with new SID :)
But I do not recall I have seen it.

Cheers,
R.

---

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

Robert –

There is another thread which is discussing how to deal with conflict resolutions – I have attached one of the early emails on the subject – please read the rest of that thread and – if you wish – comment on that thread.
Please do not introduce conflict resolution into this thread – that isn’t appropriate – the problem is not specific to this discussion.

Thanx.

   Les

From: spring [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, August 19, 2015 10:34 AM
To: Peter Psenak (ppsenak)
Cc: [email-masked]; SPRING WG; Pushpasis Sarkar; Eric Rosen
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Hi Peter,

And in that case of smart configuration you describe is there any spring document describing how do you deal with advertisements collisions where box A topo X advertised in its smart way identical SID as equally "smart" box B in the same topo X ?

It could be as simple as box with lower router_id retries with new SID :) But I do not recall I have seen it.

Cheers,
R.

On Wed, Aug 19, 2015 at 6:51 PM, Peter Psenak <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pushpasis,

thanks,
Peter

Subject: Re: [spring] Conflicting MS entries
From: "[email-masked]" <[email-masked]>
To: "Stefano Previdi (sprevidi)" <[email-masked]>
Cc: LITKOWSKI Stephane SCE/IBNF <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked] list" <[email-masked]>
Date: Wed, 17 Jun 2015 14:53:55 +0000
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>

Hi Stefano,

Thanks for initiating discussion on this point.

1) I don't feel that this is a IS-IS encoding specific issue, but rather a SPRING consideration, so I'm adding spring.
Eventually this seems related to draft-filsfils-spring-segment-routing-ldp-interop

<chair hat off>

2) From a service provider standpoint, i.e. from a functional standpoint, I think what we should try to handle this as nicely as possible. Indeed, having conflicting configurations between 2 nodes may happen, and even the most clever implementation may not avoid such configuration mistake. So in such case, dropping traffic for Mapping Server SID seems a significant network wide disruption.

3) As a contributor to spring, from a protocol standpoint, this looks a priori easier than BGP error handling, so we should probably be able to do at least as good.
It seems easier since:
- the state of the speaker is not relevant as we don't need to send spring traffic or spring signaling to it.
- all receivers receive the same information which is syntaxally correct

So to have a coherent network state, it would seem sufficient to specify a behavior on the receiving side.

4) Going into more details, and referring to Stéphane analysis:
	 1) I don't really the issue. From a forwarding standpoint, looks like we can simply program multiple SIDs in the FIB.
	 2) Seems more complex to me. A priori we need to define a tie-breaker based on received MS entries. We seem to all agree that local only mapping must be disregarded/less preferred. According to you, this is the easy part, so looks good.
	3) Is already specified in the ISIS document: https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-04#section-2.4.5

So it looks like the remaining work is to define a tie-breaker.

Thanks,
Bruno

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Stefano Previdi (sprevidi)
> 
> <removing the long recipient list and adding isis-wg> Background
> information about this issue is on the original email here below.
> 
> 
> Hi Stephane,
> 
> On Jun 17, 2015, at 10:42 AM, <[email-masked]> wrote:
> > Hi Stefano,
> >
> > As discussed in Dallas, there may be no ideal option but let's try to find
> one which may try to preserve the transport service. So I'm not in favor of
> option 1.
> > There may be three kinds of overlap :
> > 1) prefix overlap with different indexes, example :
> > 	192.0.2.0/32 range 10 index 100
> > 	192.0.2.5/32 range 1 index 2000
> > 	192.0.2.5/32 range 2 index 3000
> > 	In this case 192.0.2.5/32 is associated with three different indexes
> >
> > 2) index overlap, example :
> > 	192.0.2.0/32 range 10 index 100
> > 	198.15.0.0/32 range 100 index 100
> > 	In this case, different prefixes will use the same index.
> >
> > 3) overlap between binding TLV and prefix entry
> > 	192.0.2.0/32 range 10 index 100 learned from MS
> > 	192.0.2.5/32 index 200 learned from TLV135
> > 	In this case 192.0.2.5/32 is associated with two different indexes
> > learned by two different ways
> 
> 
> very good points above and that illustrate even better the complexity of the
> scheme we would need to define in order to cope with all possible cases.
> 
> 
> > 2) must be solved as we manage conflicting SIDs associated with
> connected prefixes. It's a similar case, two different prefixes having the
> same SID.
> 
> 
> yes, this is the easy one. Again, no real solution here but as you pointed out,
> you may still want to preserve part of the reachability.
> 
> >
> > 1)3) If we think about tiebreaker, I'm not sure that preferring local MS
> entries over remote MS entries is a good idea as it may lead to
> inconsistencies while the target may be to have everyone taking the same
> decision.  In contrary, I would make prefer prefix SID mappings over MS
> entries.
> 
> 
> yes, I agree. The point was what to prefer between a received MS entry vs. a
> locally defined MS entry. But as you aid, if we prefer anything "local" we
> can't rely on network-wide consistent behavior.
> 
> s.
> 
> 
> > To compare MS entries, it may be possible to consider something like
> lowest range and then lowest index for example.
> >
> > From: Stefano Previdi (sprevidi) [mailto:[email-masked]]
> > Sent: Tuesday, June 16, 2015 19:15
> > To: Clarence Filsfils (cfilsfil); Ahmed Bashandy (bashandy); Hannes
> > Gredler; LITKOWSKI Stephane SCE/IBNF; DECRAENE Bruno IMT/OLN; Jeff
> > Tantsura; Les Ginsberg (ginsberg); Wim (Wim) Henderickx; Steven Luong
> > (sluong)
> > Subject: Conflicting MS entries
> >
> > Co-authors and Contributors,
> >
> > I'd like to close on the conflicting MS entries issues.
> >
> > The issue is related to what a receiver should do when receiving to or
> more conflicting MS mappings.
> >
> > So far we agreed that there's no way we can determine which one is good
> or bad and therefore whatever action we mandate it will create disruption.
> The choices are:
> >
> > 1. ignore all conflicting entries
> > 2. select one of the conflicting entry based on whatever breaking tie algo.
> >
> > Obviously, option1 is the easiest knowing that no other option would allow
> to fix the conflict anyway.
> > Option2 may be appealing but in such case we would have to consider all
> corner cases such as:
> > . what about a conflict between locally configured mapping entry and
> received ones ?
> > . what about conflicting entries received by the same router ? which one to
> select ?
> >
> > I think it is preferable to ignore all conflicting entries and log and error
> message. We discussed about this in Dallas but despite the agreement on
> the absence of a cure we decided, at that time, to let the operators to give
> feedback on the proposal.
> >
> > Is there anything that has changed ?
> >
> > Also, let me know if you'd prefer to bring the issue to the mailing list
> before reaching agreement among co-authors.
> >
> > Thanks.
> > s.
> >
> >
> >
> ______________________________________________________________
> ________
> > ___________________________________________________
> >
> > 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,
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 20 Aug 2015 10:03:36 +0200

Les,

I simply were trying to politely and gently point out (in the form of the
question) the problem with "smart configuration" auto picking SIDs from
global block.

To me there is fundamental difference in accidental or buggy collisions vs
design which will likely result in such on a regular basis in some network
deployment models.

To me it is like specifying say a global /16 IPv4 block in all routers in
the domain and having local "smart configuration" automatically select /32
from that block for loopbacks or protocol router_ids.

Is this generally useful (well except maybe for home networking) ? Is this
operation friendly or easy for troubleshooting for large networks ?

Cheers,
R.

On Wed, Aug 19, 2015 at 8:05 PM, Les Ginsberg (ginsberg) <[email-masked]
> wrote:

> Robert –
>
>
>
> There is another thread which is discussing how to deal with conflict
> resolutions – I have attached one of the early emails on the subject –
> please read the rest of that thread and – if you wish – comment on that
> thread.
>
> Please do not introduce conflict resolution into this thread – that isn’t
> appropriate – the problem is not specific to this discussion.
>
>
>
> Thanx.
>
>
>
>    Les
>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 20 Aug 2015 10:37:17 +0200

Robert,

"smart configuration" is this case means nothing more then configuring 
an offset to a common SRGB space on a per topology cases. This is as 
operation friendly and easy to troubleshoot as configuring SRGB per 
topology.

thanks,
Peter

On 8/20/15 10:03 , Robert Raszuk wrote:
> Les,
>
> I simply were trying to politely and gently point out (in the form of
> the question) the problem with "smart configuration" auto picking SIDs
> from global block.
>
> To me there is fundamental difference in accidental or buggy collisions
> vs design which will likely result in such on a regular basis in some
> network deployment models.
>
> To me it is like specifying say a global /16 IPv4 block in all routers
> in the domain and having local "smart configuration" automatically
> select /32 from that block for loopbacks or protocol router_ids.
>
> Is this generally useful (well except maybe for home networking) ? Is
> this operation friendly or easy for troubleshooting for large networks ?
>
> Cheers,
> R.
>
>
> On Wed, Aug 19, 2015 at 8:05 PM, Les Ginsberg (ginsberg)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Robert –____
>
>     __ __
>
>     There is another thread which is discussing how to deal with
>     conflict resolutions – I have attached one of the early emails on
>     the subject – please read the rest of that thread and – if you wish
>     – comment on that thread.____
>
>     Please do not introduce conflict resolution into this thread – that
>     isn’t appropriate – the problem is not specific to this discussion.____
>
>     __ __
>
>     Thanx.____
>
>     __ __
>
>         Les
>
>
>

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 20 Aug 2015 09:20:36 +0000

Hi Peter,

>to me one has been picked already by both architecture and encoding.
[Pushpasis] I think that¹s what Eric and myself has been trying to say..
Whatever the architecture and the encoding has picked does not seem to be
enough. :) Again I will wait for others to chime in and let us know if
they need this change or not.

>each MTID independently with all the MTID specific attributes.
[Pushpasis] Yes, I am aware of that :)

Thanks
-Pushpasis

---

From: Peter Psenak <[email-masked]>
Date: Thu, 20 Aug 2015 13:13:01 +0200

Hi Pushpasis,

> they need this change or not.

my concern is that the change in the architecture you are proposing will 
results in an encoding which will be redundant and confusing. Unless the 
change in architecture is absolutely necessary, which does not seem to 
be the case here, I would tend to leave it as it is.

thanks,
Peter

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 20 Aug 2015 11:20:36 +0000

Hi Peter,

Sure. I will let the operators on the list to decide if this needed. No
more nagging from my side :)

Thanks
-Pushpasis

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 24 Aug 2015 11:08:27 -0400

[Peter] What you need is a different label for same prefix per
MTID/algorithm - that we agree on.  To achieve that you either need
single SID and per MTID/algorithm SRGB or single SRGB with per
MTID/algorithm SIDs.

Peter, my reading of the architecture is that a prefix-SID is "global"
and that an SRGB is per-node.

This seems to be at odds with the way the control plane encodings have
been defined, which suggests that either the architecture or the
encodings needs adjustment.

Recall that this discussion started with a claim that even one SRGB per
algorithm was in violation of the architecture.

If we assume that the signaling drafts capture what the architecture is
supposed to have said, then I see the following issues.

1. If a new topology is added by use of the MT features of an IGP, then
a new set of prefix-SIDs must be provisioned.  This seems like a major
provisioning task.  The alternative would be to have an SRGB per
topology; then when you add a new topology, you only have one quantity
to provision (or one per platform perhaps).  I hear some hand-waving
about how easy it is to provision new prefix-SIDs for every new
topology, but ...

2. The multi-topology feature of an IGP is just one way of setting up
multiple "underlays".  If you set up two underlays by using two
instances of OSPF, you can assign a SRGB to each underlay.  If you set
up two underlays by using two topologies in one instance of OSPF, you
can't.  Why the difference?  I find this really confusing -- exactly
what is the scope of uniqueness of a prefix-SID supposed to be?

[Peter] The SR architecture from the very beginning assumed per
MTID/algorithm SID, not per MTID/algorithm SRGB and IGP encoding has
been designed with that in mind.

Can you point to a place in the architecture document where it says that
SIDs are only "global" per MTID/algorithm and/or that SRGBs are
per-algorithm?

[Peter] If you add MTID and algorithm in SRGB as well, you end up with
the MTID and algorithm fields at two different TLVs for the same
topology - inside SRGB and inside the Prefix SID sub-TLV, which is
clearly redundant.

I don't really understand what problem is being stated above.

[Pushpasis] I am trying give both options to a operator (i.e. Single
SRGB with per-topology SID-index as well as single SID-index with
per-topology SRGB). Depending on which one the operators prefer, one of
them becomes redundant.

[Peter] I'm not sure we want to advertise redundant data to allow more
configuration flexibility. From both architecture and encoding
perspective it's preferable to pick single approach.

I see this issue differently.  We already allow (but do not require) a
different SRGB to be assigned to each instance of each routing
algorithm; but a different SRGB cannot be assigned to each topology of a
given instance of a given algorithm.  This means there are already
multiple ways of assigning SIDs/SRGBs, with some restrictions that don't
seem to make much sense.

Also I don't think it's a good trade-off to limit configuration
flexibility in order to simplify an encoding.

[Peter] please bear in mind that there are implementations out there in
the field with the existing encoding.

I'm sure any changes could be made in a backwards compatible manner.

[Peter] If you move the MTID/algorithm fields from Prefix SID to SRGB,
what is the MTID/algorithm fields in prefix SID used for? Having the
MTID/algorithm fields in both Prefix SID and SRGB would be redundant and
confusing.

Tthe encoding could be designed to not only be backwards compatible, but
also to give unambiguous semantics to all combinations.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 25 Aug 2015 09:48:36 +0200

Hi Eric,

please see inline:

> and that an SRGB is per-node.

Prefix SID has a prefix scope, SRGB has a node scope.

> encodings needs adjustment.

I do not see any odds with the encodings. Current IGP encoding supports
SRGB per each instance of the IGP.

> algorithm was in violation of the architecture.

SR architecture never claimed per algorithm SRGB.

> about how easy it is to provision new prefix-SIDs for every new

I will keep repeating myself that such provisioning can be made
automatic, so the above point is not really convincing to me.

> what is the scope of uniqueness of a prefix-SID supposed to be?

the difference is because SRGB is a node property and SID is a prefix
property. Each prefix can have many attributes and SID is just another
prefix attribute. It's similar to prefix metric, which has a per
topology scope. SRGB is like any other node capability. This actually
fits very well in the existing IGP architecture - node capabilities are
never per topology. At the end you only have a single label block on a
device. You can partition it in many ways, but the block is just one.

> SIDs are only "global" per MTID/algorithm and/or that SRGBs are

form draft-ietf-spring-segment-routing-04.txt:

"SR Global Block (SRGB): local property of an SR node."

"IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP
segment attached to an IGP prefix.

Above makes it clear to me that SRGB has a per node property and is
advertised by IGP as such. Prefix-SID is a prefix property and as such
can be advertised per MTID topology, as any other prefix attribute.

IGP encodings for OSPF and ISIS have been designed by a team of people
from multiple vendors and some of them contributed to the SR
architecture document as well - the fact that we designed the IGP
encoding the way it is clearly indicates what was the common
understanding of the SR architecture.

We can surely improve the wording in the SR architecture document if you
feel so.

> I don't really understand what problem is being stated above.

the problem is that you create an overlap, where both SRGB and
prefix-SID would be carrying the same values. I suppose you agree that
we do not need these fields to be associated with both SRGB and SIDs.

> algorithm; 

no, we don't. SRGB scope is IGP instance. There is no algorithm there.

> but a different SRGB cannot be assigned to each topology of a

to change the existing encoding one would need a strong reason. I do not
see anything which can not be done with the existing encodings.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 25 Aug 2015 11:05:14 +0200

Peter,

"You can partition it in many ways, but the block is just one."

As you recall mpls architecture does not have such limitation. You can have
per interface overlapping label space.

Likewise to me SRGB blocks for MT or MI do not need to be continuos what
your earlier suggestion regarding offset would result with.

So I think the crux of this entire debate is this: are we allowing non
continous SRGB pools per node or not (say one per topology).

If not what you and Les are saying may indeed be ok, however for deployment
flexibility I would rather tend to opt for it.

Best,
R.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 25 Aug 2015 11:25:35 +0200

Robert,

On 8/25/15 11:05 , Robert Raszuk wrote:
> As you recall mpls architecture does not have such limitation. You can
> have per interface overlapping label space.
>

No matter how many partitions you have, still it's a single block 
consisting of multiple partitions.

Yes, we are allowing non continuous SRGB per node - you can advertise 
multiple SRGB blocks per node - please see the OSPF/ISIS SR extensions.

thanks,
Peter

>
> If not what you and Les are saying may indeed be ok, however for
> deployment flexibility I would rather tend to opt for it.
>
> Best,
> R.
>
> On Aug 25, 2015 9:48 AM, "Peter Psenak" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Eric,
>
>     please see inline:
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 25 Aug 2015 11:36:04 +0200

Peter,

In first sentence you say "single block" in second one you say "multiple
blocks" so which one it is  ?

Thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 25 Aug 2015 11:44:05 +0200

> blocks" so which one it is  ?

you can advertise multiple SGRBs per node.

Peter

>
> Thx,
> R.
>
> On Aug 25, 2015 11:25 AM, "Peter Psenak" <[email-masked]
>     Yes, we are allowing non continuous SRGB per node - you can
>     advertise multiple SRGB blocks per node - please see the OSPF/ISIS
>     SR extensions.
>
>     thanks,
>     Peter
>
>
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>              Hi Eric,
>
>              please see inline:
>
>               > Peter, my reading of the architecture is that a
>         prefix-SID is
>              "global"
>               > This seems to be at odds with the way the control plane
>         encodings
>              have
>               > Recall that this discussion started with a claim that
>         even one
>              SRGB per
>               > 1. If a new topology is added by use of the MT features
>         of an
>              IGP, then
>               > a new set of prefix-SIDs must be provisioned.  This
>         seems like a
>              major
>               > topology; then when you add a new topology, you only
>         have one
>              quantity
>               > instances of OSPF, you can assign a SRGB to each
>         underlay.  If
>              you set
>               > Can you point to a place in the architecture document
>         where it
>              says that
>               > [Peter] If you add MTID and algorithm in SRGB as well,
>         you end up
>              with
>               > per-topology SRGB). Depending on which one the operators
>         prefer,
>              one of
>               > them becomes redundant.
>               >
>               > [Peter] I'm not sure we want to advertise redundant data
>         to allow
>              more
>               > multiple ways of assigning SIDs/SRGBs, with some
>         restrictions
>              that don't
>               > seem to make much sense.
>               >
>               > [Peter] please bear in mind that there are
>         implementations out
>              there in
>               > [Peter] If you move the MTID/algorithm fields from
>         Prefix SID to
>              SRGB,
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 25 Aug 2015 11:50:24 +0200

So as long you can also configure multiple SRGBs per node the discussion is
over :)

But that perhaps is a topic outside of IETF and one should express
preferences directly with their vendors.

Thx Peter !
R.
On Aug 25, 2015 11:44 AM, "Peter Psenak" <[email-masked]> wrote:

>>               > I see this issue differently.  We already allow (but do
>> not
>>              require) a

---

From: Peter Psenak <[email-masked]>
Date: Tue, 25 Aug 2015 12:53:28 +0200

Robert,

On 8/25/15 11:50 , Robert Raszuk wrote:
> So as long you can also configure multiple SRGBs per node the discussion
> is over :)

the discussion is not about advertising multiple SRGBs, but about the 
scope of the SRGB advertisement - currently it is a per node. The fact 
that you can advertise multiple SRGBs does not change its scope.

thanks,
Peter

> On Aug 25, 2015 11:44 AM, "Peter Psenak" <[email-masked]
>                  As you recall mpls architecture does not have such
>         limitation.
>                  You can
>                  On Aug 25, 2015 9:48 AM, "Peter Psenak"
>         <[email-masked] <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>
>                  <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>
>                       Hi Eric,
>
>                       please see inline:
>
>                        > MTID/algorithm - that we agree on.  To achieve
>         that you
>                  either need
>                        > single SID and per MTID/algorithm SRGB or
>         single SRGB
>                  with per
>                        > MTID/algorithm SIDs.
>                        >
>                        > If we assume that the signaling drafts capture
>         what the
>                       architecture is
>                        > provisioning task.  The alternative would be to
>         have an
>                  SRGB per
>                        > to provision (or one per platform perhaps).  I
>         hear some
>                  hand-waving
>                        > about how easy it is to provision new
>         prefix-SIDs for
>                  every new
>                        > topology, but ...
>
>                        > 2. The multi-topology feature of an IGP is just
>         one way
>                  of setting up
>                        > multiple "underlays".  If you set up two
>         underlays by
>                  using two
>                        > up two underlays by using two topologies in one
>         instance
>                  of OSPF, you
>                        > what is the scope of uniqueness of a prefix-SID
>         supposed
>                  to be?
>
>                       the difference is because SRGB is a node property
>         and SID
>                  is a prefix
>                       property. Each prefix can have many attributes and
>         SID is
>                  just another
>                       prefix attribute. It's similar to prefix metric,
>         which has
>                  a per
>                       topology scope. SRGB is like any other node
>         capability.
>                  This actually
>                       never per topology. At the end you only have a
>         single label
>                  block on a
>                       device. You can partition it in many ways, but the
>         block is
>                  just one.
>
>                        >
>                        > MTID/algorithm SID, not per MTID/algorithm SRGB
>         and IGP
>                  encoding has
>                        > SIDs are only "global" per MTID/algorithm
>         and/or that
>                  SRGBs are
>                        > per-algorithm?
>
>                       "IGP-prefix Segment, Prefix-SID: an IGP-Prefix
>         Segment is
>                  an IGP
>                       advertised by IGP as such. Prefix-SID is a prefix
>         property
>                  and as such
>                       can be advertised per MTID topology, as any other
>         prefix
>                  attribute.
>
>                       IGP encodings for OSPF and ISIS have been designed
>         by a
>                  team of people
>                       architecture document as well - the fact that we
>         designed
>                  the IGP
>                       We can surely improve the wording in the SR
>         architecture
>                  document if you
>                       feel so.
>
>                        >
>                        > the MTID and algorithm fields at two different
>         TLVs for
>                  the same
>                        > I don't really understand what problem is being
>         stated
>                  above.
>
>                       prefix-SID would be carrying the same values. I
>         suppose you
>                  agree that
>                       we do not need these fields to be associated with
>         both SRGB
>                  and SIDs.
>
>
>                        >
>                        > [Pushpasis] I am trying give both options to a
>         operator
>                  (i.e. Single
>                        > configuration flexibility. From both
>         architecture and
>                  encoding
>                        > I see this issue differently.  We already allow
>         (but do not
>                       require) a
>                        > different SRGB to be assigned to each instance
>         of each
>                  routing
>                        > algorithm;
>
>                        > but a different SRGB cannot be assigned to each
>         topology
>                  of a
>                        > given instance of a given algorithm.  This
>         means there
>                  are already
>                       to change the existing encoding one would need a
>         strong
>                  reason. I do not
>                        > what is the MTID/algorithm fields in prefix SID
>         used
>                  for? Having the
>                        > MTID/algorithm fields in both Prefix SID and
>         SRGB would be
>                       redundant and
>                        > confusing.
>                        >
>                        > Tthe encoding could be designed to not only be
>         backwards
>                       compatible, but
>         <mailto:[email-masked]>> <mailto:[email-masked]
>         <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: <[email-masked]>
Date: Tue, 25 Aug 2015 10:58:50 +0000

Hi Peter,

>> 1. If a new topology is added by use of the MT features of an IGP, 
>> then a new set of prefix-SIDs must be provisioned.  This seems like a 
>> major provisioning task.  The alternative would be to have an SRGB per 

> I will keep repeating myself that such provisioning can be made automatic, so the above point is not really convincing to me.

Could you explain how ? Based on past discussions, it does not seem to be so easy.

Best Regards,

Stephane

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 25 Aug 2015 13:14:34 +0200

Peter,

If on a given node I run OSPF and ISIS and I advertise differe SRGB block
with each of them what is really "per node scope"

Each igp thinks it is per node in their understanding of what the node is,
but between them I see no relation at all.

It would be rather a mistake to assue both igp have congruent base
topologies which such condition seems not easy to avoid if you treat block
as something sitting above both of them.

Thx,
R.
On Aug 25, 2015 12:53 PM, "Peter Psenak" <[email-masked]> wrote:

> scope of the SRGB advertisement - currently it is a per node. The fact that
> you can advertise multiple SRGBs does not change its scope.
>
> thanks,
> Peter
>
>
>
>>                        > [Peter] What you need is a different label for
>> same
>>                  prefix per
>>                       I do not see any odds with the encodings. Current
>> IGP
>>                  encoding supports
>>                       fits very well in the existing IGP architecture -
>> node
>>                  capabilities are
>>                        > [Peter] The SR architecture from the very
>> beginning
>>                  assumed per
>>                        > SRGB with per-topology SID-index as well as
>> single
>>                  SID-index with
>>                       no, we don't. SRGB scope is IGP instance. There is
>> no
>>                  algorithm there.
>>

---

From: Peter Psenak <[email-masked]>
Date: Tue, 25 Aug 2015 13:17:38 +0200

Hi Stephane,

> Could you explain how ? Based on past discussions, it does not seem to be so easy.

simply by associating an offset and size from SRGP on a per topology basis.

Example:

SRGB 1600-24000

I would assume that when you start to assign your SIDs for the default 
topology, you would not pick random values, but start from the 
beginning. So let' assume you are using 16001 to 16500 for nodes in 
default topology.

Now you need to add a new topology. You configure and offset of 2k for 
it, so the advertised SIDs for the new topology would start from 18001. 
If we assume that the 2k would be a reasonable size for each topology 
you can have 4 topologies with 2k SIDs per topology.

If for whatever reason you run out of the SID space in any topology, you 
can configure another offset for those SIDs which do not fit into the 
existing range for such topology.

All of the above is internal to the node and no per topology SRGB 
advertisement is required. You advertise unique SID on a per prefix and 
per topology basis, but you do not need to configure each SID manually. 
Al you need to configure is the single prefix SID and per topology 
offset/size. It gives you the same simplicity for configuration as per 
topology SRGB, but without the need to advertise SRGB per topology.

thanks,
Peter

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 25 Aug 2015 11:19:24 +0000

Hi Robert and Peter,

I think we have already concluded on the list that we need per-protocol SRGB. But earlier on this thread I have expressed my opinion that within a single IGP we need a per-topology SRGB as well. So I think the current thread is for discussing the per-topology case.

Thanks
-Pushpasis

From: <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 25, 2015 at 4:44 PM
To: Peter Psenak <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Eric Rosen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Peter,

If on a given node I run OSPF and ISIS and I advertise differe SRGB block with each of them what is really "per node scope"

Each igp thinks it is per node in their understanding of what the node is, but between them I see no relation at all.

It would be rather a mistake to assue both igp have congruent base topologies which such condition seems not easy to avoid if you treat block as something sitting above both of them.

Thx,
R.

On Aug 25, 2015 12:53 PM, "Peter Psenak" <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

the discussion is not about advertising multiple SRGBs, but about the scope of the SRGB advertisement - currently it is a per node. The fact that you can advertise multiple SRGBs does not change its scope.

thanks,
Peter

Thx Peter !
R.

On Aug 25, 2015 11:44 AM, "Peter Psenak" <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

        Peter,

        In first sentence you say "single block" in second one you say
        "multiple
        blocks" so which one it is  ?

    Peter

        Thx,
        R.

        On Aug 25, 2015 11:25 AM, "Peter Psenak" <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>
        <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:

             Robert,

                 Peter,

                 "You can partition it in many ways, but the block is
        just one."

                 Likewise to me SRGB blocks for MT or MI do not need to be
                 continuos what
                 your earlier suggestion regarding offset would result with.

                 So I think the crux of this entire debate is this: are we
                 allowing non
                 continous SRGB pools per node or not (say one per
        topology).

             No matter how many partitions you have, still it's a single
        block
             consisting of multiple partitions.

             Yes, we are allowing non continuous SRGB per node - you can
             advertise multiple SRGB blocks per node - please see the
        OSPF/ISIS
             SR extensions.

             thanks,
             Peter

                 If not what you and Les are saying may indeed be ok,
        however for
                 deployment flexibility I would rather tend to opt for it.

                 Best,
                 R.

                 On Aug 25, 2015 9:48 AM, "Peter Psenak"
        <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
                 <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
                 <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
        <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>> wrote:

                      Hi Eric,

                      please see inline:

        that you
                 either need
        single SRGB
                 with per
                 prefix-SID is
                      "global"

                 encodings
                      have
                       > encodings needs adjustment.

                      I do not see any odds with the encodings. Current IGP
                 encoding supports
                      SRGB per each instance of the IGP.

                 even one
                      SRGB per

        what the
                      architecture is
                 of an
                      IGP, then
                 seems like a
                      major
        have an
                 SRGB per
                 have one
                      quantity
        hear some
                 hand-waving
        prefix-SIDs for
                 every new
                       > topology, but ...

                      I will keep repeating myself that such
        provisioning can be made
                      automatic, so the above point is not really
        convincing to me.

        one way
                 of setting up
        underlays by
                 using two
                 underlay.  If
                      you set
        instance
                 of OSPF, you
        supposed
                 to be?

                      fits very well in the existing IGP architecture - node

                       > MTID/algorithm SID, not per MTID/algorithm SRGB
        and IGP
                 encoding has
                 where it
                      says that
        and/or that
                 SRGBs are

                      "SR Global Block (SRGB): local property of an SR
        node."

                      Above makes it clear to me that SRGB has a per node
                 property and is
                      advertised by IGP as such. Prefix-SID is a prefix
        property
                 and as such
                      can be advertised per MTID topology, as any other
        prefix
                 attribute.

                      IGP encodings for OSPF and ISIS have been designed
        by a
                 team of people
                      from multiple vendors and some of them contributed
        to the SR
                      architecture document as well - the fact that we
        designed
                 the IGP
                      encoding the way it is clearly indicates what was
        the common
                      understanding of the SR architecture.

                 you end up
                      with
        TLVs for
                 the same
        stated
                 above.

                      the problem is that you create an overlap, where
        both SRGB and
                      prefix-SID would be carrying the same values. I
        suppose you
                 agree that
                      we do not need these fields to be associated with
        both SRGB
                 and SIDs.

        operator
                 (i.e. Single
                 prefer,
                      one of
                 to allow
                      more
        architecture and
                 encoding
        (but do not
                      require) a
        of each
                 routing
                       > algorithm;

                      no, we don't. SRGB scope is IGP instance. There is no
                 algorithm there.

        topology
                 of a
        means there
                 are already
                 restrictions
                      that don't
                 implementations out
                      there in

                      to change the existing encoding one would need a
        strong
                 reason. I do not
                      see anything which can not be done with the
        existing encodings.

                      thanks,
                      Peter

                 Prefix SID to
                      SRGB,
        used
                 for? Having the
        SRGB would be
                      redundant and
        backwards
                      compatible, but

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

---

From: Peter Psenak <[email-masked]>
Date: Tue, 25 Aug 2015 13:19:46 +0200

Robert,

On 8/25/15 13:14 , Robert Raszuk wrote:
> Peter,
>
> If on a given node I run OSPF and ISIS and I advertise differe SRGB
> block with each of them what is really "per node scope"

per node means per IGP. Nobody can prevent you to advertise different 
SRGBs in different IGPs.

thanks,
Peter

>
> Each igp thinks it is per node in their understanding of what the node
> is, but between them I see no relation at all.
>
> topologies which such condition seems not easy to avoid if you treat
> block as something sitting above both of them.
>
> Thx,
> R.
>
>     the discussion is not about advertising multiple SRGBs, but about
>     the scope of the SRGB advertisement - currently it is a per node.
>     The fact that you can advertise multiple SRGBs does not change its
>     scope.
>
>     thanks,
>     Peter
>
>
>
>                  On Aug 25, 2015 11:25 AM, "Peter Psenak"
>                           <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>                           <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>> wrote:
>
>                                Hi Eric,
>
>                                please see inline:
>
>                                 > [Peter] What you need is a different
>         label for same
>                           prefix per
>                                 > been defined, which suggests that
>         either the
>                           architecture or the
>                                 > supposed to have said, then I see the
>         following
>                  issues.
>                                 >
>                                 > 1. If a new topology is added by use
>         of the MT
>                  features
>                           of an
>                                IGP, then
>                                 > topology; then when you add a new
>         topology, you
>                  only
>                           have one
>                                quantity
>                                 > can't.  Why the difference?  I find
>         this really
>                           confusing -- exactly
>                                 > [Peter] The SR architecture from the
>         very beginning
>                           assumed per
>                                 > Can you point to a place in the
>         architecture
>                  document
>                           where it
>                                says that
>                                form
>         draft-ietf-spring-segment-routing-04.txt:
>
>                                 > [Peter] If you add MTID and algorithm
>         in SRGB
>                  as well,
>                           you end up
>                                with
>                                 > topology - inside SRGB and inside the
>         Prefix SID
>                           sub-TLV, which is
>                                 > clearly redundant.
>                                 >
>                                 > SRGB with per-topology SID-index as
>         well as single
>                           SID-index with
>                                 > per-topology SRGB). Depending on which
>         one the
>                  operators
>                           prefer,
>                                one of
>                                 > them becomes redundant.
>                                 >
>                                 > Also I don't think it's a good
>         trade-off to limit
>                           configuration
>                                 > I'm sure any changes could be made in
>         a backwards
>                           compatible manner.
>
>         <mailto:[email-masked] <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>
>                           <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 25 Aug 2015 13:29:28 +0200

Cool ... as long as I can have a freedom to run multiple instances of ISIS
(one per topology) with different blocks I am happy !

Cheers,
R.
On Aug 25, 2015 1:19 PM, "Peter Psenak" <[email-masked]> wrote:

>>                                 > This seems to be at odds with the way
>> the
>>                  control plane
>>                           encodings
>>                                have
>>                                 > Recall that this discussion started
>> with a
>>                  claim that
>>                           even one
>>                                SRGB per
>>                                 > [Peter] I'm not sure we want to
>> advertise
>>                  redundant data
>>                           to allow
>>                                more
>>                                 > perspective it's preferable to pick
>> single
>>                  approach.
>>                                 >
>>                                 > also to give unambiguous semantics to
>> all
>>                  combinations.
>>                                 >
>>                                 >
>>                                 >
>>                                 >
>>                                 >
>>
>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 25 Aug 2015 13:58:54 +0000

It appears there are varying opinions on deployment models. A global SID is used as an offset into a node’s local SRGB(s) in order to derive the ingress label used for the associated prefix (or other construct) for that node. There are two opinions on deployment. The first model is that the global SID is, in fact, global and you would use a different SID if you want to advertise a different segment, i.e., forwarding instruction. The second is that the global SID is not really global and maps to a different segment dependent on the protocol instance or topology. Of course, I favor the first model but wanted to hi-light the point of contention.
Thanks,
Acee

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 25, 2015 at 7:29 AM
To: "Peter Psenak (ppsenak)" <[email-masked]<mailto:[email-masked]>>
Cc: Stephane Litkowski <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Pushpasis Sarkar ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>, Eric C Rosen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Cool ... as long as I can have a freedom to run multiple instances of ISIS (one per topology) with different blocks I am happy !

Cheers,
R.

On Aug 25, 2015 1:19 PM, "Peter Psenak" <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

per node means per IGP. Nobody can prevent you to advertise different SRGBs in different IGPs.

thanks,
Peter

Thx,
R.

On Aug 25, 2015 12:53 PM, "Peter Psenak" <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Robert,

        So as long you can also configure multiple SRGBs per node the
        discussion
        is over :)

    thanks,
    Peter

        Thx Peter !
        R.

                 Peter,

                 In first sentence you say "single block" in second one
        you say
                 "multiple
                 blocks" so which one it is  ?

             Peter

                 Thx,
                 R.

                      Robert,

                          Peter,

                          "You can partition it in many ways, but the
        block is
                 just one."

                          Likewise to me SRGB blocks for MT or MI do not
        need to be
                          continuos what
                          your earlier suggestion regarding offset would
        result with.

                          So I think the crux of this entire debate is
        this: are we
                          allowing non
                          continous SRGB pools per node or not (say one per
                 topology).

                      No matter how many partitions you have, still it's
        a single
                 block
                      consisting of multiple partitions.

                      Yes, we are allowing non continuous SRGB per node
        - you can
                      advertise multiple SRGB blocks per node - please
        see the
                 OSPF/ISIS
                      SR extensions.

                      thanks,
                      Peter

                          If not what you and Les are saying may indeed
        be ok,
                 however for
                          deployment flexibility I would rather tend to
        opt for it.

                          Best,
                          R.

                          On Aug 25, 2015 9:48 AM, "Peter Psenak"
                 <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
        <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
                          <mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>>
                          <mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>>
                 <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
        <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>>> wrote:

                               Hi Eric,

                               please see inline:

        label for same
                          prefix per
                 that you
                          either need
                 single SRGB
                          with per
                          prefix-SID is
                               "global"
                                > and that an SRGB is per-node.

                               Prefix SID has a prefix scope, SRGB has a
        node scope.

                          encodings
                               have
        either the
                          architecture or the
                                > encodings needs adjustment.

                               I do not see any odds with the encodings.
        Current IGP
                          encoding supports
                               SRGB per each instance of the IGP.

                          even one
                               SRGB per
                                > algorithm was in violation of the
        architecture.

                               SR architecture never claimed per
        algorithm SRGB.

                 what the
                               architecture is
        following
                 issues.
        of the MT
                 features
                          of an
                               IGP, then
                          seems like a
                               major
                 have an
                          SRGB per
        topology, you
                 only
                          have one
                               quantity
                 hear some
                          hand-waving
                 prefix-SIDs for
                          every new

                 one way
                          of setting up
                 underlays by
                          using two
                          underlay.  If
                               you set
                 instance
                          of OSPF, you
        this really
                          confusing -- exactly
                 supposed
                          to be?

                               the difference is because SRGB is a node
        property
                 and SID
                          is a prefix
                               property. Each prefix can have many
        attributes and
                 SID is
                          just another
                               prefix attribute. It's similar to prefix
        metric,
                 which has
                          a per
                               topology scope. SRGB is like any other node
                 capability.
                          This actually
                               fits very well in the existing IGP
        architecture - node
                          capabilities are
                               never per topology. At the end you only
        have a
                 single label
                          block on a
                               device. You can partition it in many
        ways, but the
                 block is
                          just one.

        very beginning
                          assumed per
                 and IGP
                          encoding has
        architecture
                 document
                          where it
                               says that
                 and/or that
                          SRGBs are

                               form

                               "SR Global Block (SRGB): local property
        of an SR
                 node."

                               "IGP-prefix Segment, Prefix-SID: an
        IGP-Prefix
                 Segment is
                          an IGP
                               segment attached to an IGP prefix.

                               Above makes it clear to me that SRGB has
        a per node
                          property and is
                               advertised by IGP as such. Prefix-SID is
        a prefix
                 property
                          and as such
                               can be advertised per MTID topology, as
        any other
                 prefix
                          attribute.

                               IGP encodings for OSPF and ISIS have been
        designed
                 by a
                          team of people
                               from multiple vendors and some of them
        contributed
                 to the SR
                               architecture document as well - the fact
        that we
                 designed
                          the IGP
                               encoding the way it is clearly indicates
        what was
                 the common
                               understanding of the SR architecture.

        in SRGB
                 as well,
                          you end up
                               with
                 TLVs for
                          the same
        Prefix SID
                          sub-TLV, which is
                 stated
                          above.

                               the problem is that you create an
        overlap, where
                 both SRGB and
                               prefix-SID would be carrying the same
        values. I
                 suppose you
                          agree that
                               we do not need these fields to be
        associated with
                 both SRGB
                          and SIDs.

                 operator
                          (i.e. Single
        well as single
                          SID-index with
        one the
                 operators
                          prefer,
                               one of
                          to allow
                               more
                 architecture and
                          encoding
                 (but do not
                               require) a
                 of each
                          routing
                                > algorithm;

                               no, we don't. SRGB scope is IGP instance.
        There is no
                          algorithm there.

                 topology
                          of a
                 means there
                          are already
                          restrictions
                               that don't
        trade-off to limit
                          configuration
                          implementations out
                               there in
        a backwards
                          compatible manner.

                               to change the existing encoding one would
        need a
                 strong
                          reason. I do not
                               see anything which can not be done with the
                 existing encodings.

                               thanks,
                               Peter

                          Prefix SID to
                               SRGB,
                 used
                          for? Having the
                 SRGB would be
                               redundant and
                 backwards
                               compatible, but

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

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

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 25 Aug 2015 14:17:22 -0400

On 8/25/2015 9:58 AM, Acee Lindem (acee) wrote:
> It appears there are varying opinions on deployment models. A global SID
> is used as an offset into a node’s local SRGB(s) in order to derive the
> ingress label used for the associated prefix (or other construct) for
> that node. There are two opinions on deployment. The first model is that
> the global SID is, in fact, global and you would use a different SID if
> you want to advertise a different segment, i.e., forwarding instruction.
> The second is that the global SID is not really global and maps to a
> different segment dependent on the protocol instance or topology. Of
> course, I favor the first model but wanted to hi-light the point of
> contention.

So I guess the primary question is:  should the choice of deployment 
model be left to the operator, or should the architecture/signaling 
mandate one deployment model over the other?

My interpretation of the architecture is that it intends the first 
deployment model, with a global SID (SID maps globally to single 
forwarding instruction) and an SRGB that has node-wide scope.

However, as SPRING has no control plane of its own, it relies on the IGP 
to signal the SRGB.  As a result, if there are multiple IGP instances, 
it is possible for a single node to signal multiple SRGBs.  This means 
that the SRGB signaling is NOT per-node, but (at least) per IGP instance.

The architecture could require all the IGP instances on a given node to 
signal the same SRGB.  The discussion of the SRGB in the yang model 
shows pretty clearly that some people thought that this is a 
requirement, and some thought that it is not.  I think that discussion 
also shows that the overall feeling of the WG is that this requirement 
should not be imposed, and that it should be allowable for different IGP 
instances to advertise different SRGBs.  Of course, this now allows 
Acee's second deployment model.

And once we allow a different SRGB for each IGP instance, I don't 
understand why we wouldn't allow a different SRGB for each topology.  I 
haven't heard a technical reason for not allowing this; the only real 
argument has been "but it's too late to make any changes, even if they 
are backwards compatible".

I think everyone understands that a scheme that required multiple 
unrelated SIDs to be provisioned for each prefix would be a burden for 
the operators.  Peter has made a proposal in which the provisioning 
process assigns one prefix-SID to a prefix, where that prefix-SID 
represents the forwarding instruction for that prefix in the default 
topology.  Then prefix-SIDs for additional topologies can be 
automatically assigned by adding a topology-specific offset to the 
default-topology prefix-SIDs.  However, the topology-specific offset 
sounds a lot like an SRGB.  I don't really see what this proposal adds 
other than complexity.

Further, if one has 1000 prefixes and adds a new topology, advertising 
1000 new prefix-SIDs in order to avoid the need to advertise a single 
new SRGB does not seem like a very good trade-off.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 25 Aug 2015 20:34:55 +0200

Eric,

please see inline:

> that the SRGB signaling is NOT per-node, but (at least) per IGP instance.

right there is no problem with per IGP instance SRGB, we all agreed that 
it is valid and it is supported.

> Acee's second deployment model.

not really. Per IGP SRGB still fits well in first model.

> are backwards compatible".

the point I'm trying to make is that there is no functionality in the 
second model which can not be supported with existing first model. In 
such case I do not see any good reason to change the architecture and 
mess around with the existing IGP encoding.

> sounds a lot like an SRGB.  I don't really see what this proposal adds

why do you believe it adds complexity? Why is provisioning of the offset 
any more complex then provisioning the SRGB? Actually it is the same, 
the only difference is what is advertised.

> new SRGB does not seem like a very good trade-off.

prefixes are advertised in each topology anyway, so adding a single 
sub-TLV for prefix in each topology is certainly not a significant overhead.

thanks,
Peter

---

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

Robert (and Stephane) -

From: spring [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, August 25, 2015 4:15 AM
To: Peter Psenak (ppsenak)
Cc: [email-masked]; [email-masked]; Pushpasis Sarkar ([email-masked]); Eric C Rosen
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Peter,

[Les:] This is true until you face the problem of redistribution. If you have assigned SIDs 0 – 100 in the protocol specific SRGBs to the prefixes that each IGP is originating (and it would be “natural” to do that) then if I redistribute a prefix from one protocol to another the destination protocol has to assign a different SID to the redistributed prefix because the SID specified by the originating protocol conflicts w an existing use in the destination protocol. This can be done of course – but it is more complex and uses more resources (you now need multiple incoming labels for the same prefix in the forwarding plane).

Contrast this with a single SRGB shared by all protocols. SIDs are assigned per prefix w/o regard to what protocol advertises them. When a prefix is redistributed no second SID needs to be allocated and only a single incoming label is required per prefix.

For the case where two networks are being merged, the per protocol SRGB may be helpful because you likely already have conflicting SIDs. But extending this idea to be the way things need to be in all deployments ignores the more common case where we do not have SID conflicts and therefore have a much simpler deployment model using a protocol independent SRGB.

Please reread Acee’s posts- he has most clearly and succinctly stated the position that a number of us favor i.e., protocol independent SRGB for the most common cases – per protocol SRGB available for those cases where it may avoid SID reassignment.

Stephane – as the advocate of “SID consistency” I hope you appreciate the advantage of the global SRGB for most deployments.

   Les

Thx,
R.

thanks,
Peter

Thx Peter !
R.

        Peter,

    Peter

        Thx,
        R.

             Robert,

                 Peter,

             thanks,
             Peter

                 Best,
                 R.

                      Hi Eric,

                      please see inline:

        that you
                 either need
        single SRGB
                 with per
                 prefix-SID is
                      "global"

                 encodings
                      have

                 even one
                      SRGB per

        what the
                      architecture is
                 of an
                      IGP, then
                 seems like a
                      major
        have an
                 SRGB per
                 have one
                      quantity
        hear some
                 hand-waving
        prefix-SIDs for
                 every new

        one way
                 of setting up
        underlays by
                 using two
                 underlay.  If
                      you set
        instance
                 of OSPF, you
        supposed
                 to be?

        and IGP
                 encoding has
                 where it
                      says that
        and/or that
                 SRGBs are

                 you end up
                      with
        TLVs for
                 the same
        stated
                 above.

        operator
                 (i.e. Single
                 prefer,
                      one of
                 to allow
                      more
        architecture and
                 encoding
        (but do not
                      require) a
        of each
                 routing

        topology
                 of a
        means there
                 are already
                 restrictions
                      that don't
                 implementations out
                      there in

                      thanks,
                      Peter

                 Prefix SID to
                      SRGB,
        used
                 for? Having the
        SRGB would be
                      redundant and
        backwards
                      compatible, but

---

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

Les,

How do you do anycast in data plane in your proposal ?

Thx,
R.

On Tue, Aug 25, 2015 at 9:53 PM, Les Ginsberg (ginsberg) <[email-masked]

> Robert (and Stephane) -
>
>
>
> *From:* spring [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Tuesday, August 25, 2015 4:15 AM
> *To:* Peter Psenak (ppsenak)
> *Cc:* [email-masked]; [email-masked]; Pushpasis Sarkar (
> [email-masked]); Eric C Rosen
> *Subject:* Re: [spring] SRGBs, indexes, and topologies within a domain
>
>
>
> Peter,
>
> *[Les:] This is true until you face the problem of redistribution. If you
> have assigned SIDs 0 – 100 in the protocol specific SRGBs to the prefixes
> that each IGP is originating (and it would be “natural” to do that) then if
> I redistribute a prefix from one protocol to another the destination
> protocol has to assign a different SID to the redistributed prefix because
> the SID specified by the originating protocol conflicts w an existing use
> in the destination protocol. This can be done of course – but it is more
> complex and uses more resources (you now need multiple incoming labels for
> the same prefix in the forwarding plane).*
>
> *Contrast this with a single SRGB shared by all protocols. SIDs are
> assigned per prefix w/o regard to what protocol advertises them. When a
> prefix is redistributed no second SID needs to be allocated and only a
> single incoming label is required per prefix.*
>
> *For the case where two networks are being merged, the per protocol SRGB
> may be helpful because you likely already have conflicting SIDs. But
> extending this idea to be the way things need to be in all deployments
> ignores the more common case where we do not have SID conflicts and
> therefore have a much simpler deployment model using a protocol independent
> SRGB.*
>
> *Please reread Acee’s posts- he has most clearly and succinctly stated the
> position that a number of us favor i.e., protocol independent SRGB for the
> most common cases – per protocol SRGB available for those cases where it
> may avoid SID reassignment.*
>
> *Stephane – as the advocate of “SID consistency” I hope you appreciate the
> advantage of the global SRGB for most deployments.*
>
> *   Les*
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 25 Aug 2015 21:49:28 +0000

Robert –

You have asked exactly the opposite of the question you should have asked. ☺
IF there is a consistent SRGB – not only among multiple protocols on a given node – but also among all the nodes in the network – then anycast is easy.
Where things get complicated is when SRGBs differ. Read Pushpasis’s draft:  https://www.ietf.org/id/draft-psarkar-spring-mpls-anycast-segments-00.txt

   Les

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, August 25, 2015 1:17 PM
To: Les Ginsberg (ginsberg)
Cc: Peter Psenak (ppsenak); [email-masked]; [email-masked]; Pushpasis Sarkar ([email-masked]); Eric C Rosen
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Les,

Thx,
R.

On Tue, Aug 25, 2015 at 9:53 PM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert (and Stephane) -

From: spring [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Tuesday, August 25, 2015 4:15 AM
To: Peter Psenak (ppsenak)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Pushpasis Sarkar ([email-masked]<mailto:[email-masked]>); Eric C Rosen
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Peter,

   Les

Thx,
R.

thanks,
Peter

Thx Peter !
R.

        Peter,

    Peter

        Thx,
        R.

             Robert,

                 Peter,

             thanks,
             Peter

                 Best,
                 R.

                      Hi Eric,

                      please see inline:

        that you
                 either need
        single SRGB
                 with per
                 prefix-SID is
                      "global"

                 encodings
                      have

                 even one
                      SRGB per

        what the
                      architecture is
                 of an
                      IGP, then
                 seems like a
                      major
        have an
                 SRGB per
                 have one
                      quantity
        hear some
                 hand-waving
        prefix-SIDs for
                 every new

        one way
                 of setting up
        underlays by
                 using two
                 underlay.  If
                      you set
        instance
                 of OSPF, you
        supposed
                 to be?

        and IGP
                 encoding has
                 where it
                      says that
        and/or that
                 SRGBs are

                 you end up
                      with
        TLVs for
                 the same
        stated
                 above.

        operator
                 (i.e. Single
                 prefer,
                      one of
                 to allow
                      more
        architecture and
                 encoding
        (but do not
                      require) a
        of each
                 routing

        topology
                 of a
        means there
                 are already
                 restrictions
                      that don't
                 implementations out
                      there in

                      thanks,
                      Peter

                 Prefix SID to
                      SRGB,
        used
                 for? Having the
        SRGB would be
                      redundant and
        backwards
                      compatible, but

---

From: <[email-masked]>
Date: Tue, 25 Aug 2015 23:28:12 +0000

Hi Peter,

As I already pointed to Les, using an offset creates some holes in index space that we need to manage when extending a block.

Let's say that we have SRGB [100-199] (to simplify) and you divide your block in two so you will have topology #1 using [100-149] and topology #2 using [150-199] using an offset of 50.
Now I need to add a 51th node in my network, I cannot use index 51 because it will overlap with topology#2 :(, so I will need to skip indexes from 51 to 100, and restarts my numbering with index 101. This management of holes is not automated.

Best Regards,

Stephane

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Tuesday, August 25, 2015 13:18
To: LITKOWSKI Stephane SCE/IBNF; Eric C Rosen; Pushpasis Sarkar; SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Hi Stephane,

On 8/25/15 12:58 , [email-masked] wrote:
>>> then a new set of prefix-SIDs must be provisioned.  This seems like 
>>> a major provisioning task.  The alternative would be to have an SRGB 
>>> per topology; then when you add a new topology, you only have one 
>>> quantity to provision (or one per platform perhaps).  I hear some 
>>> hand-waving about how easy it is to provision new prefix-SIDs for 
>>> every new topology, but ...
>

Example:

SRGB 1600-24000

I would assume that when you start to assign your SIDs for the default topology, you would not pick random values, but start from the beginning. So let' assume you are using 16001 to 16500 for nodes in default topology.

Now you need to add a new topology. You configure and offset of 2k for it, so the advertised SIDs for the new topology would start from 18001. 
If we assume that the 2k would be a reasonable size for each topology you can have 4 topologies with 2k SIDs per topology.

If for whatever reason you run out of the SID space in any topology, you can configure another offset for those SIDs which do not fit into the existing range for such topology.

All of the above is internal to the node and no per topology SRGB advertisement is required. You advertise unique SID on a per prefix and per topology basis, but you do not need to configure each SID manually. 
Al you need to configure is the single prefix SID and per topology offset/size. It gives you the same simplicity for configuration as per topology SRGB, but without the need to advertise SRGB per topology.

thanks,
Peter
>
>
> Best Regards,
>
> Stephane
>
>
>
> ______________________________________________________________________
> 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 distributed, used or copied without authorisation.

---

From: <[email-masked]>
Date: Tue, 25 Aug 2015 23:31:05 +0000

I agree that in the second case the index is scoped (to a topology or algorithm or whatever …).

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Tuesday, August 25, 2015 15:59
To: Robert Raszuk; Peter Psenak (ppsenak)
Cc: LITKOWSKI Stephane SCE/IBNF; [email-masked]; Pushpasis Sarkar ([email-masked]); Eric C Rosen
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Cheers,
R.

thanks,
Peter

Thx,
R.

    Robert,

    thanks,
    Peter

        Thx Peter !
        R.

                 Peter,

             Peter

                 Thx,
                 R.

                      Robert,

                          Peter,

                      thanks,
                      Peter

                          Best,
                          R.

                               Hi Eric,

                               please see inline:

        label for same
                          prefix per
                 that you
                          either need
                 single SRGB
                          with per
                          prefix-SID is
                               "global"

                          encodings
                               have
        either the
                          architecture or the

                          even one
                               SRGB per

                 what the
                               architecture is
        following
                 issues.
        of the MT
                 features
                          of an
                               IGP, then
                          seems like a
                               major
                 have an
                          SRGB per
        topology, you
                 only
                          have one
                               quantity
                 hear some
                          hand-waving
                 prefix-SIDs for
                          every new

                 one way
                          of setting up
                 underlays by
                          using two
                          underlay.  If
                               you set
                 instance
                          of OSPF, you
        this really
                          confusing -- exactly
                 supposed
                          to be?

        very beginning
                          assumed per
                 and IGP
                          encoding has
        architecture
                 document
                          where it
                               says that
                 and/or that
                          SRGBs are

                               form

        in SRGB
                 as well,
                          you end up
                               with
                 TLVs for
                          the same
        Prefix SID
                          sub-TLV, which is
                 stated
                          above.

                 operator
                          (i.e. Single
        well as single
                          SID-index with
        one the
                 operators
                          prefer,
                               one of
                          to allow
                               more
                 architecture and
                          encoding
                 (but do not
                               require) a
                 of each
                          routing

                 topology
                          of a
                 means there
                          are already
                          restrictions
                               that don't
        trade-off to limit
                          configuration
                          implementations out
                               there in
        a backwards
                          compatible manner.

                               thanks,
                               Peter

                          Prefix SID to
                               SRGB,
                 used
                          for? Having the
                 SRGB would be
                               redundant and
                 backwards
                               compatible, but

---

From: <[email-masked]>
Date: Tue, 25 Aug 2015 23:46:03 +0000

Hi,

As you shown, different deployments mean different constraints, so I think we all agree that supporting both (using same SRGB or different SRGB per protocol) is required, and it would be up to the user to choose the best option based on its design.

Brgds,

Stephane

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Tuesday, August 25, 2015 21:54
To: Robert Raszuk; Peter Psenak (ppsenak)
Cc: LITKOWSKI Stephane SCE/IBNF; [email-masked]; Pushpasis Sarkar ([email-masked]); Eric C Rosen
Subject: RE: [spring] SRGBs, indexes, and topologies within a domain

Robert (and Stephane) -

Peter,

   Les

Thx,
R.

thanks,
Peter

Thx Peter !
R.

        Peter,

    Peter

        Thx,
        R.

             Robert,

                 Peter,

             thanks,
             Peter

                 Best,
                 R.

                      Hi Eric,

                      please see inline:

        that you
                 either need
        single SRGB
                 with per
                 prefix-SID is
                      "global"

                 encodings
                      have

                 even one
                      SRGB per

        what the
                      architecture is
                 of an
                      IGP, then
                 seems like a
                      major
        have an
                 SRGB per
                 have one
                      quantity
        hear some
                 hand-waving
        prefix-SIDs for
                 every new

        one way
                 of setting up
        underlays by
                 using two
                 underlay.  If
                      you set
        instance
                 of OSPF, you
        supposed
                 to be?

        and IGP
                 encoding has
                 where it
                      says that
        and/or that
                 SRGBs are

                 you end up
                      with
        TLVs for
                 the same
        stated
                 above.

        operator
                 (i.e. Single
                 prefer,
                      one of
                 to allow
                      more
        architecture and
                 encoding
        (but do not
                      require) a
        of each
                 routing

        topology
                 of a
        means there
                 are already
                 restrictions
                      that don't
                 implementations out
                      there in

                      thanks,
                      Peter

                 Prefix SID to
                      SRGB,
        used
                 for? Having the
        SRGB would be
                      redundant and
        backwards
                      compatible, but

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 26 Aug 2015 00:00:58 +0000

Hi Stephane - Why do need to use different label blocks, i.e., for
different topologies? You have two other simpler options:

    1. Just allocate SIDs to <prefix, mt_id> tuples. So if a node has SIDs
[1-10], just allocate a unique SID to each unique combinations of tuple.
    2. For a node, allocate ranges of SIDs to a topology rather than
trying to allocate SRGBs. Then the SID would map to whatever the label the
offset correspond to in the local node’s SRGB(s).

Thanks,
Acee 

On 8/25/15, 7:28 PM, "spring on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi Peter,
>
>As I already pointed to Les, using an offset creates some holes in index
>space that we need to manage when extending a block.
>
>Let's say that we have SRGB [100-199] (to simplify) and you divide your
>block in two so you will have topology #1 using [100-149] and topology #2
>using [150-199] using an offset of 50.
>Now I need to add a 51th node in my network, I cannot use index 51
>because it will overlap with topology#2 :(, so I will need to skip
>indexes from 51 to 100, and restarts my numbering with index 101. This
>management of holes is not automated.
>
>Best Regards,
>
>Stephane
>
>topology, you would not pick random values, but start from the beginning.
>So let' assume you are using 16001 to 16500 for nodes in default topology.
>
>If we assume that the 2k would be a reasonable size for each topology you
>can have 4 topologies with 2k SIDs per topology.
>
>> 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.
>>
>__________________________________________________________________________
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Aug 2015 00:03:09 +0000

Stephane -

> From: spring [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, August 25, 2015 4:28 PM
> To: Peter Psenak (ppsenak); Eric C Rosen; Pushpasis Sarkar; SPRING WG
> As I already pointed to Les, using an offset creates some holes in index space
> that we need to manage when extending a block.
> 
> Let's say that we have SRGB [100-199] (to simplify) and you divide your block
> in two so you will have topology #1 using [100-149] and topology #2 using
> [150-199] using an offset of 50.
> Now I need to add a 51th node in my network, I cannot use index 51 because
> it will overlap with topology#2 :(, so I will need to skip indexes from 51 to 100,
> and restarts my numbering with index 101. This management of holes is not
> automated.

[Les:] The same issue arises w topology specific SRGBs.   Let's take an example.

I am setting up my network for SR. I anticipate that I will need 500 labels per topology and I anticipate a maximum of 5 topologies. In order to be prepared for the "worst case" I decide to allocate enough for 1000 labels/topology and 10 topologies and I reserve it all up front because - as you have documented in an earlier post - assuming I can allocate additional SRGB space when I need it without either rebooting the node or shutting down some applications I am using is not safe.

Using the  offset approach:

    srgb 16000-25999
    srgb offset topology 1 1000 !Please don't quibble about syntax :-)
    srgb offset topology 2 2000

I only configure offsets for the topologies that are currently active. Since I have reserved the label space in a topology independent way I am free to allocate space for each topology only when they are needed - and if I find that I am using far less than 1000 labels when the next topology is enabled I could choose to do:

   srgb offset topology 3 2500

And now I can support more topologies than originally planned for if necessary. 

Now let's look at a per topology approach. You could allocate topology specific SRGBs only when you need them, but this leaves you open to cases where the desired label space is in use - so again you decide to allocate all of the label space up front.  But now you have to decide how many SRGBs to allocate. So you do:

  srgb 16000 16999 topology 0
  srgb 17000 17999 topology 1
...
   srgb 25000 25999 topology 9

You can support 10 topologies - but if you find that 1000 labels/topology is far more than you need but 10 topologies is fewer than you need you can't easily accommodate the additional topologies without reconfiguring the srgb's.

The key points here are:

  o Allocating all the labels you will ever need up front is the safest method
  o Allocating a single SRGB and partitioning it as you need it provides a bit more flexibility
  o In either approach you likely have unused label space ("holes").

Clearly either method will work .
But the main point is that the single SRGB is not more problematic than per topology SRGB (as your reply suggests) - if anything it is more flexible.

   Les

> topology, you would not pick random values, but start from the beginning. So
> let' assume you are using 16001 to 16500 for nodes in default topology.
> 
> Now you need to add a new topology. You configure and offset of 2k for it,
> so the advertised SIDs for the new topology would start from 18001.
> If for whatever reason you run out of the SID space in any topology, you can
> configure another offset for those SIDs which do not fit into the existing
> range for such topology.
> 
> advertisement is required. You advertise unique SID on a per prefix and per
> topology basis, but you do not need to configure each SID manually.
> Al you need to configure is the single prefix SID and per topology offset/size.
> It gives you the same simplicity for configuration as per topology SRGB, but
> without the need to advertise SRGB per topology.
> 
> thanks,
> Peter
> >
> >
> > Best Regards,
> >
> > Stephane
> >
> >
> >
> >
> __________________________________________________________
> __________________________________________________________
> _____
> 
> 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.
> 
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 26 Aug 2015 01:01:43 +0000

In the  1st example below (separate unique index per topology) it seems topology 2 can have only 500 nodes but 
in the 2nd example all 10 topologies *can* have 1000 nodes. So it's not necessary to have/configure 1000 label 
space for topology 2 in the 2nd example. My point is to illustrate the point of running out SRGB space is an issue 
in the example below and that ought to handle any ways in either case.

But I would note - maintaining unique indices across all nodes (starting from the starting point of the SRGB) for 
each topology is way harder than maintaining one set of unique index per node.  With 10 topologies in the below example, 
with 1000 nodes per topology,  in per index case operator ought to maintain 10 * 1000 = 10000 unique objects. But in 
the other case of per topology SRGB operator has to only maintain 
1000 (unique labels/SID Index) + 10 (SRGB offsets) = 1010 unique objects in total.   I am not sure how maintaining 
*more* unique objects would be easier.

Remember also in the first case across all nodes, starting point of  SRGB for each topology has to be 
maintained  without indicating the same through the underlying protocol (IGP).

I would request this to capture the essence of the discussion in the architecture document and leave this to 
operators on how they feel to provision and maintain the network.  But flexibility to have either way is critical 
and I don't see any reason to deny the per topology  SRGB option.

--
Uma C.

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, August 25, 2015 5:03 PM
To: [email-masked]; Peter Psenak (ppsenak); Eric C Rosen; Pushpasis Sarkar; SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Stephane -

> As I already pointed to Les, using an offset creates some holes in 
> index space that we need to manage when extending a block.
> 
> Let's say that we have SRGB [100-199] (to simplify) and you divide 
> your block in two so you will have topology #1 using [100-149] and 
> topology #2 using [150-199] using an offset of 50.

    srgb 16000-25999

The key points here are:

   Les

> >>> then a new set of prefix-SIDs must be provisioned.  This seems 
> >>> like a major provisioning task.  The alternative would be to have 
> >>> an SRGB per topology; then when you add a new topology, you only 
> >>> have one quantity to provision (or one per platform perhaps).  I 
> >>> hear some hand-waving about how easy it is to provision new 
> >>> prefix-SIDs for every new topology, but ...
> >
> > Could you explain how ? Based on past discussions, it does not seem 
> > to be
> so easy.
> 
> beginning. So let' assume you are using 16001 to 16500 for nodes in default topology.
> 
> If for whatever reason you run out of the SID space in any topology, 
> you can configure another offset for those SIDs which do not fit into 
> the existing range for such topology.
> 
> advertisement is required. You advertise unique SID on a per prefix 
> and per topology basis, but you do not need to configure each SID manually.
> It gives you the same simplicity for configuration as per topology 
> SRGB, but without the need to advertise SRGB per topology.
> 
> thanks,
> Peter
> >
> >
> > Best Regards,
> >
> > Stephane
> >
> >
> >
> >
> ____________
> > 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 
> > 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.
> >
> >
> 
> 
> 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 distributed, used or copied without authorisation.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Aug 2015 01:43:15 +0000

Uma -

> From: Uma Chunduri [mailto:[email-masked]]
> Sent: Tuesday, August 25, 2015 6:02 PM
> To: Les Ginsberg (ginsberg); [email-masked]; Peter Psenak
> (ppsenak); Eric C Rosen; Pushpasis Sarkar; SPRING WG
> In the  1st example below (separate unique index per topology) it seems
> topology 2 can have only 500 nodes but in the 2nd example all 10 topologies
> *can* have 1000 nodes. So it's not necessary to have/configure 1000 label
> space for topology 2 in the 2nd example. My point is to illustrate the point of
> running out SRGB space is an issue in the example below and that ought to
> handle any ways in either case.

[Les:] I deliberately used an example where in neither approach would SRGB allocation be required after startup. This is to avoid the problematic scenario where you need to dynamically reserve more label space but it isn't available because some other application is using at least one label in the space you want to reserve. I tried to be fair by making sure neither approach had an advantage regarding this point.

With either approach you could run out of SRGB space and you could encounter the same problems as regards trying to reserve more. This isn't a difference or an advantage for either method.

> 
> But I would note - maintaining unique indices across all nodes (starting from
> the starting point of the SRGB) for each topology is way harder than
> maintaining one set of unique index per node.  With 10 topologies in the
> below example, with 1000 nodes per topology,  in per index case operator
> ought to maintain 10 * 1000 = 10000 unique objects. But in the other case of
> per topology SRGB operator has to only maintain

[Les:] Regardless of approach, you have a unique label for a given prefix/topology pair. So you have the same number of "objects" in both cases. This is very clear if you look at what is installed in the forwarding plane.
Do not make the mistake of confusing CLI syntax w the number of labels being used.

> 
> Remember also in the first case across all nodes, starting point of  SRGB for
> each topology has to be maintained  without indicating the same through the
> underlying protocol (IGP).

[Les:] Indeed - which is less information for the IGPs to advertise. So one could consider this a (small) advantage for the one SRGB approach. :-)

> 
> I would request this to capture the essence of the discussion in the
> architecture document and leave this to operators on how they feel to
> provision and maintain the network.  But flexibility to have either way is
> critical and I don't see any reason to deny the per topology  SRGB option.

[Les:] Topology specific SRGBs requires a specification change for the IGPs. The new advertisements are NOT backwards compatible w existing implementations. So we cannot simply say "do what you please". 
Peter has repeatedly made this point - and also pointed out that since the prefix advertisements as currently defined in the IGP drafts includes topology identifiers including the topology identifier in the SRGB advertisement is redundant.

   Les

> I am setting up my network for SR. I anticipate that I will need 500 labels per
> topology and I anticipate a maximum of 5 topologies. In order to be prepared
> for the "worst case" I decide to allocate enough for 1000 labels/topology and
> 10 topologies and I reserve it all up front because - as you have documented
> in an earlier post - assuming I can allocate additional SRGB space when I need
> it without either rebooting the node or shutting down some applications I am
> using is not safe.
> 
> I only configure offsets for the topologies that are currently active. Since I
> have reserved the label space in a topology independent way I am free to
> allocate space for each topology only when they are needed - and if I find
> that I am using far less than 1000 labels when the next topology is enabled I
> could choose to do:
> 
> Now let's look at a per topology approach. You could allocate topology
> specific SRGBs only when you need them, but this leaves you open to cases
> where the desired label space is in use - so again you decide to allocate all of
> the label space up front.  But now you have to decide how many SRGBs to
> allocate. So you do:
> 
> You can support 10 topologies - but if you find that 1000 labels/topology is far
> more than you need but 10 topologies is fewer than you need you can't
> easily accommodate the additional topologies without reconfiguring the
> srgb's.
> 
> The key points here are:
> 
> But the main point is that the single SRGB is not more problematic than per
> topology SRGB (as your reply suggests) - if anything it is more flexible.
> 
>    Les
> 
> >
> > Best Regards,
> >
> > Stephane
> >
> offset/size.
> > > be

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 26 Aug 2015 05:30:51 +0000

Hi Les,

I think you are mixing the two terms 'consistent SRGB' and 'global SRGB’ here. In my understanding ‘global SRGB’ means one SRGB for all protocols on a given node. It does not necessarily mean they will be consistent across nodes.

Thanks
-Pushpasis

From: "Les Ginsberg (ginsberg)"
Date: Wednesday, August 26, 2015 at 3:19 AM
To: Robert Raszuk
Cc: "Peter Psenak (ppsenak)", "[email-masked]<mailto:[email-masked]>", "[email-masked]<mailto:[email-masked]>", Pushpasis Sarkar, Eric Rosen
Subject: RE: [spring] SRGBs, indexes, and topologies within a domain

Robert –

   Les

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, August 25, 2015 1:17 PM
To: Les Ginsberg (ginsberg)
Cc: Peter Psenak (ppsenak); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Pushpasis Sarkar ([email-masked]<mailto:[email-masked]>); Eric C Rosen
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Les,

Thx,
R.

Peter,

   Les

Thx,
R.

thanks,
Peter

Thx Peter !
R.

        Peter,

    Peter

        Thx,
        R.

             Robert,

                 Peter,

             thanks,
             Peter

                 Best,
                 R.

                      Hi Eric,

                      please see inline:

        that you
                 either need
        single SRGB
                 with per
                 prefix-SID is
                      "global"

                 encodings
                      have

                 even one
                      SRGB per

        what the
                      architecture is
                 of an
                      IGP, then
                 seems like a
                      major
        have an
                 SRGB per
                 have one
                      quantity
        hear some
                 hand-waving
        prefix-SIDs for
                 every new

        one way
                 of setting up
        underlays by
                 using two
                 underlay.  If
                      you set
        instance
                 of OSPF, you
        supposed
                 to be?

        and IGP
                 encoding has
                 where it
                      says that
        and/or that
                 SRGBs are

                 you end up
                      with
        TLVs for
                 the same
        stated
                 above.

        operator
                 (i.e. Single
                 prefer,
                      one of
                 to allow
                      more
        architecture and
                 encoding
        (but do not
                      require) a
        of each
                 routing

        topology
                 of a
        means there
                 are already
                 restrictions
                      that don't
                 implementations out
                      there in

                      thanks,
                      Peter

                 Prefix SID to
                      SRGB,
        used
                 for? Having the
        SRGB would be
                      redundant and
        backwards
                      compatible, but

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 26 Aug 2015 05:35:47 +0000

Hi Les,

>Peter has repeatedly made this point - and also pointed out that since the prefix advertisements as currently defined in the IGP drafts includes topology identifiers including the topology identifie…
[Pushpasis] Why not add a MT-SR_Capability Sub/TLV then? That way it won’t break backward compatibility? 

Thanks
-Pushpasis

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 26 Aug 2015 05:59:07 +0000

>> But I would note - maintaining unique indices across all nodes
            >> (starting from the starting point of the SRGB) for each topology is
            >> way harder than maintaining one set of unique index per node.  With 10
            >> topologies in the below example, with 1000 nodes per topology,  in per
            >> index case operator ought to maintain 10 * 1000 = 10000 unique
            >> objects. But in the other case of per topology SRGB operator has to
            >> only maintain

      >[Les:] Regardless of approach, you have a unique label for a given prefix/topology pair.
      >So you have the same number of "objects" in both cases. This is very clear if you look at
      >what is installed in the forwarding plane. Do not make the mistake of confusing CLI
      >syntax w the number of labels being used.

[Uma]:  Les, No- I was not making any mistake of confusing with CLI syntax. Also, I was not at
all taking about uniqueness from  forwarding plane PoV. In either approach those
of course would be unique from  forwarding plane PoV.

The point is maintaining unique SID values per topology and per algorithm would be from
operational standpoint is excessively difficult (as we can see unique objects to be
provisioned would be multiplied) and easily avoidable.

--
Uma C.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 26 Aug 2015 09:23:01 +0200

Hi Uma,

> provisioned would be multiplied) and easily avoidable.

right, but to do that you do not need per topology SRGB.

thanks,
Peter

---

From: <[email-masked]>
Date: Wed, 26 Aug 2015 07:25:30 +0000

Hi Pushpasis,

I just want to remember that the discussion is not only for MT, but there was also a thread for per algorithm SRGB (as presented in Prague). IMO, there must be some consistency in the choice we do.
Regarding encoding nothing is impossible (as example a new subTLV can be created ensuring backward compatibility).
I would say let's first have a consensus of what is good to do independently of the encoding. 

Best Regards,

-----Original Message-----
From: Pushpasis Sarkar [mailto:[email-masked]] 
Sent: Wednesday, August 26, 2015 07:36
To: Les Ginsberg (ginsberg); Uma Chunduri; LITKOWSKI Stephane SCE/IBNF; Peter Psenak (ppsenak); Eric Rosen; SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Hi Les,

Thanks
-Pushpasis

---

From: Peter Psenak <[email-masked]>
Date: Wed, 26 Aug 2015 09:27:46 +0200

Hi Stephane,

> Now I need to add a 51th node in my network, I cannot use index 51 because it will overlap with topology#2 :(, so I will need to skip indexes from 51 to 100, and restarts my numbering with index 10…

how is this different to the case where you have two per topology SRGBs 
of 100-149 and 150-199 and now you need 51st SID? It is exactly the same 
problem. You need to allocate a new SRGB.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Aug 2015 09:29:28 +0200

Les,

You have clearly misunderstood the scenario/question :)

I am talking not about anycast to SR devices (what the draft you quote is
all about), but periodic anycast across N topologies to the same prefix on
the single device.

If I allocate single SID to prefix regardless which protocol/topology
advertitses such tuple how do I construct different data plane forwarding
in transit nodes assuming flat LFIBs ?

And with that I do not want to readvertise anything in IGP each type my
forwarding preference to said prefix across topologies changes.

Also as Eric commented already a workaround to bring up new prefix in such
case has severe application level consequences, hence - while doable from
network point of view - it would rather not be a wise deployment choice.

Best,
r.

On Tue, Aug 25, 2015 at 11:49 PM, Les Ginsberg (ginsberg) <
[email-masked]> wrote:

> Robert –
>
>
>
> You have asked exactly the opposite of the question you should have asked.
> J
>
> IF there is a consistent SRGB – not only among multiple protocols on a
> given node – but also among all the nodes in the network – then anycast is
> easy.
>
> Where things get complicated is when SRGBs differ. Read Pushpasis’s
> draft:
> https://www.ietf.org/id/draft-psarkar-spring-mpls-anycast-segments-00.txt
>
>
>
>    Les
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Tuesday, August 25, 2015 1:17 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Peter Psenak (ppsenak); [email-masked];
> [email-masked]; Pushpasis Sarkar ([email-masked]); Eric C Rosen
>
> On Tue, Aug 25, 2015 at 9:53 PM, Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
> Robert (and Stephane) -
>
>
>

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 26 Aug 2015 07:29:31 +0000

Hi Stephane,

I agree. And like we decided we need per-protocol SRGB, on the same lines, I think per-topology and per-algorithm SRGBs should also be allowed. I have said enough on the list already. Time for others to express their thoughts and opinions.

Thanks
-Pushpasis

---

From: Peter Psenak <[email-masked]>
Date: Wed, 26 Aug 2015 09:37:12 +0200

Hi Stephane,

> I just want to remember that the discussion is not only for MT, but there was also a thread for per algorithm SRGB (as presented in Prague). IMO, there must be some consistency in the choice we do.

agreed.

> Regarding encoding nothing is impossible (as example a new subTLV can be created ensuring backward compatibility).

true, but before you decide to add a new subTLV, there needs to be a 
requirement which can not be satisfied with the existing ones.

> I would say let's first have a consensus of what is good to do independently of the encoding.

I believe we all agree on what is "good to do". There are multiple ways 
how that can be done. One that works today and one that requires change 
in SR architecture and protocol encoding.

thanks,
Peter

---

From: <[email-masked]>
Date: Wed, 26 Aug 2015 07:46:12 +0000

Hi Peter,

Yes I need to allocate a new SRGB, but my index space will be contiguous and I will be able to use the index 51 in each scope.

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Wednesday, August 26, 2015 09:28
To: LITKOWSKI Stephane SCE/IBNF; Eric C Rosen; Pushpasis Sarkar; SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Hi Stephane,

> Now I need to add a 51th node in my network, I cannot use index 51 because it will overlap with topology#2 :(, so I will need to skip indexes from 51 to 100, and restarts my numbering with index 10…

how is this different to the case where you have two per topology SRGBs of 100-149 and 150-199 and now you need 51st SID? It is exactly the same problem. You need to allocate a new SRGB.

thanks,
Peter

>>>> a major provisioning task.  The alternative would be to have an 
>>>> SRGB per topology; then when you add a new topology, you only have 
>>>> one quantity to provision (or one per platform perhaps).  I hear 
>>>> some hand-waving about how easy it is to provision new prefix-SIDs 
>>>> for every new topology, but ...
>>
>> _____________________________________________________________________
>> _ ___________________________________________________
>>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 26 Aug 2015 10:43:13 +0200

Hi Stephane,

> Yes I need to allocate a new SRGB, but my index space will be contiguous and I will be able to use the index 51 in each scope.

configuration wise same can be achieved with the offsets - think of it 
as an internal SRGB local to the box. The only difference is what is 
advertised.

1. per topology SRGB

4 SRGBs:

100-149 topology 1
150-199 topology 2
200-249 topology 1
250-299 topology 2

prefix51, topology 1 - SID index 51 -> SID 200
prefix51, topology 2 - SID index 51 -> SID 250

What is advertised:

4 SRGBs (as above), prefix51 SID index 51

-----------

2. Per topology offset

SRGB 100-299

4 offsets (local to the box):

0-49 topology 1
50-99 topology 2
100-149 topology 1
150-199 topology 2

prefix51, topology 1 - SID index 51 -> SID 200
prefix51, topology 2 - SID index 51 -> SID 250

What is advertised:

1 SRGB (as above), 2 prefix SIDs - 101, 151

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Aug 2015 10:49:57 +0200

Peter,

Your example is ok for the indexed srgb case. Yes I agree that in such case
what you present seems fine.

But if (as most operators I spoke with) are planning deployment of absolute
srgb why would I need to introduce indexes at all to deal with per topology
blocks rather then just advertise basic index less absolute blocks to start
with.

Thx,
r.

On Wed, Aug 26, 2015 at 10:43 AM, Peter Psenak <[email-masked]> wrote:

>> Yes I need to allocate a new SRGB, but my index space will be contiguous
>> and I will be able to use the index 51 in each scope.
>>
>
> configuration wise same can be achieved with the offsets - think of it as
> an internal SRGB local to the box. The only difference is what is
> advertised.
>
>
> 1. per topology SRGB
>
> 4 SRGBs:
>
> 100-149 topology 1
> 150-199 topology 2
> 200-249 topology 1
> 250-299 topology 2
>
>>> because it will overlap with topology#2 :(, so I will need to skip indexes
>>> from 51 to 100, and restarts my numbering with index 101. This management
>>> of holes is not automated.
>>>
>>
>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que
>>> les pieces jointes. Les messages electroniques etant susceptibles

---

From: Peter Psenak <[email-masked]>
Date: Wed, 26 Aug 2015 11:29:41 +0200

Robert,

On 8/26/15 10:49 , Robert Raszuk wrote:
> Peter,
>
> Your example is ok for the indexed srgb case. Yes I agree that in such
> case what you present seems fine.
>
> But if (as most operators I spoke with) are planning deployment of
> absolute srgb why would I need to introduce indexes at all to deal with
> per topology blocks rather then just advertise basic index less absolute
> blocks to start with.

not sure what absolute SRGB means.

Offsets are used to simplify the configuration and as such are optional.

thanks,
Peter

>
> Thx,
> r.
>
> On Wed, Aug 26, 2015 at 10:43 AM, Peter Psenak <[email-masked]
>     On 8/26/15 09:46 , [email-masked]
>         Yes I need to allocate a new SRGB, but my index space will be
>         contiguous and I will be able to use the index 51 in each scope.
>
>
>     configuration wise same can be achieved with the offsets - think of
>     it as an internal SRGB local to the box. The only difference is what
>     is advertised.
>
>
>     1. per topology SRGB
>
>     4 SRGBs:
>
>     100-149 topology 1
>     150-199 topology 2
>     200-249 topology 1
>     250-299 topology 2
>
>         From: Peter Psenak [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         On 8/26/15 01:28 , [email-masked]
>             As I already pointed to Les, using an offset creates some
>             holes in index space that we need to manage when extending a
>             block.
>
>             Let's say that we have SRGB [100-199] (to simplify) and you
>             divide your block in two so you will have topology #1 using
>             [100-149] and topology #2 using [150-199] using an offset of 50.
>             Now I need to add a 51th node in my network, I cannot use
>             index 51 because it will overlap with topology#2 :(, so I
>             will need to skip indexes from 51 to 100, and restarts my
>             numbering with index 101. This management of holes is not
>             automated.
>
>
>         how is this different to the case where you have two per
>         topology SRGBs of 100-149 and 150-199 and now you need 51st SID?
>         It is exactly the same problem. You need to allocate a new SRGB.
>
>         thanks,
>         Peter
>
>
>             Best Regards,
>
>             Stephane
>
>             From: Peter Psenak [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             On 8/25/15 12:58 , [email-masked]
>                     I will keep repeating myself that such provisioning
>                     can be made automatic, so the above point is not
>                     really convincing to me.
>
>
>             I would assume that when you start to assign your SIDs for
>             the default topology, you would not pick random values, but
>             start from the beginning. So let' assume you are using 16001
>             to 16500 for nodes in default topology.
>
>             Now you need to add a new topology. You configure and offset
>             of 2k for it, so the advertised SIDs for the new topology
>             would start from 18001.
>             If we assume that the 2k would be a reasonable size for each
>             topology you can have 4 topologies with 2k SIDs per topology.
>
>             If for whatever reason you run out of the SID space in any
>             topology, you can configure another offset for those SIDs
>             which do not fit into the existing range for such topology.
>
>             All of the above is internal to the node and no per topology
>             SRGB advertisement is required. You advertise unique SID on
>             a per prefix and per topology basis, but you do not need to
>             configure each SID manually.
>             Al you need to configure is the single prefix SID and per
>             topology offset/size. It gives you the same simplicity for
>             configuration as per topology SRGB, but without the need to
>             advertise SRGB per topology.
>
>             thanks,
>             Peter
>
>
>
>                 Best Regards,
>
>                 Stephane
>
>
>
>                 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;
>                 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.
>
>
>
>
>             diffuses,
>             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 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
>         deforme ou falsifie. Merci.
>
>         privileged information that may be protected by law;
>         If you have received this email in error, please notify the
>         sender and delete this message and its attachments.
>         have been modified, changed or falsified.
>         Thank you.
>
>         .
>
>

---

From: <[email-masked]>
Date: Wed, 26 Aug 2015 10:55:28 +0000

Hi Peter,

There are some mix between SIDs and labels in your text.

Some comments inline

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]]
Sent: Wednesday, August 26, 2015 10:43
To: LITKOWSKI Stephane SCE/IBNF; Eric C Rosen; Pushpasis Sarkar; SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Hi Stephane,

> Yes I need to allocate a new SRGB, but my index space will be contiguous and I will be able to use the index 51 in each scope.

configuration wise same can be achieved with the offsets - think of it as an internal SRGB local to the box. The only difference is what is advertised.

1. per topology SRGB

4 SRGBs:

100-149 topology 1

150-199 topology 2

200-249 topology 1

250-299 topology 2

prefix51, topology 1 - SID index 51 -> SID 200 prefix51, topology 2 - SID index 51 -> SID 250

[SLI] I would more think about : prefix51, topology 1 - SID index 51 -> label 200 ; prefix51, topology 2 - SID index 51 -> label 250

What is advertised:

[SLI] Agree

-----------

2. Per topology offset

SRGB 100-299

0-49 topology 1

50-99 topology 2

100-149 topology 1

150-199 topology 2

prefix51, topology 1 - SID index 51 -> SID 200 prefix51, topology 2 - SID index 51 -> SID 250

[SLI] In this case that's no more an offset, it's more a range of indexes mapped to others.

It's different from Les's proposal " srgb offset topology 1 1000" which is just a simple "ADD" operation.

You are creating some indirection table (like for virtual memory management). It works, but adds some complexity to manage those indirections.

And so there will be two levels of indirection

Virtual index table for topology#1

Real index table

Label  range

[0-49]

[0-49]

[100-149]

[50-99]

[100-149]

[200-249]

Virtual index table for topology#2

Real index table

Label  range

[0-49]

[50-99]

[150-199]

[50-99]

[150-199]

[249-299]

Well, managing one level of indirection is already a boring thing from an operational point of view, adding such complex mapping would not ease it.

When you need to troubleshoot label values (some platforms still have programming issues unfortunately ...), it complexifies ...

What is advertised:

thanks,

Peter

> To: LITKOWSKI Stephane SCE/IBNF; Eric C Rosen; Pushpasis Sarkar;

> SPRING WG

> On 8/26/15 01:28 , [email-masked]<mailto:[email-masked]> wrote:

>> To: LITKOWSKI Stephane SCE/IBNF; Eric C Rosen; Pushpasis Sarkar;

>> SPRING WG

>> On 8/25/15 12:58 , [email-masked]<mailto:[email-masked]> wrote:

>>> ____________________________________________________________________

>>> _ _ ___________________________________________________

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

---

From: Peter Psenak <[email-masked]>
Date: Wed, 26 Aug 2015 13:34:28 +0200

Hi Stephane,

please see inline:

> There are some mix between SIDs and labels in your text.

when I said SID, I meant absolute SID, which in MPLS case becomes a label.

> [SLI] I would more think about : prefix51, topology 1 - SID index 51 ->
> label 200 ; prefix51, topology 2 - SID index 51 -> label 250
>
> What is advertised:
>

it was just one way or representing it, the idea is to split the single 
SRGB internally on the box to allow using single index for 
configuration. There are certainly other ways of doing it.

>
> It's different from Les's proposal " srgb offset topology 1 1000" which
> is just a simple “ADD” operation.

it is the same to what Les proposed, but my example contains multiple 
offsets per single topology.

thanks,
Peter

>
> You are creating some indirection table (like for virtual memory
> management). It works, but adds some complexity to manage those
> indirections.
>
> Well, managing one level of indirection is already a boring thing from
> an operational point of view, adding such complex mapping would not ease it.
>
> When you need to troubleshoot label values (some platforms still have
> programming issues unfortunately …), it complexifies …
>
> What is advertised:
>
>  > how is this different to the case where you have two per topology
> SRGBs of 100-149 and 150-199 and now you need 51st SID? It is exactly
> the same problem. You need to allocate a new SRGB.
>
>  >
>
>  > thanks,
>
>  > Peter
>
>  >
>
>  >>
>
>  >> Best Regards,
>
>  >>
>
>  >> Stephane
>
>  >>
>
> to be so easy.
>  >> I would assume that when you start to assign your SIDs for the
> default topology, you would not pick random values, but start from the
>  >> Now you need to add a new topology. You configure and offset of 2k
> for it, so the advertised SIDs for the new topology would start from 18001.
>
> 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 distributed, used or copied without authorisation.
>
> and delete this message and its attachments.
>
> and delete this message and its attachments.
>
> and delete this message and its attachments.
>

---

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

Pushpasis –

We agree on the terms you use below – and no I was not confusing them.

The context of this “sub-thread” was protocol specific SRGBs. My point is that anycast  (just like unicast) becomes more complex when you have protocol specific SRGBs because you have to account for multiple labels for the same prefix/anycast source since traffic may arrive from a node which learned the route from Protocol A as well as a node that learned the route from Protocol B. In the case of anycast this adds to the issue you already have highlighted in your draft where the presence of different SRGB ranges on nodes the network can complicate anycast delivery.

I am not saying that anycast cannot be supported using protocol specific SRGBs – but if there is a question to be asked regarding “how is this done” it should be asked in the context of protocol specific SRGBs. How this is done using a “global SRGB” is something we already understand – in part due to your draft.

   Les

From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: Tuesday, August 25, 2015 10:31 PM
To: Les Ginsberg (ginsberg); Robert Raszuk
Cc: Peter Psenak (ppsenak); [email-masked]; [email-masked]; Eric Rosen
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Hi Les,

Thanks
-Pushpasis

Robert –

   Les

Les,

Thx,
R.

Peter,

   Les

Thx,
R.

thanks,
Peter

Thx Peter !
R.

        Peter,

    Peter

        Thx,
        R.

             Robert,

                 Peter,

             thanks,
             Peter

                 Best,
                 R.

                      Hi Eric,

                      please see inline:

        that you
                 either need
        single SRGB
                 with per
                 prefix-SID is
                      "global"

                 encodings
                      have

                 even one
                      SRGB per

        what the
                      architecture is
                 of an
                      IGP, then
                 seems like a
                      major
        have an
                 SRGB per
                 have one
                      quantity
        hear some
                 hand-waving
        prefix-SIDs for
                 every new

        one way
                 of setting up
        underlays by
                 using two
                 underlay.  If
                      you set
        instance
                 of OSPF, you
        supposed
                 to be?

        and IGP
                 encoding has
                 where it
                      says that
        and/or that
                 SRGBs are

                 you end up
                      with
        TLVs for
                 the same
        stated
                 above.

        operator
                 (i.e. Single
                 prefer,
                      one of
                 to allow
                      more
        architecture and
                 encoding
        (but do not
                      require) a
        of each
                 routing

        topology
                 of a
        means there
                 are already
                 restrictions
                      that don't
                 implementations out
                      there in

                      thanks,
                      Peter

                 Prefix SID to
                      SRGB,
        used
                 for? Having the
        SRGB would be
                      redundant and
        backwards
                      compatible, but

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Aug 2015 14:15:57 +0000

Stephane -

Implementations based on the drafts that currently exist advertise a topology independent SRGB. A SID which is advertised in a specific MT Prefix Reachability advertisement is interpreted as an index into the topology independent SRGB. This is NOT compatible with an implementation which is written assuming that a SID is an index into a topology specific SRGB. So the introduction of topology specific SRGBs would have to be supported network-wide before it could be deployed. Sub-TLVs cannot resolve this incompatibility.

   Les

> Sent: Wednesday, August 26, 2015 12:25 AM
> To: Pushpasis Sarkar; Les Ginsberg (ginsberg); Uma Chunduri; Peter Psenak
> (ppsenak); Eric Rosen; SPRING WG
> I just want to remember that the discussion is not only for MT, but there was
> also a thread for per algorithm SRGB (as presented in Prague). IMO, there
> must be some consistency in the choice we do.
> Regarding encoding nothing is impossible (as example a new subTLV can be
> created ensuring backward compatibility).
> To: Les Ginsberg (ginsberg); Uma Chunduri; LITKOWSKI Stephane SCE/IBNF;
> Peter Psenak (ppsenak); Eric Rosen; SPRING WG
> >[Les:] Topology specific SRGBs requires a specification change for the IGPs.
> The new advertisements are NOT backwards compatible w existing
> implementations. So we cannot simply say "do what you please".
> >Peter has repeatedly made this point - and also pointed out that since the
> prefix advertisements as currently defined in the IGP drafts includes
> topology identifiers including the topology identifier in the SRGB
> advertisement is redundant.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Aug 2015 14:29:36 +0000

Robert -

Sent: Wednesday, August 26, 2015 12:29 AM

Les,

[Les:] Don’t think so.

I am talking not about anycast to SR devices (what the draft you quote is all about), but periodic anycast across N topologies to the same prefix on the single device.

If I allocate single SID to prefix regardless which protocol/topology advertitses such tuple how do I construct different data plane forwarding in transit nodes assuming flat LFIBs ?
[Les:] In regards to topology, there are two models being discussed:

1)Topology independent SRGB. This is  we have today – and clearly we can do anycast – and we can do it in any topology because we have different SIDs/labels for the same prefix (anycast or not) in each topology.

2)Topology specific SRGB. In this case you would have the same SID for the same prefix (anycast or not) in all topologies – but you would still have topology unique labels. So again anycast can be supported.

Your question seems more directed at #2 – which of course is not what I am advocating. So I think your question is better directed at the topology specific SRGB advocates – though as I said above I think anycasr can be done w either model.

And with that I do not want to readvertise anything in IGP each type my forwarding preference to said prefix across topologies changes.

[Les:] It’s a bit hard to parse the above sentence – not quite sure what you are trying to say.
IGPs necessarily have to advertise what prefixes are reachable in each topology – we do not assume that because a prefix is reachable in topology A that it is also reachable in Topology B.
And since the SID advertisement is associated with the topology specific prefix advertisement, whether I happen to have the same SID for the same prefix across topologies or not I still have to advertise it in each topology.
I would strongly object to a model which required the SID for a prefix in Topology B to be retrieved from the advertisement for the same prefix in Topology A.

   Les

Also as Eric commented already a workaround to bring up new prefix in such case has severe application level consequences, hence - while doable from network point of view - it would rather not be a wise deployment choice.

Best,
r.

On Tue, Aug 25, 2015 at 11:49 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 25, 2015 1:17 PM
To: Les Ginsberg (ginsberg)
Cc: Peter Psenak (ppsenak); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Pushpasis Sarkar ([email-masked]<mailto:[email-masked]>); Eric C Rosen

Les,

Thx,
R.

Peter,

   Les

Thx,
R.

thanks,
Peter

Thx Peter !
R.

        Peter,

    Peter

        Thx,
        R.

             Robert,

                 Peter,

             thanks,
             Peter

                 Best,
                 R.

                      Hi Eric,

                      please see inline:

        that you
                 either need
        single SRGB
                 with per
                 prefix-SID is
                      "global"

                 encodings
                      have

                 even one
                      SRGB per

        what the
                      architecture is
                 of an
                      IGP, then
                 seems like a
                      major
        have an
                 SRGB per
                 have one
                      quantity
        hear some
                 hand-waving
        prefix-SIDs for
                 every new

        one way
                 of setting up
        underlays by
                 using two
                 underlay.  If
                      you set
        instance
                 of OSPF, you
        supposed
                 to be?

        and IGP
                 encoding has
                 where it
                      says that
        and/or that
                 SRGBs are

                 you end up
                      with
        TLVs for
                 the same
        stated
                 above.

        operator
                 (i.e. Single
                 prefer,
                      one of
                 to allow
                      more
        architecture and
                 encoding
        (but do not
                      require) a
        of each
                 routing

        topology
                 of a
        means there
                 are already
                 restrictions
                      that don't
                 implementations out
                      there in

                      thanks,
                      Peter

                 Prefix SID to
                      SRGB,
        used
                 for? Having the
        SRGB would be
                      redundant and
        backwards
                      compatible, but

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 26 Aug 2015 14:30:23 +0000

Hi Les,

From: "Les Ginsberg (ginsberg)"
Date: Wednesday, August 26, 2015 at 7:38 PM
To: Pushpasis Sarkar, Robert Raszuk
Cc: "Peter Psenak (ppsenak)", "[email-masked]<mailto:[email-masked]>", "[email-masked]<mailto:[email-masked]>", Eric Rosen
Subject: RE: [spring] SRGBs, indexes, and topologies within a domain

Pushpasis –

The context of this “sub-thread” was protocol specific SRGBs. My point is that anycast  (just like unicast) becomes more complex when you have protocol specific SRGBs because you have to account for multiple labels for the same prefix/anycast source since traffic may arrive from a node which learned the route from Protocol A as well as a node that learned the route from Protocol B. In the case of anycast this adds to the issue you already have highlighted in your draft where the presence of different SRGB ranges on nodes the network can complicate anycast delivery.
[Pushpasis] My understanding is that we already have discussed and concluded on this (global SRGB versus local significance of labels) in SPRING and MPLS working groups. We dont need to discuss that again. The anycast draft is a result of that decision and a necessary solution. We should not be assuming in any of the future proposals that all nodes has to support the same SRGB (even if its per-protocol/per-topology/per-algorithm SRGB).

   Les

Cc: Peter Psenak (ppsenak); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Eric Rosen

Hi Les,

Thanks
-Pushpasis

Robert –

   Les

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

Les,

Thx,
R.

Peter,

   Les

Thx,
R.

thanks,
Peter

Thx Peter !
R.

        Peter,

    Peter

        Thx,
        R.

             Robert,

                 Peter,

             thanks,
             Peter

                 Best,
                 R.

                      Hi Eric,

                      please see inline:

        that you
                 either need
        single SRGB
                 with per
                 prefix-SID is
                      "global"

                 encodings
                      have

                 even one
                      SRGB per

        what the
                      architecture is
                 of an
                      IGP, then
                 seems like a
                      major
        have an
                 SRGB per
                 have one
                      quantity
        hear some
                 hand-waving
        prefix-SIDs for
                 every new

        one way
                 of setting up
        underlays by
                 using two
                 underlay.  If
                      you set
        instance
                 of OSPF, you
        supposed
                 to be?

        and IGP
                 encoding has
                 where it
                      says that
        and/or that
                 SRGBs are

                 you end up
                      with
        TLVs for
                 the same
        stated
                 above.

        operator
                 (i.e. Single
                 prefer,
                      one of
                 to allow
                      more
        architecture and
                 encoding
        (but do not
                      require) a
        of each
                 routing

        topology
                 of a
        means there
                 are already
                 restrictions
                      that don't
                 implementations out
                      there in

                      thanks,
                      Peter

                 Prefix SID to
                      SRGB,
        used
                 for? Having the
        SRGB would be
                      redundant and
        backwards
                      compatible, but

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Aug 2015 14:34:15 +0000

Pushpasis -

Sent: Wednesday, August 26, 2015 7:30 AM

Hi Les,

Pushpasis –

[Les:] Agreed – and I have not said anything which suggests we have to have the same SRGB range across multiple nodes (topology specific or not). If you think I have said that please point it out and I will clarify.

  Les

   Les

Hi Les,

Thanks
-Pushpasis

Robert –

   Les

Les,

Thx,
R.

Peter,

   Les

Thx,
R.

thanks,
Peter

Thx Peter !
R.

        Peter,

    Peter

        Thx,
        R.

             Robert,

                 Peter,

             thanks,
             Peter

                 Best,
                 R.

                      Hi Eric,

                      please see inline:

        that you
                 either need
        single SRGB
                 with per
                 prefix-SID is
                      "global"

                 encodings
                      have

                 even one
                      SRGB per

        what the
                      architecture is
                 of an
                      IGP, then
                 seems like a
                      major
        have an
                 SRGB per
                 have one
                      quantity
        hear some
                 hand-waving
        prefix-SIDs for
                 every new

        one way
                 of setting up
        underlays by
                 using two
                 underlay.  If
                      you set
        instance
                 of OSPF, you
        supposed
                 to be?

        and IGP
                 encoding has
                 where it
                      says that
        and/or that
                 SRGBs are

                 you end up
                      with
        TLVs for
                 the same
        stated
                 above.

        operator
                 (i.e. Single
                 prefer,
                      one of
                 to allow
                      more
        architecture and
                 encoding
        (but do not
                      require) a
        of each
                 routing

        topology
                 of a
        means there
                 are already
                 restrictions
                      that don't
                 implementations out
                      there in

                      thanks,
                      Peter

                 Prefix SID to
                      SRGB,
        used
                 for? Having the
        SRGB would be
                      redundant and
        backwards
                      compatible, but

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 26 Aug 2015 14:44:13 +0000

Hi Les,

>Implementations based on the drafts that currently exist advertise a topology independent SRGB. A SID which is advertised in a specific MT Prefix Reachability advertisement is interpreted as an inde…
[Pushpasis] What if we use the current SR-capability sub-TLVs only for single topology deployments? And use a new MT-SR-Capability SubTLV for MT deployments? Please note, I am not saying MT cannot be supported with current SR-Cap SubTLV. It can be, but with the limitation (as I like to see this cuurently) is that we MUST use separate SID-index for the same prefix in separate topologies. If operator does not want to live with the limitation then all the vendor implementations must implement the new MT-SR-Cap SubTLV and make it happen. If the operator can live with the implementation they continue with per-topology SID-index and single SRGB for all topology.

Thanks
-Pushpasis

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 26 Aug 2015 14:49:00 +0000

Hi Les,

Date: Wednesday, August 26, 2015 at 8:04 PM

Pushpasis -

Hi Les,

Pushpasis –

[Pushpasis] The following text from your mail earlier gave me the impression that you are still trying to advocate same SRGB across all nodes…

"IF there is a consistent SRGB – not only among multiple protocols on a given node – but also among all the nodes in the network – then anycast is easy.”

And..

"My point is that anycast  (just like unicast) becomes more complex when you have protocol specific SRGBs because you have to account for multiple labels for the same prefix/anycast source since traffic may arrive from a node which learned the route from Protocol A as well as a node that learned the route from Protocol B. In the case of anycast this adds to the issue..”

Forgive me if I have misunderstood you :)

Thanks
-Pushpasis

  Les

   Les

Hi Les,

Thanks
-Pushpasis

Robert –

   Les

Les,

Thx,
R.

Peter,

   Les

Thx,
R.

thanks,
Peter

Thx Peter !
R.

        Peter,

    Peter

        Thx,
        R.

             Robert,

                 Peter,

             thanks,
             Peter

                 Best,
                 R.

                      Hi Eric,

                      please see inline:

        that you
                 either need
        single SRGB
                 with per
                 prefix-SID is
                      "global"

                 encodings
                      have

                 even one
                      SRGB per

        what the
                      architecture is
                 of an
                      IGP, then
                 seems like a
                      major
        have an
                 SRGB per
                 have one
                      quantity
        hear some
                 hand-waving
        prefix-SIDs for
                 every new

        one way
                 of setting up
        underlays by
                 using two
                 underlay.  If
                      you set
        instance
                 of OSPF, you
        supposed
                 to be?

        and IGP
                 encoding has
                 where it
                      says that
        and/or that
                 SRGBs are

                 you end up
                      with
        TLVs for
                 the same
        stated
                 above.

        operator
                 (i.e. Single
                 prefer,
                      one of
                 to allow
                      more
        architecture and
                 encoding
        (but do not
                      require) a
        of each
                 routing

        topology
                 of a
        means there
                 are already
                 restrictions
                      that don't
                 implementations out
                      there in

                      thanks,
                      Peter

                 Prefix SID to
                      SRGB,
        used
                 for? Having the
        SRGB would be
                      redundant and
        backwards
                      compatible, but

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Aug 2015 15:07:45 +0000

Pushpasis -

Sent: Wednesday, August 26, 2015 7:49 AM

Hi Les,

Pushpasis -

Hi Les,

Pushpasis –

[Les:]I was just pointing out that consistent SRGBs makes anycast easier. I was reacting to Robert’s question – which seemed to imply that having a topology independent SRGB makes anycast difficult. Probably the example was not the best choice – apologies for any confusion.

And..

[Les:] Again, not saying we MUST have consistent SRGBs across nodes – though there is no denying life is simpler if you can do that. I hope the fact that we support different SRGB ranges/node does not then imply that we MUST have different SRGB ranges/node.

[Les:] We are good – always better to make sure we understand each other. At least then we know on what we agree on and on what we disagree. ☺

   Les

Thanks
-Pushpasis

  Les

   Les

Hi Les,

Thanks
-Pushpasis

Robert –

   Les

Les,

Thx,
R.

Peter,

   Les

Thx,
R.

thanks,
Peter

Thx Peter !
R.

        Peter,

    Peter

        Thx,
        R.

             Robert,

                 Peter,

             thanks,
             Peter

                 Best,
                 R.

                      Hi Eric,

                      please see inline:

        that you
                 either need
        single SRGB
                 with per
                 prefix-SID is
                      "global"

                 encodings
                      have

                 even one
                      SRGB per

        what the
                      architecture is
                 of an
                      IGP, then
                 seems like a
                      major
        have an
                 SRGB per
                 have one
                      quantity
        hear some
                 hand-waving
        prefix-SIDs for
                 every new

        one way
                 of setting up
        underlays by
                 using two
                 underlay.  If
                      you set
        instance
                 of OSPF, you
        supposed
                 to be?

        and IGP
                 encoding has
                 where it
                      says that
        and/or that
                 SRGBs are

                 you end up
                      with
        TLVs for
                 the same
        stated
                 above.

        operator
                 (i.e. Single
                 prefer,
                      one of
                 to allow
                      more
        architecture and
                 encoding
        (but do not
                      require) a
        of each
                 routing

        topology
                 of a
        means there
                 are already
                 restrictions
                      that don't
                 implementations out
                      there in

                      thanks,
                      Peter

                 Prefix SID to
                      SRGB,
        used
                 for? Having the
        SRGB would be
                      redundant and
        backwards
                      compatible, but

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Aug 2015 15:19:02 +0000

Pushpasis -

> Sent: Wednesday, August 26, 2015 7:44 AM
> To: Les Ginsberg (ginsberg); [email-masked]; Uma
> Chunduri; Peter Psenak (ppsenak); Eric Rosen; SPRING WG
> >Implementations based on the drafts that currently exist advertise a
> topology independent SRGB. A SID which is advertised in a specific MT Prefix
> Reachability advertisement is interpreted as an index into the topology
> independent SRGB. This is NOT compatible with an implementation which is
> written assuming that a SID is an index into a topology specific SRGB. So the
> introduction of topology specific SRGBs would have to be supported
> network-wide before it could be deployed. Sub-TLVs cannot resolve this
> incompatibility.
> [Pushpasis] What if we use the current SR-capability sub-TLVs only for single
> topology deployments? And use a new MT-SR-Capability SubTLV for MT
> deployments? Please note, I am not saying MT cannot be supported with
> current SR-Cap SubTLV. It can be, but with the limitation (as I like to see this
> cuurently) is that we MUST use separate SID-index for the same prefix in
> separate topologies. If operator does not want to live with the limitation
> then all the vendor implementations must implement the new MT-SR-Cap
> SubTLV and make it happen. If the operator can live with the implementation
> they continue with per-topology SID-index and single SRGB for all topology.

[Les:] What you propose does not alter the fact that unless all implementations agree that SIDs in MT prefix advertisements have to be applied against a topology specific SRGB we will have interoperability problems. So the specs have to be revised and the implementations have to be revised to match.
Existing code will not interoperate.

   Les

> >> To: Pushpasis Sarkar; Les Ginsberg (ginsberg); Uma Chunduri; Peter
> >> Psenak (ppsenak); Eric Rosen; SPRING WG
> >> I just want to remember that the discussion is not only for MT, but
> >> there was also a thread for per algorithm SRGB (as presented in
> >> Prague). IMO, there must be some consistency in the choice we do.
> >> Regarding encoding nothing is impossible (as example a new subTLV can
> >> be created ensuring backward compatibility).
> >> To: Les Ginsberg (ginsberg); Uma Chunduri; LITKOWSKI Stephane
> >> SCE/IBNF; Peter Psenak (ppsenak); Eric Rosen; SPRING WG

---

From: <[email-masked]>
Date: Wed, 26 Aug 2015 15:31:17 +0000

Hi Les,

IMO, backward compatibility mean that we are compatible with the old flavor functionality.
Let's assume that we create a new subTLV that will override the current SR capability subTLV (just as example). The new subTLV will contain encoding for per algo, per topo SRGB. I think we can define compatibility rules :
We have the simple network A - B - C - D, with two topologies #1 and #2 and SRGB [100,200], A uses index 1 (topo#1), index 2 (topo#2), B uses index 3 (topo#1) and 4 (topo#2) ...

- for sure during the migration period, we cannot use a different SRGB per topo, we need to keep backward compatibility with same level of functions, so common SRGB between topologies.
- We activate the support of the new subTLV on B, without changing SRGB, B advertise the same SRGB for the two topologies in the new subTLV and keep advertising the SRGB in legacy subTLV. Node B receives legacy SR-cap from A and C and understand it well, it considers the index 1 as part of SRGB in legacy subTLV and computes the appropriate value. To reach index 7 on D (topo#1), it programs the label computed with index 7 + SRGB advertised by C in legacy subTLV. Now, what about A, A receives advertisement from B, it does not understand the newsubTLV, A computes path to B using index 3 (topo#1) and SRGB from B in legacy subTLV. As B moved to newsubTLV, it allocates labels per topology based on the per topology SRGB and while we advertise the legacy subTLV, it ensures that a label is programmed using the ex global SRGB. In this case, as migration is not done, B has allocated a unique label for topo#1 index 3 using the ex global SRGB (per topology label is the same). Same process for A computing a path to C, A uses index 6 (topo#2) and uses the legacy subTLV advertisement from B. B has programmed a forwarding plane entry for the legacy label.
- Now we activate the support on C, B to reach D knows that C supports the new subTLV and use it in priority. As all nodes still advertise the global SRGB (let's call it legacySRGB) in the the newsubTLV, forwarding plane is not changed.
- Now we decide on C to start changing SRGB to per topology SRGB. As there is some legacy traffic, C still need to keep the legacy subTLV and legacy SRGB. C associate SRGB_C1 to topo#1 and SRGB_C2 to topo#2. These new advertisement are part of the new subTLV. Let's assume traffic from A to D. A sends traffic using label#1=legacySRGB_start_on_B+index 7 to B for topo#1 traffic and using label#2=legacySRGB_start_on_B+index 8 to B for topo#2. B programs the forwarding entry taking into account that the C supports per topo SRGB : label#1 swapped to SRGB#1+7, label#2 swapped to SRGB#1+8. C programs the new forwarding entries (from labels in SRGB#1 and #2) pointing to a label value computed using legacySRGB_start_on_D+index 7 or 8.

Now if we need to renumber indexes to use the same index value, we need to wait for all nodes to support the new extension, as using the same index is a new feature. 

So IMO, backward compatibility is feasible. I think changing SRGBs per topology is feasible in an incremental way. Using the same index requires a full network deployment (not incrementally deployable) but it's normal as the current behavior does not support it.

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Wednesday, August 26, 2015 16:16
To: LITKOWSKI Stephane SCE/IBNF; Pushpasis Sarkar; Uma Chunduri; Peter Psenak (ppsenak); Eric Rosen; SPRING WG
Subject: RE: [spring] SRGBs, indexes, and topologies within a domain

Stephane -

   Les

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 26 Aug 2015 15:31:43 +0000

Hi Les,

>Existing code will not interoperate.
[Pushpasis] My understanding is that in such partial deployment of this proposal it will still work if operator still used distinct indexes per-topology. However to use the same index for the same prefix across all the topologies all the nodes in the network needs to be upgraded to the new proposal.

It will be better if we introduce this right away. Further delay will only result in complicating things in future.

Thanks
-Pushpasis

---

From: Peter Psenak <[email-masked]>
Date: Wed, 26 Aug 2015 17:39:34 +0200

Hi Pushpasis,

> [Pushpasis] What if we use the current SR-capability sub-TLVs only for single topology deployments? And use a new MT-SR-Capability SubTLV for MT deployments? Please note, I am not saying MT cannot…

above would require vendors to implement both options. For operators 
managing transitions between one option to the other would be difficult. 
Interoperability with the implementations that only support one option 
would become problematic.

Do we really want to create all this? Does the gain we would get with 
per topo/algo SRGB justify all this, especially given that the gain is 
not functional, but rather operational and fairly limited?

thanks,
Peter

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 26 Aug 2015 15:43:02 +0000

Hi Peter,

>not functional, but rather operational and fairly limited?
[Pushpasis] Forgive my pestering again, but I think its needed to solve the operational inconvenience. 

Thanks
-Pushpasis

---

From: <[email-masked]>
Date: Wed, 26 Aug 2015 16:17:52 +0000

Hi,

Just to know, is there some implementation today supporting MT for SPRING ? The other point is : if yes, does someone use it in a live network ? If no, there is no issue to change.
I agree that a migration is not easy, but coming back to previous sentence, honestly I think no one use MT SPRING today ... so no migration expected.

For algorithm, AFAIK, no one support multiple algorithm today, so we can do what we want as far as it does not break algo#0 today.

Stephane

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Wednesday, August 26, 2015 17:40
To: Pushpasis Sarkar; Les Ginsberg (ginsberg); LITKOWSKI Stephane SCE/IBNF; Uma Chunduri; Eric Rosen; SPRING WG
Subject: Re: [spring] SRGBs, indexes, and topologies within a domain

Hi Pushpasis,

> [Pushpasis] What if we use the current SR-capability sub-TLVs only for single topology deployments? And use a new MT-SR-Capability SubTLV for MT deployments? Please note, I am not saying MT cannot…

above would require vendors to implement both options. For operators managing transitions between one option to the other would be difficult. 
Interoperability with the implementations that only support one option would become problematic.

Do we really want to create all this? Does the gain we would get with per topo/algo SRGB justify all this, especially given that the gain is not functional, but rather operational and fairly limited?

thanks,
Peter

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 26 Aug 2015 17:07:44 +0000

Stephane -

For IS-IS there is at least MT support for IPv6 and multicast.

But, I really think we are getting ahead of ourselves.

There is no consensus yet - there are simply advocates for two different positions.
Trying to talk about the mechanics of migration is premature. For now  it is sufficient for all parties to understand that existing code is not compatible w a per topology SRGB and changes will have to be made if that choice is made.

I would appreciate it if folks did not declare consensus until we have achieved it. :-)

   Les

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, August 26, 2015 9:18 AM
> To: Peter Psenak (ppsenak); Pushpasis Sarkar; Les Ginsberg (ginsberg); Uma
> Chunduri; Eric Rosen; SPRING WG
> Just to know, is there some implementation today supporting MT for SPRING
> ? The other point is : if yes, does someone use it in a live network ? If no,
> there is no issue to change.
> I agree that a migration is not easy, but coming back to previous sentence,
> honestly I think no one use MT SPRING today ... so no migration expected.
> 
> For algorithm, AFAIK, no one support multiple algorithm today, so we can do
> what we want as far as it does not break algo#0 today.
> 
> Stephane
> 
> 
> To: Pushpasis Sarkar; Les Ginsberg (ginsberg); LITKOWSKI Stephane
> SCE/IBNF; Uma Chunduri; Eric Rosen; SPRING WG
> > [Pushpasis] What if we use the current SR-capability sub-TLVs only for
> single topology deployments? And use a new MT-SR-Capability SubTLV for
> MT deployments? Please note, I am not saying MT cannot be supported with
> Do we really want to create all this? Does the gain we would get with per
> topo/algo SRGB justify all this, especially given that the gain is not functional,
> but rather operational and fairly limited?
> 
> thanks,
> Peter
> 
> >
> > Thanks
> > -Pushpasis
> 
>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 27 Aug 2015 09:16:53 +0200

Hi Stephane,

> I agree that a migration is not easy, but coming back to previous sentence, honestly I think no one use MT SPRING today ... so no migration expected.

the fact that there are no existing MT/algo deployments of SR using the 
existing encoding does not mean there will never be ones in the future. 
Unless you remove those fields in the existing encoding anyone can use 
them to deploy MT/algo with SR, you can not prevent that.

My point is that having two mechanisms to do the same thing is bad idea 
to start with, because of the reasons I mentioned earlier.

thanks,
Peter

---

From: <[email-masked]>
Date: Thu, 27 Aug 2015 07:17:05 +0000

Hi Les,

I completely agree that consensus is not achieved yet, no worry. The only consensus we have is on per IGP instance SRGB support.
But as the discussion moved to encoding issue, I just wanted to highlight that it may not be an issue.
Anyway, yes, we need to find a consensus.

Best Regards,

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Wednesday, August 26, 2015 19:08
To: LITKOWSKI Stephane SCE/IBNF; Peter Psenak (ppsenak); Pushpasis Sarkar; Uma Chunduri; Eric Rosen; SPRING WG
Subject: RE: [spring] SRGBs, indexes, and topologies within a domain

Stephane -

   Les

> To: Peter Psenak (ppsenak); Pushpasis Sarkar; Les Ginsberg (ginsberg); 
> Uma Chunduri; Eric Rosen; SPRING WG
> Just to know, is there some implementation today supporting MT for 
> SPRING ? The other point is : if yes, does someone use it in a live 
> network ? If no, there is no issue to change.
> I agree that a migration is not easy, but coming back to previous 
> sentence, honestly I think no one use MT SPRING today ... so no migration expected.
> 
> For algorithm, AFAIK, no one support multiple algorithm today, so we 
> can do what we want as far as it does not break algo#0 today.
> 
> Stephane
> 
> 
> topology independent SRGB. A SID which is advertised in a specific MT 
> Prefix Reachability advertisement is interpreted as an index into the 
> topology independent SRGB. This is NOT compatible with an 
> implementation which is written assuming that a SID is an index into a 
> topology specific SRGB. So the introduction of topology specific SRGBs 
> would have to be supported network-wide before it could be deployed. 
> Sub-TLVs cannot resolve this incompatibility.
> MT deployments? Please note, I am not saying MT cannot be supported 
> with current SR-Cap SubTLV. It can be, but with the limitation (as I 
> like to see this
> cuurently) is that we MUST use separate SID-index for the same prefix 
> in separate topologies. If operator does not want to live with the 
> limitation then all the vendor implementations must implement the new 
> MT-SR-Cap SubTLV and make it happen. If the operator can live with the 
> implementation they continue with per-topology SID-index and single SRGB for all topology.
>