Re: [Pce] Adoption Poll for draft-dhodylee-pce-pcep-ls
Thanks, Julien. Once upon a time, I was quite skeptical about this idea, and unhappy to see it progress. But I have become used to the idea, and two things help me believe we should adopt this: 1. As an Experiment, this can be tried out and we can see how well it works. If it is nonsense, no harm done. The authors' willingness to proceed as Experimental is reassuring. 2. The applicability to optical networks (separate draft) is convincing because it is easier to believe that optical devices do not want to add BGP-LS to their code stack (even if it is only a couple of thpusand lines of code). So, I support adoption and commit to working with the authors to improve the draft. I think the current description of the Experiment is pretty good, but work will be needed to sort out the IANA stuff. I just posted a draft to help with Experimental Error-Types. Best, Adrian On 04/04/2024 18:18 CEST julien.meu...@orange.com wrote: Hi all, We have a long history around PCEP-LS. The rough consensus has been to progress it as experimental within the PCE WG, which makes more sense than an independent submission. As a result, do you support draft-dhodylee-pce-pcep-ls-27 [1] to become a PCE WG document? Please share your feedback using the PCE mailing list, including your comments and especially your rationales in case you're opposed. Thank you, Julien --- [1] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] The PCE WG has placed draft-dhodylee-pce-pcep-ls in state "Candidate for WG Adoption"
The PCE WG has placed draft-dhodylee-pce-pcep-ls in state Candidate for WG Adoption (entered by Julien Meuric) The document is available at https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] Adoption Poll for draft-dhodylee-pce-pcep-ls
Hi all, We have a long history around PCEP-LS. The rough consensus has been to progress it as experimental within the PCE WG, which makes more sense than an independent submission. As a result, do you support draft-dhodylee-pce-pcep-ls-27 [1] to become a PCE WG document? Please share your feedback using the PCE mailing list, including your comments and especially your rationales in case you're opposed. Thank you, Julien --- [1] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ smime.p7s Description: S/MIME Cryptographic Signature ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Éric Vyncke's No Objection on draft-ietf-pce-segment-routing-ipv6-24: (with COMMENT)
Thanks Eric and Dhruv for your comments. Please see my reply inline. We also updated the drat accordingly to address your comments, please check, HTML: https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-25.html HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-ipv6 Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-25 Thanks, Cheng From: Dhruv Dhody Sent: Thursday, April 4, 2024 8:14 AM To: Éric Vyncke Cc: The IESG ; draft-ietf-pce-segment-routing-i...@ietf.org; pce-cha...@ietf.org; pce@ietf.org; hariharan.i...@gmail.com; rthal...@gmail.com Subject: Re: Éric Vyncke's No Objection on draft-ietf-pce-segment-routing-ipv6-24: (with COMMENT) Hi Éric, On Thu, Apr 4, 2024 at 12:53 AM Éric Vyncke via Datatracker mailto:nore...@ietf.org>> wrote: Éric Vyncke has entered the following ballot position for draft-ietf-pce-segment-routing-ipv6-24: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-pce-segment-routing-ipv6-23 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Hariharan Ananthakrishnan for the shepherd's write-up including the WG consensus and the justification of the intended status. Other thanks to Bob Halley, the Internet directorate reviewer (at my request): https://datatracker.ietf.org/doc/review-ietf-pce-segment-routing-ipv6-22-intdir-telechat-halley-2024-02-24/ (Bob found no issue) I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Title The title is rather long, should it rather use "IPv6 Segment Routing" [Cheng]Ack ## Abstract Like other IESG members, I find the abstract convoluted, i.e., please be straight to the point and focus on SRv6 and PCEP, e.g., no need to mention LDP in the abstract. [Cheng]Ack. ## Section 1 The second paragraph is rather useless, with another mention of SR-MPLS in a SRv6 document. The 3rd paragraph is not that useful either. 4th and 5th paragraphs could be used during the WG call for adoption, but have little to do in a SRv6-related document. Please really consider to change this section. Dhruv: I see your point for the 2nd and 3rd paragraph. For 4th and 5th, it is important to highlight what is the base set of specifications over which this extension is built. [Cheng]I am ok with deleting the 2nd and 3rd paragraph, though I think they may be helpful for some readers who are not familiar with SR. But it is ok to delete. I am not really sure of the long history in PCE WG, but for most of the RFCs in the WG, they explains the dependent RFCs/Tech in a detailed way, which can help readers to understand the logic and the base of this RFC. I will suggest to keep them. ## Section 2 Consider adding a reference to the SRH RFC. ## Section 3 Is `subobject` term well-defined ? Honestly, I never read this term before and even if I can *guess* the meaning, it may be worth adding it to the terminology section. Dhruv: They go back to the base specification of PCEP in RFC 5440 as well as RSVP-TE in RFC 3209 and thus are well known and understood. One can add this sentence to make it clear - "In PCEP messages,route information is carried in the Explicit Route Object (ERO), which consists of a sequence of subobjects." [Cheng]agree with the modification. ## Section 3.1 I have *very hard* time to understand what is meant by `When SR-MPLS is used with an IPv6 network` to be honest. I was about to ballot a blocking DISCUSS on this point, but I assume that I simply lack the PCEP context. May I ***REQUEST*** some explanations here ? Dhruv: I suggested that text based on Jim's comment. Maybe you can help with wordsmithing this :) In an IPv6-only network that uses SR-MPLS, the SR related information in the IGP/BGP will use an IPv6 address and the data-plane would use MPLS. In this case, for PCEP the RFC 8664 (SR-MPLS extension) is sufficient and there is no role of SRv6 here. Would the term "IPv6-enabled networks (IPv6-only or Dual-stack networks)" be better? [Cheng]Though I know what you are saying here, but I will rather remove this paragraph, because it is not so needed at all. Regarding using SR-MPLS in an IPv6
[Pce] I-D Action: draft-ietf-pce-segment-routing-ipv6-25.txt
Internet-Draft draft-ietf-pce-segment-routing-ipv6-25.txt is now available. It is a work item of the Path Computation Element (PCE) WG of the IETF. Title: Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing Authors: Cheng Li(Editor) Prejeeth Kaladharan Siva Sivabalan Mike Koldychev Yongqing Zhu Name:draft-ietf-pce-segment-routing-ipv6-25.txt Pages: 28 Dates: 2024-04-04 Abstract: Segment Routing (SR) can be used to steer packets through a network using the IPv6 or MPLS data plane, employing the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element(PCE). Since SR can be applied to both MPLS and IPv6 data-planes, a PCE should be able to compute an SR Path for both MPLS and IPv6 data- planes. The Path Computation Element communication Protocol (PCEP) extension and mechanisms to support SR-MPLS have been defined. This document outlines the necessary extensions to support SR for the IPv6 data-plane within PCEP. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-ipv6-25.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-ipv6-25 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Éric Vyncke's No Objection on draft-ietf-pce-segment-routing-ipv6-24: (with COMMENT)
Hi Éric, On Thu, Apr 4, 2024 at 12:53 AM Éric Vyncke via Datatracker < nore...@ietf.org> wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-pce-segment-routing-ipv6-24: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/ > > > > -- > COMMENT: > -- > > > # Éric Vyncke, INT AD, comments for draft-ietf-pce-segment-routing-ipv6-23 > > Thank you for the work put into this document. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education), and some nits. > > Special thanks to Hariharan Ananthakrishnan for the shepherd's write-up > including the WG consensus and the justification of the intended status. > > Other thanks to Bob Halley, the Internet directorate reviewer (at my > request): > > https://datatracker.ietf.org/doc/review-ietf-pce-segment-routing-ipv6-22-intdir-telechat-halley-2024-02-24/ > (Bob found no issue) > > I hope that this review helps to improve the document, > > Regards, > > -éric > > # COMMENTS (non-blocking) > > ## Title > > The title is rather long, should it rather use "IPv6 Segment Routing" > > ## Abstract > > Like other IESG members, I find the abstract convoluted, i.e., please be > straight to the point and focus on SRv6 and PCEP, e.g., no need to mention > LDP > in the abstract. > > ## Section 1 > > The second paragraph is rather useless, with another mention of SR-MPLS in > a > SRv6 document. The 3rd paragraph is not that useful either. > > 4th and 5th paragraphs could be used during the WG call for adoption, but > have > little to do in a SRv6-related document. Please really consider to change > this > section. > > Dhruv: I see your point for the 2nd and 3rd paragraph. For 4th and 5th, it is important to highlight what is the base set of specifications over which this extension is built. > ## Section 2 > > Consider adding a reference to the SRH RFC. > > ## Section 3 > > Is `subobject` term well-defined ? Honestly, I never read this term before > and > even if I can *guess* the meaning, it may be worth adding it to the > terminology > section. > > Dhruv: They go back to the base specification of PCEP in RFC 5440 as well as RSVP-TE in RFC 3209 and thus are well known and understood. One can add this sentence to make it clear - "In PCEP messages,route information is carried in the Explicit Route Object (ERO), which consists of a sequence of subobjects." > ## Section 3.1 > > I have *very hard* time to understand what is meant by `When SR-MPLS is > used > with an IPv6 network` to be honest. I was about to ballot a blocking > DISCUSS on > this point, but I assume that I simply lack the PCEP context. May I > ***REQUEST*** some explanations here ? > > Dhruv: I suggested that text based on Jim's comment. Maybe you can help with wordsmithing this :) In an IPv6-only network that uses SR-MPLS, the SR related information in the IGP/BGP will use an IPv6 address and the data-plane would use MPLS. In this case, for PCEP the RFC 8664 (SR-MPLS extension) is sufficient and there is no role of SRv6 here. Would the term "IPv6-enabled networks (IPv6-only or Dual-stack networks)" be better? > ## Section 4.1.1 > > Is there a reason why the only defined bit in the flag field it not the > rightmost one ? > > Dhruv: There used to be another flag "X" that we removed later on. Implementers preferred not to move the N flag from its current position. > Please mention the position of the N bit (bit 30 from picture but let's be > crystal clear). > > Is it common for PCEP communication to use the term TLV where the Length > is not > actually the field length ? How can a non SRv6 capable PCEP speakers will > parse/skip this TLV without prior knowledge of the 4-octet alignment ? > > Dhruv: The (MSD-Type,MSD-Value) are not called TLV, they are a part of the value portion of SRv6-PCE-CAPABILITY sub-TLV. The SRv6-PCE-CAPABILITY has type (27) and a length field and follows the TLV format. The length field will indicate how many pairs of (MSD-Type,MSD-Value) are included. Am I misunderstanding your comment? > ## Section 4.3.1 > > No need to reply, but the encoding of TLV object is really weird again as > it > starts with an important flag and the length is now only 1 octet. > > Dhruv: This is not a TLV but a subobject. They follows the standard subobject encoding that PCEP inherited from RSVP-TE -
