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

[Pushpasis Sarkar <[e-mail]>]

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, "[e-mail]<mailto:[e-mail]>"
Subject: [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases

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

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


(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<http://30.30.30.30/32>

     node segment 100 for 40.40.40.40/32<http://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<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.


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


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


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