|
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.ietf@xxxxxxxxx>
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__ 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- UNQOUTE [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 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 [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 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 [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 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 UNQOUTE [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 UNQOUTE RFC5654 does not seem to justify the need for a Path Segment for the bidirectional use-case. The computation aspect of bidir paths [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，
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 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 [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 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-secretary@xxxxxxxx> wrote:
|
Attachment:
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 >>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
