<resending due to isis-wg and spring mailers having medieval configuration).
On Oct 7, 2015, at 11:29 AM, Pushpasis Sarkar <psar...@juniper.net<mailto:psar...@juniper.net>> wrote: 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)", "bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>", Jeff Tantsura, Isis-wg, "spring@ietf.org<mailto:spring@ietf.org>" Subject: Re: [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases On Oct 6, 2015, at 7:48 PM, Pushpasis Sarkar <psar...@juniper.net<mailto:psar...@juniper.net>> wrote: Hi Stefano, Thanks for your response. Please find few comments inline. On 10/6/15, 10:22 PM, "Stefano Previdi (sprevidi)" <sprev...@cisco.com<mailto:sprev...@cisco.com>> wrote: 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. [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. 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. [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… 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. [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. 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. 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 [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. [Pushpasis] The use case in the original mail is also valid. 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. [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.. Both types of use case (co)exist and we MUST NOT assume there’s only one type. 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. 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 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 <psar...@juniper.net<mailto:psar...@juniper.net>> wrote: 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, "spring@ietf.org<mailto:spring@ietf.org>" Subject: Re: [Isis-wg] Handling same SID mapped to different prefixes and vice versa cases Thanks Pushpasis ! That helps. On Thu, Oct 1, 2015 at 4:24 PM, Pushpasis Sarkar <psar...@juniper.net<mailto:psar...@juniper.net>> wrote: 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, "spring@ietf.org<mailto:spring@ietf.org>" 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 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. [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 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. [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 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. [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 -- Mohammad Imtiyaz Software Engineer Arista Networks Bangalore +91 9901101171
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
