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>; draft-ietf-spring-conflict-resolut...@ietf.org Cc: 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
