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 - https://datatracker.ietf.org/doc/html/rfc3209#section-4.3.3 > Isn't it weird that S&V flags indicate an absence and T flag a presence ? > > Dhruv: We borrowed the S and F flag from RFC 8664. I guess we could have kept them uniform :( but it's late to make a change now. > Should there be a reference to the IANA registry already here ? > > ## Section 4.3.1.2 > > `The presence of each of them ` should probably be "presence or absence" > cfr my > comment above. > > Dhruv: Agree. Thanks! Dhruv
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
