Hi Ketan, Many thanks for your thorough review, and sorry for my delay. Please see my reply inline. BTW, the proposed update is attached, authors please review as well.
You can also review it from the Github repository. https://github.com/muzixing/SR-MPLS-Path-Segment/commit/343f7efe3f67a0bc2c02a239d575a2cc658c0aa5 Thanks, Cheng From: Ketan Talaulikar <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> Sent: Monday, November 28, 2022 3:39 PM To: last-c...@ietf.org<mailto:last-c...@ietf.org> Cc: IETF-Announce <ietf-annou...@ietf.org<mailto:ietf-annou...@ietf.org>>; andrew-i...@liquid.tech<mailto:andrew-i...@liquid.tech>; draft-ietf-spring-mpls-path-segm...@ietf.org<mailto:draft-ietf-spring-mpls-path-segm...@ietf.org>; james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>; spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org> Subject: Re: Last Call: <draft-ietf-spring-mpls-path-segment-08.txt> (Path Segment in MPLS Based Segment Routing Network) to Proposed Standard Hello Authors, Please find below some comments on the draft. I hope these can be addressed to fix/improve the document. Major: 1) Sec 1: The term "SR path" is not defined in either RFC8402 or RFC9256. It seems this document is trying to introduce this terminology/concept. If so, it needs to be defined more formally with respect to the SR Policy. There is some text about this buried further in the document that perhaps needs to be specified more formally. Most of the document is dependent on this term. [Cheng]Ketan, In the document, the description of the Path Segment is shown below. --------- The term of SR path used in this document is a general term that can be used to describe an SR Policy, a Candidate-Path (CP), or a Segment-List (SL) {{RFC9256}}. Therefore, the PSID may be used to identify an SR Policy, its CP, or a SL terminating on an egress node depending on the use-case. --------- 2) Sec 1: One of the key aspects of SR is that the state is on the SR Source Node and not the destination. I think it is important to cover/say that remains the case for most situations and it is only in very specific cases that this Path Segment and the need to introduce a "per-path" state or awareness may be required at the destination/egress node. [Cheng] How about adding a sentence in the last paragraph of introduction section? __OLD___ Therefore, this document introduces a new segment type that is referred to as the Path Segment. A Path Segment is defined to uniquely identify an SR path in an SR-MPLS network. It MAY be used by the egress nodes for path identification hence to support various use-cases including SR path PM, end-to-end 1+1 SR path protection, and bidirectional SR paths correlation. __NEW__ Therefore, this document introduces a new segment type that is referred to as the Path Segment. A Path Segment is defined to uniquely identify an SR path in an SR-MPLS network. It MAY be used by the egress nodes for path identification hence to support various use-cases including SR path PM, end-to-end 1+1 SR path protection, and bidirectional SR paths correlation. Note that, Per-path states will be maintained in the egress node due to the requirements in these use cases, though in normal cases that the per-path states will be maintained in the ingress node only in the SR architecture. 3) Sec 1: QOUTE However, to support various use-cases in SR-MPLS networks, like end- to-end 1+1 path protection (Live-Live case) [RFC4426], bidirectional path [RFC5654], or Performance Measurement (PM) [RFC7799], the ability to implement path identification on the egress node is a pre- requisite. UNQOUTE It is very difficult to glean out what parts of these references make the assertion for the need for a Path Segment. More specific references to sections along with text that explains why Path Segment is necessary would help. Perhaps that goes into a use-cases or applicability section? [Cheng] No problem, added a reference to the use case sections. 4) Sec 2: QUOTE If the Path Segment is used by an intermediate node to identify a SR path, the SRGB MUST be used. UNQOUTE Is there an assumption that there is no service label (or flow label) following the PSID label? How can an intermediate node know where the PSID label lies in the label stack? [Cheng]First of all, an intermediate node can know the PSID in the top of the label stack in an error(Path Segment is not used for forwarding, so intermediate node should not read it unless it is an error). If it needs to know where is a PSID, it has to scan the label stack I think. Regarding flow label and others, it is irrelevant with PSID. A flow label can be inserted after a PSID, that is fine. 5) Sec 2 QOUTE The term of SR path used in this document is a general term that can be used to describe a SR Policy, a Candidate-Path (CP), or a Segment- List (SL) [RFC9256]. Therefore, the Path Segment may be used to identify an SR Policy, its CP, or a SL terminating on an egress node depending on the use-case. UNQOUTE See my previous comment. Can it be defined more formally? Who determines what the Path Segment is associated with? The egress allocates it but it is used by the ingress by associating with a specific SR Policy or specific Candidate Path or specific Segment List? [Cheng]When PSID is allocated, it can be used for a Segment list, in this case, this PSID identifies a Segment List. A PSID can be allocated for multiple Segment list in the Candidate Path, which means that multiple Segment Lists use the same PSID. In this case, a PSID is associated with a CP. Same logic for SR Policy if you decide to use one PSID in the SR Policy. Egress node and Ingress node will learn the mapping between PSID and SL. The details are described in PCEP/BGP extension drafts. 6) Sec 2 QOUTE When Path Segment is allocated from the SRGB pool, an intermediate node MAY see the Path Segment label at the top of the label stack. UNQOUTE See previous comment and I am not able to understand how intermediate nodes can figure this out. [Cheng] Already addressed in the latest revision, please review the update. 7) Sec 2 QOUTE A Path Segment can be used in the case of Penultimate Hop Popping (PHP), where some labels are be popped off at the penultimate hop of an SR path, but the Path Segment MUST NOT be popped off until it reaches at the egress node. UNQOUTE How or why would the PH pop path segment? Is there any issue with misrouting if the PSID label was exposed at the top of the label stack at other than the egress node? Especially if it is not allocated from the SRGB and is not unique in the domain. [Cheng] I think you misunderstand this text. OR probably, the text is incorrect. I think the meaning is A path segment can be used in the case that the previous label is a PHP label, and Path Segment MUST NOT be popped off until it reaches at the egress node. But the previous label is irrelevant with PSID, so no need to explain more. I prefer to make some modifications shown below: __NEW__ Some labels can be popped off at the penultimate hop of an SR path, but the PSID MUST NOT be popped off until it reaches at the egress node. 8) Sec 2 QOUTE There may be multiple paths (or sub-path(s)) carried in the label stack, for each path (or sub-path), there may be a corresponding Path Segment carried. A use case can be found in Section 4. UNQOUTE Please define what a sub-path is at the beginning of the document. [Cheng] OK, any suggestion? How about adding the below text in Terms section? Sub-Path: A sub-path is a part of the a path, which contains a sub-set of the nodes and links of the path. 9) Sec 4 QOUTE Figure 2 shows the details of the label stacks when PSID and BSID are used to support both sub-path and end-to-end path monitoring in a multi-domain scenario. UNQOUTE What specific monitoring is required/used here when the path is end to end. By using PSID for sub-paths, are we not exposing the issue to many more nodes in the network. In the figure below, has the scalability impact on a mid-point aggregation node B through which a large number of SR Paths may be transiting been considered? Does that not go against the SR paradigm? [Cheng] It depends on the use case. I can say that in some cases, E2E monitoring is needed, then allocates a PSID for the E2E path is good enough. But we can not block people to do anything they want and they need. For example, they may need to know the traffic from ingress to the egress node in different domains respectively, that we can do it by encoding labels. But this is not required for sure. This is not related to SR paradigm, it is only about the need. I won’t say we encourage people to use path segment like that, but it is not prohibited. 😊 10) Sec 6 QOUTE In the current SR architecture, an SR path is a unidirectional path [RFC8402]. In order to support bidirectional SR paths, a straightforward way is to bind two unidirectional SR paths to a single bidirectional SR path. Path Segments can then be used to identify and correlate the traffic for the two unidirectional SR paths at both ends of the bidirectional path. UNQOUTE RFC5654 does not seem to justify the need for a Path Segment for the bidirectional use-case. The computation aspect of bidir paths is already covered and there is no issue there. I don't see the justification for the need of a PSID to be used in the data path. It would help if a description of the use-case about why the egress node needs to know the reverse path context and what it can or may do with it were covered. [Cheng] Well, the egress node must know the path so that it can support APS(Automatic Protection Switching) for Bidiretional path. Therefore the PSID is required for Bidirectional Path. Also, you can see RFC5654 section 2.1, 9 The end points of a co-routed bidirectional transport path MUST be aware of the pairing relationship of the forward and reverse paths used to support the bidirectional service. Egress can know the relationship and perform actions based on PSIDs. 11) Sec 7 QOUTE There then needs to be a method of binding this SR path identifiers into equivalence groups such that the egress node can determine for example, the set of packets that represent a single primary path. It is obvious that this equivalence group can be instantiated in the network by an SDN controller using the Path Segments of the SR paths. UNQOUTE Unlike the other use-cases, there does not seem to be an equivalent description or specification on how this use-case is realized using PSID for SR Policy [Cheng]I think this is not a case of PSID for SR policy. In the case of PSID for SR policy, each CP/SL use the same PSID value. In this case, different PSIDs are allocated to Primary and Secondary path, the egress node will always receive the packets from the Primary path and discard the packets from the secondary path. Therefore, it is required that the egress node knows that from which path the packets come. Minor: a) Please consider shortening the abstract. Right now it is almost mirroring the Introduction. [Cheng]Good suggestion, please see diff. b) Sec 2 QOUTE In addition, adding a Path Segment to a label stack will increase the depth of the label stack, the Path Segment should be accounted when considering Maximum SID Depth (MSD)[RFC8992]. UNQOUTE This is a repetition of text just a few paragraphs above. [Cheng]deleted Thanks, Ketan On Sun, Nov 6, 2022 at 3:48 PM The IESG <iesg-secret...@ietf.org<mailto:iesg-secret...@ietf.org>> wrote: The IESG has received a request from the Source Packet Routing in Networking WG (spring) to consider the following document: - 'Path Segment in MPLS Based Segment Routing Network' <draft-ietf-spring-mpls-path-segment-08.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org<mailto:last-c...@ietf.org> mailing lists by 2022-11-20. Exceptionally, comments may be sent to i...@ietf.org<mailto:i...@ietf.org> instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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 is preserved until it reaches the egress node for SR path identification and correlation. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/5009/ https://datatracker.ietf.org/ipr/3492/ https://datatracker.ietf.org/ipr/3455/ https://datatracker.ietf.org/ipr/5063/ _______________________________________________ IETF-Announce mailing list ietf-annou...@ietf.org<mailto:ietf-annou...@ietf.org> https://www.ietf.org/mailman/listinfo/ietf-announce
draft-ietf-spring-mpls-path-segment-10-00.md
Description: draft-ietf-spring-mpls-path-segment-10-00.md
<<< text/html; name="draft-ietf-spring-mpls-path-segment-10-00.diff.html": Unrecognized >>>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring