Subject: [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

From: Imtiyaz Mohammad <[email-masked]>
Date: Thu, 1 Oct 2015 12:44:02 +0530

Hello experts !

The draft-ietf-isis-segment-routing-extensions draft states that:

 "The 'Prefix SID' MUST
   be unique within a given IGP domain (when the L-flag is not set)."

Makes sense from usage point of view. What if some implementation does
not enforce a configuration time check and allows such possibilities
in the network wherein the following three situations arise:

(1) Same SID is received from one device and mapped to multiple prefixes.

(2) Same SID is received from two devices and mapped to multiple prefixes.

(3) Same prefix is mapped with two different SID on two different devices.

Let me go through each case with examples.

(1) Same SID is received from one device and mapped to multiple prefixes.

devA-----ISIS------devB

devB has:

     node segment 100 for 30.30.30.30/32

     node segment 100 for 40.40.40.40/32

It sends prefix segment subTLV for both these entries.

devA receives these subTLVs and since they have arrived from the very
same device, the LFIB entries would be same calculated through
30.30.30.30/32:100 or 40.40.40.40/32:100 because your next operation
and nexthops would be identical.

(2) Same SID is received from two devices and mapped to multiple prefixes.

devA-----ISIS---cost10---devB

          |

          |_____cost20___devC

devB has:

     node segment 100 for 30.30.30.30/32

devC has:

     node segment 100 for 40.40.40.40/32

This cause would clearly not work as devA would need to know SID 100
represents devB or devC. So, on receipt on such subTLV entries, we
would syslog an error.

(3) Same prefix is mapped with two different SID on two different devices.

devA-----ISIS---cost10---devB

          |

          |_____cost20___devC

devB has:

     node segment 100 for 30.30.30.30/32

devC has:

     node segment 200 for 30.30.30.30/32

Even in this case, things would fall apart as the 30.30.30.30/32 fec
has two paths, one of them may be the best path or there might be an
ecmp but one would not know when using incoming label 100 or 200 that
the packet would go to devB or devC.

Is my understanding correct for these three scenarios ?

I am thinking that in scenario (2) and (3), on receipt of duplicate
subTLV entries ( same SID different prefixes or vice versa from
different systemIDs ), we should store all of them, mark one of them
as 'active' based on same criteria such highest systemID and use that
for LFIB generation. The inactive subTLV entry would just lie there in
case the active one ceases to exist for some reason later in time at
which point, the inactive one could be made active and used for LFIB
generation.

Comments / Opinions ?

-- 
Imtiyaz

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 1 Oct 2015 10:54:04 +0000

Hi imtiyaz,

Thanks for bringing this to the working groups attention. Please find some comments inline.

Thanks
-Pushpasis

From: Isis-wg on behalf of Imtiyaz Mohammad
Date: Thursday, October 1, 2015 at 12:44 PM
To: Isis-wg, "[email-masked]<mailto:[email-masked]>"
Subject: [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

Hello experts !

 "The 'Prefix SID' MUST

[Pushpasis] To me it means no two router in the same IGP domain should/can originate the same Prefix Sid index. However it does not mean that two or more prefixes originated by the same node cannot share the same prefix sid index as long as another node is not originating any prefix with the same index.

Makes sense from usage point of view. What if some implementation does not enforce a configuration time check and allows such possibilities in the network wherein the following three situations arise:

devA-----ISIS------devB

devB has:

     node segment 100 for 30.30.30.30/32<http://30.30.30.30/32>

     node segment 100 for 40.40.40.40/32<http://40.40.40.40/32>

devA receives these subTLVs and since they have arrived from the very same device, the LFIB entries would be same calculated through 30.30.30.30/32:100<http://30.30.30.30/32:100> or 40.40.40.40/32:100<http://0.40.40.40/32:100> because your next operation and nexthops would be identical.

[Pushpasis] Totally agree. For example if there are multiple loopback addresses on a single node, a single unique node sid index can be attached to all the loopback addresses. There can be cases that the operator may need to attach separate prefix-sid-indexes with all the loopback address, and I don’t say it is possible, but the same cannot be mandatory as well. So receivers receiving multiple prefixes with the same sid index from the same node should accept it and program one route for each of the prefixes with all of them using the same next hop label.

          |

          |_____cost20___devC

devB has:

     node segment 100 for 30.30.30.30/32<http://30.30.30.30/32>

devC has:

     node segment 100 for 40.40.40.40/32<http://40.40.40.40/32>

This cause would clearly not work as devA would need to know SID 100 represents devB or devC. So, on receipt on such subTLV entries, we would syslog an error.

[Pushpasis] Totally agree.

          |

          |_____cost20___devC

devB has:

     node segment 100 for 30.30.30.30/32<http://30.30.30.30/32>

devC has:

     node segment 200 for 30.30.30.30/32<http://30.30.30.30/32>

Even in this case, things would fall apart as the 30.30.30.30/32<http://30.30.30.30/32> fec has two paths, one of them may be the best path or there might be an ecmp but one would not know when using incoming label 100 or 200 that the packet would go to devB or devC.

[Pushpasis] Agree.

I am thinking that in scenario (2) and (3), on receipt of duplicate subTLV entries ( same SID different prefixes or vice versa from different systemIDs ), we should store all of them, mark one of them as 'active' based on same criteria such highest systemID and use that for LFIB generation. The inactive subTLV entry would just lie there in case the active one ceases to exist for some reason later in time at which point, the inactive one could be made active and used for LFIB generation.

Comments / Opinions ?

--
Imtiyaz

---

From: Imtiyaz Mohammad <[email-masked]>
Date: Thu, 1 Oct 2015 19:18:29 +0530

Thanks Pushpasis ! That helps.

On Thu, Oct 1, 2015 at 4:24 PM, Pushpasis Sarkar <[email-masked]>
wrote:

> To: Isis-wg, "[email-masked]"
> *[Pushpasis] To me it means no two router in the same IGP domain
> should/can originate the same Prefix Sid index. However it does not mean
> that two or more prefixes originated by the same node cannot share the same
> prefix sid index as long as another node is not originating any prefix with
> the same index.*
>
>
> devA receives these subTLVs and since they have arrived from the very same device, the LFIB entries would be same calculated through 30.30.30.30/32:100 or 40.40.40.40/32:100 because your next operation and nexthops would be identical.
>
>
> *[Pushpasis] Totally agree. For example if there are multiple loopback addresses on a single node, a single unique node sid index can be attached to all the loopback addresses. There can be cases that the operator may need to attach separate prefix-sid-indexes with all the loopback address, and I don’t say it is possible, but the same cannot be mandatory as well. So receivers receiving multiple prefixes with the same sid index from the same node should accept it and program one route for each of the prefixes with all of them using the same next hop label.*
>
>
> *[Pushpasis] Totally agree.*
>
>
> Even in this case, things would fall apart as the 30.30.30.30/32 fec has two paths, one of them may be the best path or there might be an ecmp but one would not know when using incoming label 100 or 200 that the packet would go to devB or devC.
>
> *[Pushpasis] Agree.*
>
>

-- 
Mohammad Imtiyaz
Software Engineer
Arista Networks
Bangalore
+91 9901101171

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 6 Oct 2015 15:25:13 +0000

We have not heard back from any of the SR authors though :)

Hi Authors of draft-ietf-isis-segment-routing-extension,

Can one of you please confirm/comment on this?

Thanks and Regards,
-Pushpasis

From: Imtiyaz Mohammad
Date: Thursday, October 1, 2015 at 7:18 PM
To: Pushpasis Sarkar
Cc: Isis-wg, "[email-masked]<mailto:[email-masked]>"
Subject: Re: [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

On Thu, Oct 1, 2015 at 4:24 PM, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>> wrote:
Hi imtiyaz,

Thanks
-Pushpasis

Hello experts !

 "The 'Prefix SID' MUST

devA-----ISIS------devB

devB has:

          |

          |_____cost20___devC

devB has:

devC has:

          |

          |_____cost20___devC

devB has:

devC has:

[Pushpasis] Agree.

Comments / Opinions ?

--
Imtiyaz

--
Mohammad Imtiyaz
Software Engineer
Arista Networks
Bangalore
+91 9901101171

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 6 Oct 2015 16:52:50 +0000

Hi,

sorry, I’m a bit late on my mail queue…

In fact your use case can be addressed by using the Node-SID of the prefix originator.

Rather than allowing same sid for different prefixes (which may easy come to misbehaviors), I’d prefer to set the following rule:
. for all prefixes originated by the same node, the node-sid of the originator may be used.

Of course, it implies the ingress is capable of understanding who originated the prefix (even in case of multi-level/area).

In isis we have draft-ietf-isis-prefix-attributes that define a new prefix sub-tlv with the originator info (among other things) that is preserved across levels, so you have all the info you need.

The advantage of this rule, compared to advertising the same sid of multiple prefixes, is also that you can still advertise a prefix-sid (e.g.: a local sid) with the prefix.

If I take your example, you can still advertise:
	local sid 123 for 30.30.30.30/32
	local sid 321 for 40.40.40.40/32

and therefore (for destination 30.30.30.30) you can use segment list:
	node-sid(devB)
	123

as well as you can use simply node-sid(devB) and do an ip lookup in devB.

s.

> On Oct 6, 2015, at 5:25 PM, Pushpasis Sarkar <[email-masked]> wrote:
> 
> Cc: Isis-wg, "[email-masked]"
> On Thu, Oct 1, 2015 at 4:24 PM, Pushpasis Sarkar <[email-masked]> wrote:
>> Hi imtiyaz,
>>

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 6 Oct 2015 17:48:25 +0000

Hi Stefano,

Thanks for your response. Please find few comments inline.

On 10/6/15, 10:22 PM, "Stefano Previdi (sprevidi)" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

In fact your use case can be addressed by using the Node-SID of the prefix originator.
[Pushpasis] Actually that’s exactly what case 1) in Imtiyaz’s mail says..

Rather than allowing same sid for different prefixes (which may easy come to misbehaviors), I’d prefer to set the following rule:
. for all prefixes originated by the same node, the node-sid of the originator may be used.
[Pushpasis] But that does not mean that traffic for all the prefixes originated by the originator MUST be tunneled. The solution should be flexible to provide all options.
1. Use a single tunnel to carry traffic for all prefixes originated by a node.
2. Use separate tunnels to carry traffic for two or more prefixes originated by a node.
3. Use separate tunnels to carry traffic for each selected prefix-sets(groups of prefixes) originated by a node.

2 and 3 are useful if we the operator is interested in traffic statistics for each separate traffic flows destined to the node. The SR architecture should enable both.. In summary it should allow both 1:1 as well as N:1 correspondence between Prefix and Prefix-SID-indexes.

If I take your example, you can still advertise:
local sid 123 for 30.30.30.30/32
local sid 321 for 40.40.40.40/32
[Pushpasis] If 30.30.30.30/32 and 40.40.40.40/32 are both originated from one single node, and there is no need to separately account traffic for each of these there is no need to allocate two different labels for reaching the same node. Then why waste labels?? If we can conserve labels it should help us implement support SR on platforms with limited LFIB size as well..

Hence scenario 1) should be possible… And so any implementation receiving  multiple prefix with same SID-index should NOT reject them as long as all the prefixes are originated from a single node.

Thanks and Regards,
-Pushpasis

s.

On Oct 6, 2015, at 5:25 PM, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 6 Oct 2015 19:12:43 +0000

On Oct 6, 2015, at 7:48 PM, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>> wrote:

Hi Stefano,

Hi,

Rather than allowing same sid for different prefixes (which may easy come to misbehaviors), I’d prefer to set the following rule:
. for all prefixes originated by the same node, the node-sid of the originator may be used.
[Pushpasis] But that does not mean that traffic for all the prefixes originated by the originator MUST be tunneled.

of course not. that’s why I did put a “may”.

The solution should be flexible to provide all options.
1. Use a single tunnel to carry traffic for all prefixes originated by a node.
2. Use separate tunnels to carry traffic for two or more prefixes originated by a node.
3. Use separate tunnels to carry traffic for each selected prefix-sets(groups of prefixes) originated by a node.

that is fine and my rule still apply. After all, there’s nothing that prevlude a node from having multiple sid’s.

So, the rule would be slightly different:
. for all prefixes originated by the same node, node-sid's of the originator may be used.

this would address your 3 points above.

2 and 3 are useful if we the operator is interested in traffic statistics for each separate traffic flows destined to the node. The SR architecture should enable both..

the architecture already allows this.

In summary it should allow both 1:1 as well as N:1 correspondence between Prefix and Prefix-SID-indexes.

agreed, and it’s already the case.

If I take your example, you can still advertise:
local sid 123 for 30.30.30.30/32
local sid 321 for 40.40.40.40/32
[Pushpasis] If 30.30.30.30/32 and 40.40.40.40/32 are both originated from one single node, and there is no need to separately account traffic for each of these there is no need to allocate two different labels for reaching the same node.

but if there _is_ the need to use a label in order to switch the packet towards the outgoing interface (to 30 or 40), then you understand the use case, right ?

It’s a different use case than the one reported in the original email.

The use case reported in the original email is only one sub-case.

Then why waste labels?? If we can conserve labels it should help us implement support SR on platforms with limited LFIB size as well..

there are a variety of use cases. Some of which do not necessitate to have sr end-to-end (i.e.: you do an ip lookup on the originator) and there are use cases where you want to leverage sr end to end.

Both types of use case (co)exist and we MUST NOT assume there’s only one type.

this is only one use case and you do not address others.

What I look into an architecture, is the ability to address multiple use cases with the same mechanism rather than defining ad-hoc solutions that, at the end, would make the architecture more complex.

I don’t like the idea to blindly allow same sid for multiple prefixes knowing that there’s a much simpler solution: resolution to the node-sid of the originator.

s.

Thanks and Regards,
-Pushpasis

s.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 7 Oct 2015 13:20:48 +0200

Hi Pushpasis
​,

*[Pushpasis] No. I seem to be repeating myself. But your suggestion of
recursing will result in tunnelling traffic destined for all prefixes
originated (not only loopback addresses) though MPLS. Operator may not
like/want this. So associating the sid-index with the loopback address
with a specific address provides flexibility in picking which prefixes
should be tunneled and which ones need not.*
​I do not quite agree with your above statement. Clearly you are thinking
in terms how traditional MPLS router with perhaps specific implementation
resolves paths and building forwarding tables in MPLS domain.

Let's observe that Segment Routing imposition may but not necessarily must
use the same imposition algorithm/mechanism.

​I can easily see a case at ingress where only carefully selected by
operator subset of prefixes originated by exit X will be MPLS segment
routed in the given domain. Rest may be native switched or IP
tunneled/encapsulated.

As examples that can be accomplished by controller driven ingress map or
use multiple next hops (the case where you propagate by BGP).

Cheers,
R.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 7 Oct 2015 09:29:50 +0000

Hi Stefano,

From: "Stefano Previdi (sprevidi)"
Date: Wednesday, October 7, 2015 at 12:42 AM
To: Pushpasis Sarkar
Cc: Imtiyaz Mohammad, Stephane Litkowski, "Clarence Filsfils (cfilsfil)", Hannes Gredler, "Ahmed Bashandy (bashandy)", "[email-masked]<mailto:[email-masked]>", Jeff Tantsura, Isis-wg, "[email-masked]<mailto:[email-masked]>"
Subject: Re: [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

Hi Stefano,

Hi,

that is fine and my rule still apply. After all, there’s nothing that prevlude a node from having multiple sid’s.
[Pushpasis] By sids do you mean node-sids or non-node prefix sids… If the later I agree… But why do you need multiple node-sids for? You can associate the same node-sid for all prefixes originated from the router (e.g. All loopback addresses).. I am not saying that different setting different node-sids should not be used for different prefixes originated, but that cannot be mandatory as well…

this would address your 3 points above.
[Pushpasis] Yes it would..  But again there should not be a mandatory requirement to set different node-sids for each loopback address originated from a given node. A single node-sid configured on the node can be associated with all the loopback addresses originated from the same node.

It’s a different use case than the one reported in the original email.
[Pushpasis] The use case in the original mail is also valid.

there are a variety of use cases. Some of which do not necessitate to have sr end-to-end (i.e.: you do an ip lookup on the originator) and there are use cases where you want to leverage sr end to end.
[Pushpasis] I assume you are referring to a prefix sid for a prefix attached to a local interface. If so, you mean the originator will not need to do a IP lookup? Lets take an address 100.100.100.100/24 attached to a local interface and associate a prefix sid 100 (say). So the node will advertise the prefix 100.100.100.0/24 with SID 10. And this will cause the ingress node to install a route like below..

100.100.100.0/24 -> PUSH NodeSegmentLabel(SID=100)

Now say two packet arrives at ingress for 100.100.100.100 and 100.100.100.90 respectively. Both packets will now be sent to the node using the same label. When the packet arrives (minus the MPLS header, assuming No-PHP) the first packet needs to go to the host stack and the second needs to be forwarded over the interface. I don’t understand how the router can differentiate between the two packets without doing a IP-lookup. Perhaps you can help me understand that..

this is only one use case and you do not address others.
[Pushpasis] I don’t know what use case is not addressed here? The way I see is that the use case Imtiyaz brought up is also not addressed if the above restriction (i.e. Same node-sid cannot be associated with multiple addresses originated from the same node) is imposed by any implementation. Do you agree?

What I look into an architecture, is the ability to address multiple use cases with the same mechanism rather than defining ad-hoc solutions that, at the end, would make the architecture more complex.
[Pushpasis] Once again I don’t understand how is this more complex.

I don’t like the idea to blindly allow same sid for multiple prefixes knowing that there’s a much simpler solution: resolution to the node-sid of the originator.
[Pushpasis] I don’t like the idea either that the same SID cannot be associated with more than one prefix originated from the same node. You are again asking traffic destined for all prefixes originated by the node to be tunneled in a MPLS tunnel. This MUST not be mandatory. Operator may want to tunnel traffic for few traffic flows and for others he /she may want the packets to follow hop-by-hop IP forwarding.

Thanks
-Pushpasis

s.

Thanks and Regards,
-Pushpasis

s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 7 Oct 2015 10:31:53 +0000

On Oct 7, 2015, at 11:29 AM, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>> wrote:

Hi Stefano,

Hi Stefano,

Hi,

that is fine and my rule still apply. After all, there’s nothing that prevlude a node from having multiple sid’s.
[Pushpasis] By sids do you mean node-sids or non-node prefix sids…

a node, likely, has multiple prefixes attached to it and therefore will have multiple sids (each one attached to one of its prefixes).
These sids may be node-sids as well as prefix-sids.

 If the later I agree… But why do you need multiple node-sids for?

for many use cases where a node is known in the routing domain through multiple loopback addresses (e.g.: one for ipv4 traffic and one for vpnv4 traffic).
two (or more) loopback addresses MAY mean two or more node-sid’s.

You can associate the same node-sid for all prefixes originated from the router (e.g. All loopback addresses)..

I definitely don't like the idea because you can’t determine if it’s intended or misconfiguration. This will create a lot of room for problems.

If your use case requires to use the same label on top of packets destined to different prefixes, then my proposal of recursing into the node-sid works just fine (in addition to addressing other use cases).

s.

I am not saying that different setting different node-sids should not be used for different prefixes originated, but that cannot be mandatory as well…

this would address your 3 points above.
[Pushpasis] Yes it would..  But again there should not be a mandatory requirement to set different node-sids for each loopback address originated from a given node.

A single node-sid configured on the node can be associated with all the loopback addresses originated from the same node.

Thanks
-Pushpasis

s.

Thanks and Regards,
-Pushpasis

s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 7 Oct 2015 10:35:18 +0000

<resending due to isis-wg and spring mailers having medieval configuration).

Hi Stefano,

Hi Stefano,

Hi,

s.

Thanks
-Pushpasis

s.

Thanks and Regards,
-Pushpasis

s.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 7 Oct 2015 11:00:41 +0000

Hi Stefano,

From: "Stefano Previdi (sprevidi)"
Date: Wednesday, October 7, 2015 at 4:05 PM
To: Pushpasis Sarkar, Imtiyaz Mohammad
Cc: "Clarence Filsfils (cfilsfil)", Hannes Gredler, Isis-wg, "[email-masked]<mailto:[email-masked]>"
Subject: Re: [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

Hi Stefano,

Hi,

[Pushpasis] Only if the traffic needs to be accounted separately for each prefix. But if one does not have these needs we can use single node-sid and conserve LFIB space on transit routers. So nothing should restrict us from associating the single node-sid with 2 out 4 loopback addresses. There may mot be need to tunnel traffic for rest of the 2 loopback addresses.

[Pushpasis] I think this can be easily determined. If a prefix-SID –index learn recently has also been learnt associated with another prefix originated by another node in the network, then it is misconfiguration. Otherwise not.

[Pushpasis] No. I seem to be repeating myself. But your suggestion of recursing will result in tunnelling traffic destined for all prefixes originated (not only loopback addresses) though MPLS. Operator may not like/want this. So associating the sid-index with the loopback address with a specific address provides flexibility in picking which prefixes should be tunneled and which ones need not.

Thanks

-Pushpasis

s.

Thanks
-Pushpasis

s.

Thanks and Regards,
-Pushpasis

s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 7 Oct 2015 12:00:57 +0000

Hi Pushpasis,

[Pushpasis] No. I seem to be repeating myself. But your suggestion of recursing will result in tunnelling traffic destined for all prefixes originated (not only loopback addresses) though MPLS.

that’s not the case. please read again my proposal.

the idea is to recurse what you need into what you want. There are no constraints.

Operator may not like/want this. So associating the sid-index with the loopback address with a specific address provides flexibility in picking which prefixes should be tunneled and which ones need not.

same with my proposal.

s.

Thanks

-Pushpasis

s.

Thanks
-Pushpasis

s.

Thanks and Regards,
-Pushpasis

s.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 7 Oct 2015 13:47:58 +0000

Hi Bruno,

From: "[email-masked]<mailto:[email-masked]>"
Date: Wednesday, October 7, 2015 at 5:43 PM
To: Pushpasis Sarkar, "Stefano Previdi (sprevidi)"
Cc: Hannes Gredler, "[email-masked]<mailto:[email-masked]>", Isis-wg, Imtiyaz Mohammad, "Clarence Filsfils (cfilsfil)"
Subject: RE: [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

BTW, draft-ietf-isis-segment-routing-extensions does not explicitly state whether this is allowed or not (to advertise Special Purpose MPLS labels (aka Reserved labels)). My personal reading is that since this is not forbidden, then this is allowed.
[Pushpasis] That is exactly what I (and probably Imtiyaz too) wanted the authors to confirm and if possible explicitly spell out in the next version (we expect that draft should specifically spell out that same node-sid can be associated with multiple prefixes originated by the same node.. But not with same or different prefixes originated from different nodes). Otherwise implementations may interpret this in other way and expect all prefixes (even originated  by the same node) to have separate index associated and if they receive two or more prefixes form same node with same index they might throw and error and not install the label push for the rest of the prefixes (i.e. program it for only the first prefix learnt).

Thanks
-Pushpasis

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 7 Oct 2015 13:56:19 +0000

Pushpasis,

On Oct 7, 2015, at 3:47 PM, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>> wrote:

Hi Bruno,

BTW, draft-ietf-isis-segment-routing-extensions does not explicitly state whether this is allowed or not (to advertise Special Purpose MPLS labels (aka Reserved labels)). My personal reading is that since this is not forbidden, then this is allowed.
[Pushpasis] That is exactly what I (and probably Imtiyaz too) wanted the authors to confirm and if possible explicitly spell out in the next version (we expect that draft should specifically spell out that same node-sid can be associated with multiple prefixes originated by the same node..

is it what Bruno intended ?  Sorry, this is not what I understood. What I agree with is:

. multiple prefixes may use the node-sid of their originator (the indication may be done through Bruno’s suggestion) and through the use of prefix-attribute.

This covers the case where you want to use:
.  the same node-sid for all prefixes of the same node
. some prefixes use one node-sid and other prefixes use another node-sid
. prefixes use the node-sid while also carry a local sid.

one solution for many use cases and without opening the door to misconfigurations.

s.

But not with same or different prefixes originated from different nodes). Otherwise implementations may interpret this in other way and expect all prefixes (even originated  by the same node) to have separate index associated and if they receive two or more prefixes form same node with same index they might throw and error and not install the label push for the rest of the prefixes (i.e. program it for only the first prefix learnt).

Thanks
-Pushpasis

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 7 Oct 2015 13:57:08 +0000

Hi Robert,

From: <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk
Date: Wednesday, October 7, 2015 at 4:50 PM
To: Pushpasis Sarkar
Cc: "Stefano Previdi (sprevidi)", Hannes Gredler, "[email-masked]<mailto:[email-masked]>", Isis-wg, "Clarence Filsfils (cfilsfil)"
Subject: Re: [spring] [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

Hi Pushpasis
​,

​I do not quite agree with your above statement. Clearly you are thinking in terms how traditional MPLS router with perhaps specific implementation resolves paths and building forwarding tables in MPLS domain.

Let's observe that Segment Routing imposition may but not necessarily must use the same imposition algorithm/mechanism.

​I can easily see a case at ingress where only carefully selected by operator subset of prefixes originated by exit X will be MPLS segment routed in the given domain. Rest may be native switched or IP tunneled/encapsulated.
[Pushpasis] That is exactly what I was saying that such usecase will not be possible if we follow Stefano’s suggestion. As per his suggestion (at least that is what I understood so far)… The exit X will associate node-sid with only one loopback prefix.. And then ingress should automatically use the single node-sid for tunneling traffic for all prefixes originated by exit X.. And I am trying to say that will not provide the operator to pick a subset of prefixes.. If the ingress uses tunelling only for prefixes with which a index is associated, then the operators will have that choice..

As examples that can be accomplished by controller driven ingress map or use multiple next hops (the case where you propagate by BGP).
[Pushpasis] I did not get this usecase much. But I think we maybe saying the same thing.

Thanks
-Pushpasis

Cheers,
R.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 7 Oct 2015 14:01:43 +0000

On Oct 7, 2015, at 3:57 PM, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>> wrote:

Hi Robert,

Hi Pushpasis
​,

​I can easily see a case at ingress where only carefully selected by operator subset of prefixes originated by exit X will be MPLS segment routed in the given domain. Rest may be native switched or IP tunneled/encapsulated.
[Pushpasis] That is exactly what I was saying that such usecase will not be possible if we follow Stefano’s suggestion. As per his suggestion (at least that is what I understood so far)… The exit X will associate node-sid with only one loopback prefix.. And then ingress should automatically use the single node-sid for tunneling traffic for all prefixes originated by exit X..

this is not what I suggested.

Again, sorry to repeat myself:

You decide on a per-prefix base,  which node-sid of the originator you want to use (if any).

This gives you all the flexibility to:
. group prefixes on different node-sids or
. use the same node-sid or
. use the prefix-prefix-sid

whatever combination you need.

s.

And I am trying to say that will not provide the operator to pick a subset of prefixes.. If the ingress uses tunelling only for prefixes with which a index is associated, then the operators will have that choice..

Thanks
-Pushpasis

Cheers,
R.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 7 Oct 2015 14:02:00 +0000

Hi Bruno,

May be the selection of the specific IGP IP prefixes to be tunneled may possibly be achieved by advertising these prefixes with a Local (L-Flag)  MPLS label (V-Flag) of value 3 (Reserved “Implicit Null Label”).

[Pushpasis] This seems to be a work-around and not a proper solution. As a implementor I really don’t like this idea..  But then its my opinion.. :)

Thanks
-Pushpasis

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 7 Oct 2015 14:21:02 +0000

HI Stefano,

From: "Stefano Previdi (sprevidi)"
Date: Wednesday, October 7, 2015 at 7:31 PM
To: Pushpasis Sarkar
Cc: Robert Raszuk, Hannes Gredler, "[email-masked]<mailto:[email-masked]>", Isis-wg, "Clarence Filsfils (cfilsfil)"
Subject: Re: [spring] [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

You decide on a per-prefix base,  which node-sid of the originator you want to use (if any).
[Pushpasis] The default policy for deciding the sid to use should be the sid associated with prefix in the advertisement. Off course that can be overridden with some local policy but that is upto the implementation. The default behavior should be to use the sid associated with the prefix originally. With that default behavior the ingress should be able to use the same tunnel for more than one prefixes all originated from the same node. Which means that the originator should be able associate the same node-sid with more than one prefixes originated locally on that node.

The question I have is what is the problem if we associate the same index for multiple prefix as long as those prefixes are all originated on the same node? I don’t see a issue yet. If you can pick an example and illustrate the issue you have in mind, perhaps it will help me to get convinced as well..

Thanks
-Pushpasis

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 7 Oct 2015 14:27:09 +0000

On Oct 7, 2015, at 4:21 PM, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>> wrote:

HI Stefano,

because you brake a simple rule of sid unicity and you will not be able to distinguish the case where two prefix legitimately share he same sid from the misconfiguration case.

Also, you do not address all use cases with your solution.

s.

Thanks
-Pushpasis

---

From: Peter Psenak <[email-masked]>
Date: Thu, 08 Oct 2015 18:03:17 +0530

Hi Pushpasis,

On 10/7/15 19:51 , Pushpasis Sarkar wrote:
> Cc: Robert Raszuk, Hannes Gredler, "[email-masked]
> <mailto:[email-masked]>", Isis-wg, "Clarence Filsfils (cfilsfil)"
> *[Pushpasis] The default policy for deciding the sid to use should be
> the sid associated with prefix in the advertisement. Off course that can
> be overridden with some local policy but that is upto the
> implementation. The default behavior should be to use the sid associated
> with the prefix originally. With that default behavior the ingress
> should be able to use the same tunnel for more than one prefixes all
> originated from the same node.

how do you envision to find out the node originating a prefix in case of 
inter-area prefixe?

thanks,
Peter

> Which means that the originator should be
> able associate the same node-sid with more than one prefixes originated
> locally on that node.*
> *
> *
> *The question I have is what is the problem if we associate the same
> index for multiple prefix as long as those prefixes are all originated
> on the same node? I don’t see a issue yet. If you can pick an example
> and illustrate the issue you have in mind, perhaps it will help me to
> get convinced as well..*
> *
> *
> *Thanks*
> *-Pushpasis*
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 8 Oct 2015 13:11:37 +0000

Hi Peter,

>how do you envision to find out the node originating a prefix in case of 
[Pushpasis] The ABR on the originating area/level should be able to detect the anomaly like other nodes in the same area/level and block re-advertisement. 

Thanks
-Pushpasis

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Thu, 08 Oct 2015 07:48:17 -0700

if I understand you reply to Peter correctly, does this means that 
multi-prefix SID should not be leaked outside its originating area?

Ahmed

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 8 Oct 2015 15:21:33 +0000

Pushpasis -

Not all conflicts are intra-area - so your response does not cover all cases.

In addition, your proposal introduces some new problem areas. Do we leak the prefix but remove the conflicting SID info or stop leaking the prefix entirely?

If you think about these issues I believe the advantage of Stefano's proposal becomes clear.

     Les

> -----Original Message-----
> From: spring [mailto:[email-masked]] On Behalf Of Pushpasis Sarkar
> Sent: Thursday, October 08, 2015 6:12 AM
> To: Peter Psenak (ppsenak); Stefano Previdi (sprevidi)
> Cc: Hannes Gredler; [email-masked]; Robert Raszuk; [email-masked] list;
> Clarence Filsfils (cfilsfil)
> >how do you envision to find out the node originating a prefix in case
> >of inter-area prefixe?
> [Pushpasis] The ABR on the originating area/level should be able to detect
> the anomaly like other nodes in the same area/level and block re-
> advertisement.
> 
> Thanks
> -Pushpasis

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 8 Oct 2015 16:25:01 +0000

Hi Ahmed,

>multi-prefix SID should not be leaked outside its originating area?
[Pushpasis] For backward-compatibility with classic IGP, prefix should be re-advertised.. But prefix-sid sub-tlv should not be propagated… 

Thanks
-Pushpasis

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 8 Oct 2015 16:29:22 +0000

Hi Les,

>Not all conflicts are intra-area - so your response does not cover all cases.
[Pushpasis] I did not get the above statement. But essentially I meant that in a given area if the same index is originated (and not re-advertise/re-originated), the ABRs in that node should not propagate the prefix-sid-tlvs for that prefix to other area.. 

>In addition, your proposal introduces some new problem areas. Do we leak the prefix but remove the conflicting SID info or stop leaking the prefix entirely?
[Pushpasis] Prefix should still be re-advertised, but without the prefix-sid-subtlv. So you stop the SR-reachability without affecting the native IP-reachability.

Thanks
-Pushpasis

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 8 Oct 2015 17:56:18 +0000

Some corrections inline

On 10/8/15, 9:59 PM, "Isis-wg on behalf of Pushpasis Sarkar" <[email-masked] on behalf of [email-masked]> wrote:

>[Pushpasis] I did not get the above statement. But essentially I meant that in a given area if the same index is originated (and not re-advertise/re-originated) by multiple nodes, the ABRs in that node should not propagate the prefix-sid-tlvs for that prefix to other area.. 
>
>>
>Isis-wg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Peter Psenak <[email-masked]>
Date: Fri, 09 Oct 2015 10:10:56 +0530

Hi Pushpasis,

> [Pushpasis] The ABR on the originating area/level should be able to detect the anomaly like other nodes in the same area/level and block re-advertisement.

Node N1 in area 1 advertises prefix P1 with SID X. ABR1 advertises P1 to 
area 0.
Node N2 in area 2 advertises prefix P2 with SID X, ABR2 advertises P2 to 
area 0.

Node 3 in area 0 get these two prefixes P1 and P2 from two different 
ABRs. How does it know that the originators for P1 and P2 are different? 
Do you expect the ABR1 and ABR2 to detect the collision and withdraw SID 
advertisement to area 0? If yes, that may become source of all sorts of 
problems.

thanks,
Peter

---

From: Pushpasis Sarkar <[email-masked]>
Date: Fri, 9 Oct 2015 05:30:04 +0000

HI Peter,

>advertisement to area 0? If yes, that may become source of all sorts of 
[Pushpasis] Nodes in area 0 can see that for the same prefix there are two prefix-sid advertisements from ABR1 and ABR2 but another advertisement (not re-advertisement) from Node 3. They should then not program a IP->MPLS or MPLS->MPLS route in the FIB and raise a syslog. I am not proposing a withdraw of the prefix-sid subtlv. The syslog should notify the operator of the misconfiguration scenario.

Thanks
-Pushpasis

---

From: Peter Psenak <[email-masked]>
Date: Fri, 09 Oct 2015 11:34:18 +0530

Hi Pushpasis,

On 10/9/15 11:00 , Pushpasis Sarkar wrote:
> [Pushpasis] Nodes in area 0 can see that for the same prefix there are two prefix-sid advertisements from ABR1 and ABR2 but another advertisement (not re-advertisement) from Node 3.

there is no advertisement from Node 3 in this case. Node 3 is an 
internal router in area 0 (non-ABR). How does node 3 figures out if the 
prefixes P1 and P2 are sourced by the same node or not? Unless you carry 
the originator-id with each prefix, I don't see how you can do that.

thanks,
Peter

> They should then not program a IP->MPLS or MPLS->MPLS route in the FIB and raise a syslog. I am not proposing a withdraw of the prefix-sid subtlv. The syslog should notify the operator of the misconfiguration scenario.
>
> Thanks
> -Pushpasis
>>
>> thanks,
>> Peter
>>
>>>
>>> Thanks
>>> -Pushpasis
>>>
>>

---

From: Pushpasis Sarkar <[email-masked]>
Date: Fri, 9 Oct 2015 07:03:36 +0000

Hi Peter,

>the originator-id with each prefix, I don't see how you can do that.

[Pushpasis] I overlooked that there were two different prefixes P1 and P2 in your example. In that case I will take back my last comment and re-formulate the proposal. For the situation that you mentioned above, here is what how it should be dealt with..
1. ABR1 and ABR 2 re-advertises the prefixes P1 and P2 into Area 0.
2. ABR1 will learn from ABR2’s advertisement in Area 0 that the same index is associated with P1 originated by N1 in Area 1 and and a different prefix P2 (re)originated from another node ABR2 in Area 0. It should then raise a syslog error notifying that this seems to be misconfiguration.
3. Likewise, ABR2 will learn from ABR1’s advertisement in Area 0 that the same index is associated with P2 originated by N2 in Area 2 and and a different prefix P1 (re)originated from another node ABR1 in Area 0. It should then raise a syslog error notifying that this seems to be misconfiguration.
4. And then none of the ABRs should withdraw the prefix-sid-advertisements (I take back my last comment). Things should be left as is till the operator rectifies the configuration.

The basic rule for any node to detect a anomaly and take action should be as follows…
A. Multiple prefix originated with same but from same originator.. No need to throw error
B. Multiple prefix originated with same index but from different originator..  Throw syslog.. Use the index advertised with best-originator(s) of the prefix for MPLS ingress/transit routes.
C. Same prefix originated with different index from same originator.. Throw syslog.. But don’t program MPLS ingress/transit routes for it… Ideally this scenario is almost next to impossible unless any implementation allows assoicating multiple sids with a singe prefix.
D. Same prefix originated with different index from same originator.. Throw syslog.. Use the index advertised with best-originator(s) of the prefixfor MPLS ingress/transit routes.

Hoping I have covered all possible situation with the above set of rules.

Thanks
-Pushpasis

---

From: Peter Psenak <[email-masked]>
Date: Fri, 09 Oct 2015 14:58:49 +0530

Hi Pushpasis,

> 4. And then none of the ABRs should withdraw the prefix-sid-advertisements (I take back my last comment). Things should be left as is till the operator rectifies the configuration.

the question is what Node 3 does? If it assumes that thees are coming 
from same originator, it may end up sending the traffic wrong way, which 
a serious issue.

> A. Multiple prefix originated with same but from same originator.. No need to throw error

we do not seem to have a consistent way to detect the same originator, 
unless we advertise originator with every prefix.

> B. Multiple prefix originated with same index but from different originator..  Throw syslog.. Use the index advertised with best-originator(s) of the prefix for MPLS ingress/transit routes.

there is no best-originator, that is the whole point.

> C. Same prefix originated with different index from same originator.. Throw syslog.. But don’t program MPLS ingress/transit routes for it… Ideally this scenario is almost next to impossible unless…

we should not make the behavior implementation specific.

> Hoping I have covered all possible situation with the above set of rules.

the question really is if the above is worth the benefit you get.
It seems that simplicity may be a better option here.

thanks,
Peter

---

From: Pushpasis Sarkar <[email-masked]>
Date: Fri, 9 Oct 2015 09:56:29 +0000

Hi Peter,

>from same originator, it may end up sending the traffic wrong way, which 
[Pushpasis]Node 3 should follow rule D below. For the ingress traffic at Node 3, it will choose the next-hop towards ABR1 and for P1 and the next hop towards ABR2 for P2. However for the transit route for SID X, it has to choose who is the best-originator (among ABR1 and ABR2) for SID X, and choose the nexthop towards the same. The resulting traffic path may not still be right. But the protocol should not take care of it other than throwing a syslog/error-message. Operator should rectify the misconfiguration.

>there is no best-originator, that is the whole point.
[Pushpasis]I meant best-(re)originators. So for nodes in Area 0 ABR1 and ABR2 are the (re)originators.

>we should not make the behavior implementation specific.
[Pushpasis] Fully agree. That is why I am asking the draft to spell out the expected behavior explicitly. So that all implementations can follow the same behavior.
>
>> D. Same prefix originated with different index from different originator.. Throw syslog.. Use the index advertised with best-originator(s) of the prefixfor MPLS ingress/transit routes.
>>
[Pushpasis] Often simplicity in implementation also brings a lot of limitations along with. We need to always draw the line somewhere in the middle, and strike a balance between simplicity of the implementation and usability it offers to the end-users. If simplicity limits a user from deploying the solution in his/her existing network, what use is that implementation? :)

I have already mentioned in a previous mail about the limitation ‘per-prefix-unique-sid-index’ approach brings. And I won’t be repeating myself again and again on this thread anymore. 

Thanks
-Pushpasis

---

From: Peter Psenak <[email-masked]>
Date: Fri, 09 Oct 2015 16:01:08 +0530

Hi Pushpasis,

> [Pushpasis]Node 3 should follow rule D below. For the ingress traffic at Node 3, it will choose the next-hop towards ABR1 and for P1 and the next hop towards ABR2 for P2. However for the transit ro…

you have to take into consideration the result of the behavior you are 
proposing. The fact that traffic goes wrong may be a bigger issue than 
you believe.

> [Pushpasis]I meant best-(re)originators. So for nodes in Area 0 ABR1 and ABR2 are the (re)originators.

same issue, there is no best-(re)originator, regardless of whatever 
rules we use to choose it.

> [Pushpasis] Often simplicity in implementation also brings a lot of limitations along with. We need to always draw the line somewhere in the middle, and strike a balance between simplicity of the i…

there is other side of the coin too. The more complexity you add, more 
difficult will it be to develop, deploy, maintain and support. So you 
need to balance it with the gain you get.

thanks,
Peter

---

From: Pushpasis Sarkar <[email-masked]>
Date: Fri, 9 Oct 2015 12:02:47 +0000

Hi Peter,

>need to balance it with the gain you get.

[Pushpasis] I think principal-wise we are saying the same thing… The only disagreement is about that... While you are saying this proposal is more complex.. I am saying without this proposal it is more limiting… :)

My personal opinion we should try to remove the limitations.. And if the WG consensus is that the limitations are not considerable and operators can live with…  i.e. it is okay to have the limitation to always have per-prefix-index (one index per prefix)... Then.. I would prefer that to be explicitly stated in the SR drafts. Currently all it says is ‘IGP Prefix SID MUST be globally unique in a IGP domain’. It is not clear what it really means.. One can easily interpret it as no two node in the IGP domain can originate/assign the same Prefix SID. It does not say that a single node cannot use the same Prefix SID for multiple locally-originated prefixes (e.g. Local loopback address). That needs to be clarified with some explicit text in all the relevant SR drafts.

Thanks
-Pushpasis