Seems the email is cut due to some reasons ☹ I will update the draft to address Gunter's email. Please check @Gunter Van de Velde
Thanks, Cheng -----Original Message----- From: Cheng Li <c.l=40huawei....@dmarc.ietf.org> Sent: Wednesday, April 3, 2024 12:00 PM To: Dhruv Dhody <d...@dhruvdhody.com>; Gunter Van de Velde <gunter.van_de_ve...@nokia.com> Cc: The IESG <i...@ietf.org>; draft-ietf-pce-segment-routing-i...@ietf.org; pce-cha...@ietf.org; pce@ietf.org; hariharan.i...@gmail.com Subject: RE: Gunter Van de Velde's No Objection on draft-ietf-pce-segment-routing-ipv6-22: (with COMMENT) Hi Dhruv, and Gunter, Thank you for your comments. Please see my reply inline, will update the draft accordingly soon. Thanks, Cheng -----Original Message----- From: Dhruv Dhody <d...@dhruvdhody.com> Sent: Wednesday, April 3, 2024 11:41 AM To: Gunter Van de Velde <gunter.van_de_ve...@nokia.com> Cc: The IESG <i...@ietf.org>; draft-ietf-pce-segment-routing-i...@ietf.org; pce-cha...@ietf.org; pce@ietf.org; hariharan.i...@gmail.com Subject: Re: Gunter Van de Velde's No Objection on draft-ietf-pce-segment-routing-ipv6-22: (with COMMENT) Hi Gunter, Thanks for a detailed review. On Tue, Apr 2, 2024 at 10:49 PM Gunter Van de Velde via Datatracker < nore...@ietf.org> wrote: > Gunter Van de Velde has entered the following ballot position for > draft-ietf-pce-segment-routing-ipv6-22: 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-posi > tions/ 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: > ---------------------------------------------------------------------- > > Please find this review using a fresh pair of eyes upon the draft. > feel free to use or ignore these comments. Comments are ordered with > some first set of idnit typo's, followed with observations when > reading the document. > > **Idnits:** > > 349 Endpoint node as well as the tailend node also need to be > considered > > I believe that the grammatically correct form is "tail-end," which > refers to the final part of something, such as a process, activity, or > physical object. > Using a hyphen clarifies that the two words function together as a > single concept. Not sure if there is earlier art that uses the term > with the proposed spelling in the document? > > Dhruv: I checked; authors - please change to tail-end! [Cheng]Ack, no problem. > 659 PCE. As such,the flags MUST be set to zero and a (MSD-Type,MSD- > > s/such,the/such, the/ > > 635 mechanisms, e.g routing protocols [RFC9352], then it ignores the > > s/e.g/e.g./ > > 653 SRv6 MSD capabilties, the PCC MUST send a PCErr message with > Error- > > s/capabilties/capabilities/ > > Dhruv: Ack for above! [Cheng]Ack. > **Observations when reading through the document:** > > 20 Segment Routing (SR) can be used to steer packets through an > IPv6 or > 21 MPLS network using the source routing paradigm. SR enables any > head- > 22 end node to select any path without relying on a hop-by-hop > signaling > 23 technique (e.g., LDP or RSVP-TE). > > Proposed rewrite > Segment Routing (SR) can be used to steer packets through a network > using the > IPv6 or MPLS data plane, employing the source routing paradigm. SR > enables any head-end node to select any path without relying on > hop-by-hop signaling techniques (e.g., LDP or RSVP-TE). > > Dhruv: Thanks for the rewrite, it reads better! [Cheng] No problem > 29 Since SR can be applied to both MPLS and IPv6 forwarding > planes, a > 30 PCE should be able to compute an SR Path for both MPLS and IPv6 > 31 forwarding planes. > > I suspect we are talking dataplane instead of forwarding plane? I see > the terms "forwarding plane" and "data plane" often used > interchangeably, but they do seem to have nuanced differences. The > forwarding plane deals with the logical decision-making process of > packet forwarding, the data plane deals with the physical > implementation of forwarding those packets based on those decisions. > In addition the term dataplane is used later in this same abstract. > Maybe best to use single terminology (maybe dataplane) through the > document? > > Dhruv: Looking at spring RFCs I see a mix of terms but when talking about SR instantiation as SR-MPLS and SRv6, the term data-plane is used and thus we should also use the same. [Cheng]Ack > 31 forwarding planes. The PCEP extension and mechanisms to > support SR- > 32 MPLS have been defined. > > What about adding the reference to RFC5440? > Dhruv: I would avoid adding references in the abstract. [Cheng]I agree with Dhruv of this > > 32 MPLS have been defined. This document describes the extensions > 33 required for SR support for the IPv6 data plane in the Path > 34 Computation Element communication Protocol (PCEP). > > This text reads a bit odd. What about a readability rewrite: > “This document outlines the necessary extensions to support Segment > Routing > (SR) for the IPv6 data plane within the Path Computation Element > Communication Protocol (PCEP).” > > Dhruv: Ack, with slight modification as the whole para can be read as - "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." [Cheng]Will update and double-check with Gunter. > 126 When the SR architecture is applied to the MPLS forwarding > plane, it > 127 is called SR-MPLS. When the SR architecture is applied to the > IPv6 > 128 data plane, is is called SRv6 (Segment Routing over IPv6 data > plane) > 129 [RFC8754]. > > See earlier comments. Data plane vs forwarding plane. > > 133 IGP SPT. Such paths may be chosen by a suitable network > planning > 134 tool, or a PCE and provisioned on the ingress node. > > The correlation between PCE and suitable network planning tool is > unclear [Cheng]Ack. _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
