Hi Bruno/All, The v11 of the draft posted by the authors addressed my concerns/comments.
Thanks, Ketan On Wed, Aug 2, 2023 at 10:30 PM <bruno.decra...@orange.com> wrote: > Hi Ketan, > > > > You may not have seen the reply from Mach, especially since for some > reason, you don’t seem to be in the recipient list… > > > > Does the reply address your comments or do you want to follow up? > > > > If the latter, you may want to read and refer to latest version as there > has been to modification since then. > > https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment > > > > Thanks again for your review and comments. > > > > Thanks, > > --Bruno > > > > > > Orange Restricted > > *From:* spring <spring-boun...@ietf.org> *On Behalf Of *Cheng Li > *Sent:* Wednesday, July 5, 2023 9:57 AM > *To:* Mach Chen <mach.c...@huawei.com>; > draft-ietf-spring-mpls-path-segm...@ietf.org > *Cc:* ietf-annou...@ietf.org; andrew-i...@liquid.tech; > james.n.guich...@futurewei.com; spring-cha...@ietf.org; spring@ietf.org; > last-c...@ietf.org; Pengshuping (Peng Shuping) <pengshup...@huawei.com> > *Subject:* Re: [spring] Last Call: > <draft-ietf-spring-mpls-path-segment-08.txt> (Path Segment in MPLS Based > Segment Routing Network) to Proposed Standard > > > > 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> > *Sent:* Monday, November 28, 2022 3:39 PM > *To:* last-c...@ietf.org > *Cc:* IETF-Announce <ietf-annou...@ietf.org>; andrew-i...@liquid.tech; > draft-ietf-spring-mpls-path-segm...@ietf.org; > james.n.guich...@futurewei.com; spring-cha...@ietf.org; 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> 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 mailing lists by 2022-11-20. Exceptionally, comments > may > be sent to 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 > https://www.ietf.org/mailman/listinfo/ietf-announce > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
