Les, The use-case you are describing here is SRMS advertisements and there is no problem in handling SRMS advertisements. There is a special indication in the protocol messages to indicate it is an SRMS advertisement and it is documented in ISIS and OSPF drafts in detail, how to handle the scenario.
You are suggesting to use the same procedures to handle the case of anycast-SIDs where prefix advertisements aren't accompanied by a SID advertisements for some of the prefixes. This procedure does work for anycast-SIDs and I suggest you to add the text to the draft to standardize. I believe conflict resolution draft is the best place to add it. Below is my suggested text for the draft. "Section 3.2.3 Anycast SIDs [SR-ARCH] defines anycast SIDs which is used for a number of use-cases. When there are multiple nodes which advertise same anycast prefix, it is possible that one of the nodes does not advertise a SID for the prefix. This discrepancy is not detected by the conflict resolution procedure as the conflict resolution database takes the prefix-SID mappings as input and this particular case does not have prefix-SID mapping. The forwarding plane follows IP routing and so nodes in the network MAY point to a node which does not advertise a SID. This situation is similar to an SRMS advertisement where prefix reachability advertisements from a node does not include a SID advertisement for the prefix. The route programming for such anycast SIDs should follow the PHP procedures as described in, [SR-ISIS] and [SR-OSPF] for an SRMS advertisement." Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Friday, May 5, 2017 12:53 PM To: Shraddha Hegde <shrad...@juniper.net>; draft-ietf-spring-conflict-resolut...@ietf.org Cc: spring@ietf.org Subject: RE: Mail regarding draft-ietf-spring-conflict-resolution Shraddha - I say again - there is no conflict and there is no config error. Let's use another example which does NOT involve anycast. --------------A (1.1.1.1) / G-----------------B (1.1.1.2) \ ----------------C(1.1.1.3) NO SIDS are locally configured on any routers because the operator has chosen to use SRMS as a global provisioning tool. Therefore none of the prefix reachability advertisements include a SID. SRMS (say advertised by some node "F" ) advertises the following: 1.1.1.1/32 100 range 3 SRMS advertisements do not support P/E flags. When G forwards the following packets it has to make a decision as to whether to do PHP, UHP, EXPLICIT_NULL: 1.1.1.1 to A 1.1.1.2 to B 1.1.1.3 to C But there is no advertisement of P/E for any of the destinations. It must follow a default behavior. If you think there is a problem here, please clearly state what it is and what you think should be done about it. But whatever you think it might be, this has nothing to do with SID conflict resolution - which is defining a way to resolve advertised Prefix Conflicts/SID Conflicts as defined in Section 3.2 of the draft. Les From: Shraddha Hegde [mailto:shrad...@juniper.net] Sent: Thursday, May 04, 2017 10:02 PM To: Les Ginsberg (ginsberg); draft-ietf-spring-conflict-resolut...@ietf.org<mailto:draft-ietf-spring-conflict-resolut...@ietf.org> Cc: spring@ietf.org<mailto:spring@ietf.org> Subject: RE: Mail regarding draft-ietf-spring-conflict-resolution Les, The issues we are discussing here are specific to Segment Routing and SPRING is the right WG to address this. The problem here is not about standardizing what is the default PHP behavior, it is about the scenarios when this default behavior assumption need to be applied. The problem doesn't get solved by applying default PHP behavior in all cases. Assume 1.1.1.1 in the example below is a redistributed prefix from another ISIS Level. In that case the pop and forward will cause the service labels to get exposed at A which would cause black-holing or misrouting. These are issues caused by config errors and IMO conflict resolution draft is the right place to describe these cases and the solutions so that all vendors have consistent behaviours. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Friday, May 5, 2017 12:05 AM To: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>; draft-ietf-spring-conflict-resolut...@ietf.org<mailto:draft-ietf-spring-conflict-resolut...@ietf.org> Cc: spring@ietf.org<mailto:spring@ietf.org> Subject: RE: Mail regarding draft-ietf-spring-conflict-resolution Shraddha - First, there is no SID conflict here. There is therefore nothing for the conflict resolution draft to discuss. Let's look at your scenario more detail. To do so let's use the following simple topology: --------------A / G-----------------B \ ----------------C Using your example w addition of P/E flag settings in prefix-sid advertisement (using IS-IS naming convention). For simplicity assume all nodes have the default SRGB (16000 - 23999). 1.prefix 1.1.1.1 advertised from node A with no SID 2.Prefix 1.1.1.1 advertised from node B with SID 10 P flag = 0 E flag = 0 3. Prefix 1.1.1.1 advertised from node C with SID 10 P flag = 1 E flag = 0 Using procedures defined in draft-ietf-spring-conflict-resolution all nodes in the network will use SID 10 when forwarding traffic to 1.1.1.1. The question is what should the penultimate next hop router do when forwarding a packet to each of the owning nodes? When G forwards the packet to B, PHP is indicated, so G will POP. When G forwards the packet to C, UHP is indicated and E flag is 0, so G will send the packet with outgoing label 16010. When G forwards the packet to A, because A has not advertised the prefix-SID (but is SR capable) we do not know whether it wants PHP or not - so we have to make an assumption. Default MPLS behavior is to assume PHP. If A does not want PHP then it would have to advertise the prefix SID so it could specify desired behavior using P/E flags. Note that this same situation can occur if the mapping server is used as a global provisioning tool. In such a case no prefix-SIDs need be advertised in prefix reachability advertisements - all SIDs are advertised by SRMS advertisements which do not include P/E flags. Historically, MPLS implementations have chosen a default behavior (equivalent to P and E flags = 0). Some implementations provide knobs to override this behavior. If your concern is that there is not an explicit definition of default PHP/Explicit NULL behavior, then I think this needs to be directed at the MPLS WG. I do not claim to be an MPLS expert, but I have found these references: RFC 3036 Section 6 "- Section 2.16 of the MPLS architecture [RFC3031] requires that the initial label distribution protocol negotiation between peer LSRs enable each LSR to determine whether its peer is capable of popping the label stack. This version of LDP assumes that LSRs support label popping for all link types except ATM and Frame Relay. A future version may specify means to make this determination part of the session initiation negotiation." Les From: Shraddha Hegde [mailto:shrad...@juniper.net] Sent: Wednesday, May 03, 2017 10:16 PM To: Les Ginsberg (ginsberg); draft-ietf-spring-conflict-resolut...@ietf.org<mailto:draft-ietf-spring-conflict-resolut...@ietf.org> Cc: spring@ietf.org<mailto:spring@ietf.org> Subject: RE: Mail regarding draft-ietf-spring-conflict-resolution Les, >From what you describe in section 3.3.8, all the SIDs attached to prefixes are >fed into the database. The example I am talking about, 1.prefix 1.1.1.1 advertised from node A with no SID 2.Prefix 1.1.1.1 advertised from node B with SID 10 3. Prefix 1.1.1.1 advertised from node C with SID 10 The advertisements 2 and 3 are fed into the mapping database and 1 isn't. The conflict resolution does not detect any conflict with the above advertisements and For prefix 1.1.1.1 /SID 10 is chosen. All this is fine but the problem is in programming the forwarding plane. Lets say for a certain node E in the network node A is the nexthop for 1.1.1.1. How would node E program its forwarding plane? Node E should recognize the conflict between node A, Node B and C and program the SID 10 with a pop and forward instead of looking into the P and E flags of the SID 10? This is good enough detail, that should be explained in the draft instead of leaving it to the Imagination of implementers. Rgds Shraddha From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Wednesday, May 3, 2017 11:47 PM To: Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>; draft-ietf-spring-conflict-resolut...@ietf.org<mailto:draft-ietf-spring-conflict-resolut...@ietf.org> Cc: spring@ietf.org<mailto:spring@ietf.org> Subject: RE: Mail regarding draft-ietf-spring-conflict-resolution Shraddha - There is a misunderstanding on your part. It would be good if you read Section 3.3.8. Guaranteeing Database Consistency again. In short, it does not matter whether you do or do not advertise a prefix SID for a prefix which you own. What matters is that all routers populate the mapping entry database consistent w Section 3.3.8 and that each router applies the conflict resolution rules in a consistent manner. Then all routers will be using the same prefix/SID pair in forwarding. Les From: Shraddha Hegde [mailto:shrad...@juniper.net] Sent: Wednesday, May 03, 2017 9:58 AM To: draft-ietf-spring-conflict-resolut...@ietf.org<mailto:draft-ietf-spring-conflict-resolut...@ietf.org> Cc: spring@ietf.org<mailto:spring@ietf.org> Subject: Mail regarding draft-ietf-spring-conflict-resolution Hi Authors, When there are multiple anycast IP addresses assigned to different nodes and one or more nodes do not advertise a Prefix SID for that anycast address but other nodes advertise a prefix-sid, there is a possibility of different implementations behaving differently with respect to programming the labelled routes. This scenario should be considered as a prefix conflict and the behavior should be addressed in the draft. I suggest to update section 3.2.1 with the relevant text to describe the behavior. Rgds Shraddha
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
