Thanks a lot for review, Eric. Please see inline <S>.
Thanks, Samuel From: Eric Vyncke (evyncke) <evyn...@cisco.com> Sent: Wednesday, April 2, 2025 10:25 AM To: mohamed.boucad...@orange.com; The IESG <i...@ietf.org> Cc: draft-ietf-pce-segment-routing-policy...@ietf.org; pce-cha...@ietf.org; pce@ietf.org; d...@dhruvdhody.com Subject: Re: Éric Vyncke's Discuss on draft-ietf-pce-segment-routing-policy-cp-25: (with DISCUSS and COMMENT) Bonjour Med, You are correct and I stand corrected for the length field being 16 bits... too early in the morning for me ;-) Regards -éric From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Date: Wednesday, 2 April 2025 at 10:16 To: Eric Vyncke (evyncke) <evyn...@cisco.com<mailto:evyn...@cisco.com>>, The IESG <i...@ietf.org<mailto:i...@ietf.org>> Cc: draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org> <draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>>, pce-cha...@ietf.org<mailto:pce-cha...@ietf.org> <pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>>, pce@ietf.org<mailto:pce@ietf.org> <pce@ietf.org<mailto:pce@ietf.org>>, d...@dhruvdhody.com<mailto:d...@dhruvdhody.com> <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>> Subject: RE: Éric Vyncke's Discuss on draft-ietf-pce-segment-routing-policy-cp-25: (with DISCUSS and COMMENT) Salut Éric, Regarding: > > ### Sections 4.2.1 & 4.2.3 > > `It is RECOMMENDED that the size of the symbolic name for the SR > Policy is > limited to 255 bytes. ` why only "RECOMMENDED" when the Length > field can only > indicate 255 maximum ? Suggest using MUST rather RECOMMENDED here. The length field is 16 bits. I actually asked to have that text in the spec and ensure that we are consistent with https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-safi/13/. I suggest we keep the current wording. Thanks. Cheers, Med > -----Message d'origine----- > De : Éric Vyncke via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> > Envoyé : mercredi 2 avril 2025 09:44 > À : The IESG <i...@ietf.org<mailto:i...@ietf.org>> > Cc : > draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>; > pce- > cha...@ietf.org<mailto:cha...@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>; > d...@dhruvdhody.com<mailto:d...@dhruvdhody.com> > Objet : Éric Vyncke's Discuss on draft-ietf-pce-segment-routing- > policy-cp-25: (with DISCUSS and COMMENT) > > > Éric Vyncke has entered the following ballot position for > draft-ietf-pce-segment-routing-policy-cp-25: Discuss > > 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.) > > > ------------------------------------------------------------------ > DISCUSS: > ------------------------------------------------------------------ > > > # Éric Vyncke, INT AD, comments for draft-ietf-pce-segment- > routing-policy-cp-25 > CC @evyncke > > Thank you for the work put into this document. > > Please find below some blocking DISCUSS points (easy to address), > some > non-blocking COMMENT points (but replies would be appreciated even > if only for > my own education), and some nits. > > Special thanks to Dhruv Dhody for the shepherd's write-up > including the WG > consensus, some justification for 6 authors, and the justification > of the > intended status. > > I hope that this review helps to improve the document, > > Regards, > > -éric > > ## DISCUSS (blocking) > > > ### Section 3 > > This section appears to be only about SR-MPLS, i.e., conflicting > with the > abstract, which explicitly includes SRv6, and the title, which > does not mention > any restriction to SR-MPLS only. Either add some SRv6 text (my > preference) or > restrict the I-D to SR-MPLS only. <S> Section is talking about both - SR-MPLS and SRv6. Ketan raised comment in other mail thread that usage of LSP with SRv6 may really cause confusion, so we can introduce something similar as used in RFC9603: Further, note that the term "LSP" used in the PCEP specifications would be equivalent to an SRv6 path (represented as a list of SRv6 segments) in the context of supporting SRv6 in PCEP. > > ### Section 4.1 > > Let's remove any ambiguity and specify the units (octets I guess) > and the field > coverage (color + endpoint I guess) for the Length field. <S> Agreed, I'll change it. > > ### Sections 4.2.1 & 4.2.3 > > `It is RECOMMENDED that the size of the symbolic name for the SR > Policy is > limited to 255 bytes. ` why only "RECOMMENDED" when the Length > field can only > indicate 255 maximum ? Suggest using MUST rather RECOMMENDED here. <S> Already responded by Med, but there is typo as that statement is talking about "symbolic name", but it should be talking about SR Policy or candidate-path name. > > > ------------------------------------------------------------------ > ---- > COMMENT: > ------------------------------------------------------------------ > ---- > > > ## COMMENTS (non-blocking) > > ### Are RFC 8986 policies included ? > > This document does not seem to include RFC 8986 (network > programming) policies > as it only talks about "paths". The document should be clear > whether it > supports RFC 8986 and, if so, amend the text about "paths". > <S> Support for SRv6 policies in PCEP is introduced in RFC9603 and the draft is already referring to that one, but we can still add clarification for "LSP" in SRv6 context as mentioned above. > ### Abstract > > Suggest deleting `called a headend node` as it brings no value > there. > <S> I'll delete it. > ### Section 1 > > s/Path Setup Type 1 (Segment Routing) /Path Setup Type 1 (SR-MPLS) > / ? (and > possibly other places, let's remove any ambiguity) > <S> Path Setup Type value is not using SR-MPLS, but Segment-routing, see for example: https://datatracker.ietf.org/doc/html/rfc8664#name-new-path-setup-type or https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-path-setup-types So by referring to SR-MPLS Path Setup Type we would actually introduce ambiguity as such Path Setup Type does not exist. > ### Sections 4.2.1 and 4.2.3 > > `Padding is not included in the Length field.` do PCEP receivers > know how to > handle a Length that does not really represent the length of the > TLV ? > <S> It would be really better to be aligned with: https://www.ietf.org/rfc/rfc8231.html#section-7.3.2 So length will represent "indicates the total length of the TLV". I'll make it clear. > ### Section 11.2 > > RFC20 should be normative. > > ## NITS (non-blocking / cosmetic) > > ### Section 1 > > Consider using lower case for `Establishing Relationships Between > Sets` > > ### Section 5.1 > > Please use balanced quotes in `Type: 71 for "SRPOLICY-CAPABILITY > TLV` > > ### Use of SVG graphics > > To make a much nicer HTML rendering, suggest using the aasvg too > to generate > SVG graphics. It is worth a try ;-) > > <S> Ack, for comments. ____________________________________________________________________________________________________________ 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.
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
