Hi Gyan, Many thanks for your comments. Please see my reply inline.
However, I have not answer all the comments yet. I think it will be better to separate the comments into different threads, and we can address them one by one. Again! Thank you for your comments! Respect, Cheng From: Gyan Mishra [mailto:[email protected]] Sent: Tuesday, September 28, 2021 5:04 AM To: SPRING WG <[email protected]>; [email protected]; j00406941 <[email protected]>; [email protected]; [email protected] Subject: RE: [Spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/ Dear Rakesh & Authors I replied during WGLC on July 29th supporting publication of this draft, but did not hear back from the authors. I have since added some additional comments in this email related to this SR-MPLS draft as well as other Path Segment related drafts and how they reference each other as normative references as well as how each of the drafts help explain the entire path segment solution and how SR-MPLS and SRv6 path segment solutions related to the extensions for PCE and SR policy updates. This draft can be very useful for operators and provides an RSVP-TE record route style function in a new Path SID that can be leveraged for IOAM PM use case as well as BIDIR path association and 1+1 protection solution. As all of these drafts relate to each other from a SR PSID path segment perspective I would like to comment on all of the drafts below as it relates to this draft WGLC as well as progressing the other drafts listed below also provide some synchronization and parity between the drafts: All 5 drafts as they define the overall SR Path Segment solution, I believe they all should have normative mentions of each of the other drafts. I reviewed all 5 drafts and they do except for any noted below. [Cheng] Many thanks for your support! Yes, Path Segment can be used in many use cases like you mentioned. Well, they may not need to cite each other as normative reference I think, we need to discuss one by one. The Data plane extension drafts of SR-MPLS & SRv6 Path Segment are the basic drafts. They can be the normative referred at the control plane drafts like PCE and BGP, that is correct, and we believe we did it. If we miss some reference, you are welcome to point it out, many thanks for your help! ☺ I think we do not need to make PCE draft as the normative reference of BGP extension draft, and vice versa. Because they are not dependencies between these two protocol. Informative reference is the correct choice. SR Path Segment drafts: SR-MPLS Path Segment https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment-05 SRv6 Path Segment https://datatracker.ietf.org/doc/html/draft-li-spring-srv6-path-segment-07 [Cheng] This has been adopted, and become draft-ietf-spring-srv6-path-segment<https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-path-segment/> PCE SR extension for PSID path Segment https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-path-segment-04 PCE SR extension for BIDIR PSID Path Segment https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path SR Policy Path Segment https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-segment SR MSD as it applied to SR-MPLS & SRv6 Compression & how Path Segment can be used to alleviate MSD issues: Can the Path Segment solution be used to help with MSD issues for both SR-MPLS & SRv6 very long strict paths by being able to reference inter-as paths as PSID/BSID sub paths instead of the expanded path? [Cheng] BSID is using for shortening the SID list, while the Path Segment will not be used for this. It is an ID space for path associated services. SR-MPLS Path Segment - WGLC Review: https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment-05 Recommendation to update the verbiage to state that 1+1 path protection is an SR-MPLS specification optimization using PSID solution. Since PSID can be used for 1+1 path protection my thoughts are that maybe PSID can be used to help overall in MSD SID depth issues on the primary active path for very long paths to help with SID depth and reduce the size SID path length with PSID/BSID nested sub path segments. PSID could also be stated as an optimization for MSD issues for very long strict paths to help in the reduction of the size of the SID list in an SR-TE policy to define the path using the BSID/PSID path vector to compress the explicit path. My thoughts are that Sub paths created by PSID/BSID keys can be used for inter-as paths across multiple domains, a similar concept of RFC 4736 lose hop expansion can be used for longer paths to help compress and cutdown on the E2E Path containing all the SIDs. In cases where the intra-as path is very long the path can be broken up into PSID/BSID sub paths regions within a domain. I believe this could apply to both SR-MPLS & SRv6 very long E2E strict paths that cross many AS’s and domains. [Cheng] Using BSID can shorten the SID list. In case like BFD echo mode, we may have two solutions to shorten the SID list. · Using BSID: Putting the BSID of the reverse direction path at the end of the SID list to specify the reverse path. · Using PSID: Putting the PSID of the reverse direction path at the end of the SID list to specify the reverse path. In this case, the egress node should process the path Segment and encapsulate the reverse SID list for the packet. It can work. Abstract section: OLD TXT A Segment Routing (SR) path is identified by an SR segment list. Only the complete segment list can identify the end-to-end SR path, and a sub-set of segments from the segment list cannot distinguish one SR path from another as they may be partially congruent. SR path identification is a pre-requisite for various use-cases such as Performance Measurement (PM), bidirectional paths correlation, and end-to-end 1+1 path protection. In SR for MPLS data plane (SR-MPLS), the segment identifiers are stripped from the packet through label popping as the packet transits the network. This means that when a packet reaches the egress of the SR path, it is not possible to determine on which SR path it traversed the network. This document defines a new type of segment that is referred to as Path Segment, which is used to identify an SR path in an SR-MPLS network. When used, it is inserted by the ingress node of the SR path and immediately follows the last segment identifier in the segment list of the SR path. The Path Segment will not be popped off until it reaches the egress node of the SR path. The Path Segment then can be used by the egress node to implement SR path identification and correlation. NEW TXT Segment Routing (SR) [RFC8402<https://datatracker.ietf.org/doc/html/rfc8402>] leverages the source-routing paradigm to steer packets from a source node through a controlled set of instructions, called segments, by prepending the packet with an SR header in the MPLS data plane SR-MPLS [RFC8660<https://datatracker.ietf.org/doc/html/rfc8660>] through a label stack or IPv6 data plane using an SRH header via SRv6 [RFC8<https://datatracker.ietf.org/doc/html/rfc8402>986] to construct an SR path. The MPLS forwarding plane does not preserve the path state at the egress node that maybe use for various optimization and path correlation use cases similar to what is provided by RSVP-TE record route object. This document defines a new type of segment that is referred to as Path Segment, which is used to identify an SR path in an SR-MPLS network. When used, it is inserted by the ingress node of the SR path and immediately follows the last segment identifier in the segment list of the SR path. The Path Segment is preserved until it reaches the egress node for SR path identification and correlation. This document defines a new path segment that enables SR path identification which is a pre-requisite for various use-cases such as Performance Measurement (PM), bidirectional paths correlation, as well as SR-MPLS specification optimizations such as end-to-end 1+1 path protection and SR path list compression for MSD optimizations. [Cheng]thank you for your text, we will consider this ☺ Introduction section: OLD TXT Segment Routing (SR) [RFC8402<https://datatracker.ietf.org/doc/html/rfc8402>] is a source routed forwarding method that allows to directly encode forwarding instructions (called segments) in each packet, hence it enables steering traffic through a network without the per-flow states maintained on the transit nodes. Segment Routing can be instantiated on an MPLS data plane or an IPv6 data plane. The former is called SR-MPLS [RFC8660<https://datatracker.ietf.org/doc/html/rfc8660>], the latter is called SRv6 [RFC8402<https://datatracker.ietf.org/doc/html/rfc8402>]. SR-MPLS leverages the MPLS label stack to construct an SR path. NEW TXT Segment Routing (SR) [RFC8402<https://datatracker.ietf.org/doc/html/rfc8402>] leverages the source-routing paradigm to steer packets from a source node through a controlled set of instructions, called segments, by prepending the packet with an SR header in the MPLS data plane SR-MPLS [RFC8660<https://datatracker.ietf.org/doc/html/rfc8660>] through a label stack or IPv6 data plane using an SRH header via SRv6 [RFC8<https://datatracker.ietf.org/doc/html/rfc8402>986] to construct an SR path. [Cheng]We will consider this at the next update, many thanks!!! In the SRv6 PSID draft PSP must be disabled in SRv6 PGM. For SR-MPLS PSID draft PHP implicit null does not need to be disabled as long as the BOS S bit is set and the TTL is set to last label in label stack. Agreed. Since the label stack for L2/L3 VPN is 2 labels deep with topmost label as topological label and bottom label as the service label. Would the Path segment appear as the last label in the set of labels or SR label stack representing the topological path or below the service label and in that case would have the BOS bit S set. Would the path segment label only be the bottom label for Global table routing where no service label exists but if a L2/L3 VPN service label exists then the S bit would not be set on the PSID? In figure 1 it shows the PSID label as the last label, below the Service labels. If that is the case then the BOS S bit would be set. Can we state explicitly if the path label will always be the bottom label or are there certain circumstances where it would not be the bottom label. How does the PSID label TTL change in PHP enabled versus disabled mode with respect to pipe and uniform mode RFC 3443. [Cheng] I think we can separate the comments into different threads for discussion. So will answer your above comments in next email. RFC 8662 states that the entropy label ELI/EL would be placed at readable depths within the label stack section 10.5. “Entropy label and Entropy Label Indicator (ELI) as described in [RFC8662<https://datatracker.ietf.org/doc/html/rfc8662>] for SR-MPLS path, can be placed before or after the Path Segment label in the MPLS label stack.” So how would you prevent the PSID label from being popped in the PHP case if it’s Entropy label is placed before or after the PSID label? Also I am not sure how that would work if per RFC 8662 the placement of the ELI/EL for load balancing and issues with DPI and processing is placed at per section 10.5 at readable depths? The introduction section of the SRv6 Path draft mentions the SR-MPLS path segment solution & as they both are drafts and similar maturity states the SR-MPLS path segment draft should mention the SRv6 path segment draft as well to be complete. [Cheng] this is because of SR-MPLS draft was proposed before SRv6 draft. But we do not have dependencies between these two documents. So I think we can mention this in the draft as an informative reference, good! Section 6 should mention PCE bidir path segment draft. I don't see it mentioned. https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path Section 7 E2E path protection it would be helpful to have a picture similar to section 4 with sub paths and depicting a similar scenario with access, aggregation & core E2E path with the BSID/PSID path nested sub paths and how they 1+1 protection of the E2E would be instantiated. [Cheng] Can add it in the next revision ☺ SRv6 Path segment draft - Comments: https://datatracker.ietf.org/doc/html/draft-li-spring-srv6-path-segment-07 In the SR-MPLS Path segment draft can the section 4 Nesting of paths segments concept with PSID/BSID path vector sub paths apply to SRv6? I think this would help tremendously with SRv6 compression for long inter-as paths. Also as stated above can the path segments be used for not only 1+1 path protection, but also for defining the E2E path with a minimal number of SIDs thereby compression of the overall SID path and help eliminate MSD issues & be a possible SRv6 compression solution. It would be useful to have a section on 1+1 path protection mechanism graphical depiction with PSID/BSID sub-paths similar to my SR-MPLS path draft comment. [Cheng] When considering using the PSID as a routing ID for compression, I think you can read the draft of PPR(Preferred Path Route). But doing so will need to maintain the per-path forwarding statement at nodes, which bring as back to the RSVP-TE I guess. So it will be another way, but not stateless SR. PCE SR extension for PSID path Segment Comments: https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-path-segment-04 Draft is well written. No comments PCE SR extension for BIDIR PSID Path Segment Comments: https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path Draft is well written. No comments SR Policy Path Segment Comments: https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-segment Draft is well written. No comments Kind Regards Gyan James Guichard [email protected]<mailto:[email protected]> via<https://support.google.com/mail/answer/1311182?hl=en> ietf.org<http://ietf.org> Wed, Jul 7, 11:49 AM [https://mail.google.com/mail/u/0/images/cleardot.gif] [https://mail.google.com/mail/u/0/images/cleardot.gif] to [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]> [https://mail.google.com/mail/u/0/images/cleardot.gif] Dear WG: This email starts a 2 week Working Group Last Call for draft-ietf-spring-mpls-path-segment [1]. Please read this document if you haven’t read the most recent version and send your comments to the SPRING WG list no later than July 21st 2021. If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point. Lastly, if you are an author or contributor please response to indicate whether you know of any undisclosed IPR related to this document. Thanks! Jim, Joel & Bruno [1] https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/ [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
