Eric - First I want to say that this input is exactly what I was hoping to get. Thanx.
We also had concluded that the issue of default PHP behavior is applicable to SR-MPLS precisely because advertisements are globally scoped. As it is possible in some circumstances (SRMS advertisement on behalf of an SR capable node is the most practical example) that explicit indication of the desired PHP behavior is not advertised a default behavior is required. We are assuming a default behavior of PHP for SR-MPLS. If folks believe this requires explicit specification I would propose language similar to the following: "When Segment Routing is instantiated over the MPLS data plane the penultimate node performs the NEXT operation (i.e., MPLS pop) unless a specific indication to do otherwise is advertised by the ultimate node." As to why we are choosing PHP rather than UHP as the default, it is our belief that most of the platforms which support MPLS today have been implemented to take advantage of the optimizations that PHP affords. In some cases it may even be true that UHP is not supported at all. Of course if UHP is required prefix-SID advertisements provide the means to indicate this. I hope this resolves the issue. (NOTE: I will discuss the issue of anycast advertisements w/wo a SID in a separate email) Les From: Eric C Rosen [mailto:ero...@juniper.net] Sent: Wednesday, May 10, 2017 7:27 AM To: Les Ginsberg (ginsberg); Shraddha Hegde; draft-ietf-spring-conflict-resolut...@ietf.org Cc: spring@ietf.org Subject: Re: [spring] Mail regarding draft-ietf-spring-conflict-resolution On 5/4/2017 2:35 PM, Les Ginsberg (ginsberg) wrote: 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. I'm not sure why you think there is such a thing as "default MPLS behavior" in this regard. In conventional MPLS, when a node advertises the binding of a label to a FEC, PHP will not occur unless the advertised label is Implicit NULL. If you advertise a different label, you don't get PHP. If there were any such thing as a default behavior for MPLS, it wouldn't make any sense for PHP to be the default behavior. You can only advertise Implicit NULL if you know that the packet can be properly processed after the top label is popped off. Whether PHP will give the right result is application-specific. So if there were a default behavior, it would have to be "don't do PHP". But of course MPLS has no need of such a default behavior, because each node advertises its own labels. Since the segment routing architecture allows cases where you don't know whether the next hop wants you to pop the stack or not, segment routing needs to have a default, and the only sensible default is "don't do PHP". This should be stated in whatever document discusses the use of the MPLS data plane for segment routing. I don't see that there is any issue for the MPLS WG. 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. A default of "do PHP" doesn't seem sensible, as it may result in the exposure of a label at a node that cannot process it properly. Historically, MPLS implementations have chosen a default behavior (equivalent to P and E flags = 0). Some implementations provide knobs to override this behavior. I wonder if you're thinking about the case where the next hop has advertised Implicit NULL for a particular FEC, but the current hop actually uses Explicit NULL in order to have a place to put the TC field, which would otherwise be lost when PHP is done. That doesn't really seem relevant to the issue that Shraddha raised. 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 think this is incorrect, as explained above. 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." Well, you don't have to be an MPLS expert to notice that RFC3036 was obsoleted ten years ago ;-) In any event, the above quote is not relevant. It simply says that when using LDP, an LSR may assume, for most data link types, that an LDP peer is capable of popping the top label off the stack. Thus it is allowable to advertise to the peer a binding of Implicit NULL to a FEC. This is an issue for LDP, but there is no way to apply the quoted passage to segment routing. This really needs to be addressed in some SPRING draft or other.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
