Hi Sasha, Thanks for your prompt response.
Maybe I am not clear in my last email, my thought was not to deduce the network protocol from the last label above the Path segment label when a packet is received. Because the last label of the SR path and its implied network protocol is known, the correlation between the network protocol and the Path Segment label will be deduced when the Path Segment label is signaled or configured and be installed in a local table. Given this, a node (e.g., the egress) can know the network protocol by looking up the local table and know how to process the packet (e.g., pop the Path Segment label and continue process the payload according to the deduced network protocol). Of cause, I also think you suggested solution workable. Regarding the two solutions introduced in the draft, as noted in the draft, it intends to trigger the WG to discuss and decide which one is more preferred. I still remember that you thought 1-label solution is more preferred in a previous discussion. Regarding the 2-label solution, if the only downstream-allocated labels are allowed in SR-MPLS, indeed the 2-label solution is precluded. I am open with it, but I will let others to express their points. Best regards, Mach From: Alexander Vainshtein [mailto:[email protected]] Sent: Friday, July 13, 2018 3:36 PM To: [email protected]; Mach Chen <[email protected]> Cc: [email protected] Subject: Re: A question about Path Segment draft Mach hi! Lots of thanks for a prompt response. Unfortunately your pdoposal zeems problematic to me because in many cases the last label above the Path Segment one will be popped by the penultimate node (e.g. if it identifes an Adj-SID or a Node SID for which PHP has been advertised). >From my POV the preferred solution could be limiting payload of tbe >problematic packets to just IPv4 and IPv6 and using the 1st nibble of the >payload to differentiate between them. AFAIK this is commonly supported by >many existing chipsets, si implementing this would be reasonably simple. But >of course this is for you and your co-authors to decide. On another issue: The draft offers 2 solutions, with the 2-label solution effectivel using upstream-allocated labels. I hhave raised the issue of upstream-allicated labels in my early RTG-DIR review of the SR-MOLS draft, anx the curre t position of the Editkr is that only downstream-allocated labels are used in SR-MPLS. This looks to me as precluding the 2-label solution. My 2c Thumb typed by Sasha Vainshtein ________________________________ From: Mach Chen <[email protected]<mailto:[email protected]>> Sent: Friday, July 13, 2018 5:04:22 AM To: Alexander Vainshtein; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: RE: A question about Path Segment draft Hi Sasha, Thanks for your valuable question! Since a Path Segment is just designed to identify an SR path, if the Path Segment label is the BoS label, the network protocol of the packet should be the same as the one implied by the last label of the SR path. That means, no matter through signaling or configuration, when install a Path Segment label, the implicit network protocol can deduced from the last label of the SR path. Hope this clarify the question, or maybe you have other suggestions. Best regards, Mach From: Alexander Vainshtein [mailto:[email protected]] Sent: Thursday, July 12, 2018 6:00 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: A question about Path Segment draft Dear colleagues, One of the issues I've raised during my Early RTG-DIR review<https://datatracker.ietf.org/doc/review-ietf-spring-segment-routing-mpls-13-rtgdir-early-vainshtein-2018-06-10/> of the SR-MPLS<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-14> draft dealt the way in which identity of the network protocol of the packet can be inferred when the label that represents some segment ID happens to be the bottom-of-stack label. The Editors' response<https://www.ietf.org/mail-archive/web/spring/current/msg03877.html> was that for labels representing Prefix and Adjacency SIDs, the network protocol of such a packet is always either Ipv4 and IPv6. For Prefix SIDs this is obvious and for Adjacency SIDs IPv4 vs. IPv6 is indicated by the F-Flag in the corresponding IS-IS TLV (or its analogs for OSPF). This is also applicable for Binding SID because it refers to a specific prefix (or a range of prefixes from the same family). >From my POV this response is sufficient in the context of the SR-MPLS. >However, it does not help in the case of Path Segments introduced with your >draft. One use case for the label representing a Path Segment being BoS is LSP Ping (RFC 8029) for Segment Routing (RFC 8287) since both IPv4 and IPv6 packets can follow the BoS label in LSP Ping. It is not even clear whether packets immediately following the Path Segment label that is BoS can be neither IPv4 nor IPv6. Your clarification of this point would be highly appreciated. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected]<mailto:[email protected]> ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________ ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
