Hi Cheng/Dhruv, Responding to both your e-mails. See inline with [mj]
> On Nov 25, 2024, at 7:54 AM, Cheng Li <c...@huawei.com> wrote: > > Hi Mahesh, > > Thank you for your comments, please see my reply in-line. > Also, please see the diff: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-stateful-pce-optional-11 > > <https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-stateful-pce-optional-11>, > please check if the update is OK for you. > > Thanks, > Cheng > > From: Dhruv Dhody <d...@dhruvdhody.com <mailto:d...@dhruvdhody.com>> > Sent: Monday, November 18, 2024 10:54 AM > To: Mahesh Jethanandani <mjethanand...@gmail.com > <mailto:mjethanand...@gmail.com>> > Cc: The IESG <i...@ietf.org <mailto:i...@ietf.org>>; > draft-ietf-pce-stateful-pce-optio...@ietf.org > <mailto:draft-ietf-pce-stateful-pce-optio...@ietf.org>; pce-cha...@ietf.org > <mailto:pce-cha...@ietf.org>; pce@ietf.org <mailto:pce@ietf.org> > Subject: [Pce] Re: Mahesh Jethanandani's No Objection on > draft-ietf-pce-stateful-pce-optional-10: (with COMMENT) > > Hi Mahesh, > > On Sun, Nov 17, 2024 at 8:20 PM Mahesh Jethanandani via Datatracker > <nore...@ietf.org <mailto:nore...@ietf.org>> wrote: > Mahesh Jethanandani has entered the following ballot position for > draft-ietf-pce-stateful-pce-optional-10: 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/ > <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-stateful-pce-optional/ > <https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-optional/> > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "Abstract", paragraph 0 > > Abstract > > The shepherd's write-up was done in 2022. Has there been no change in the > document since then that would require an update to the writeup? > > > Dhruv: The datatracker says that the shepherd write up was "Last changed > 2024-04-16". > I am guessing you are looking at "*This version is dated 4 July 2022.*" in > the writeup itself, which is the date for the template - > https://datatracker.ietf.org/doc/shepherdwriteup-template/individual > <https://datatracker.ietf.org/doc/shepherdwriteup-template/individual> [mj] You are right. I was looking at the date when the template was updated. Regardless, it should have been removed, but that is a matter for another day. > > Section 1, paragraph 3 > > [RFC5440] defined the P flag (Processing-Rule) in the Common Object > > Header to allow a PCC to specify in a Path Computation Request > > (PCReq) message (sent to a PCE) whether the object must be taken into > > account by the PCE during path computation or is optional. The I > > flag (Ignore) is used by the PCE in a Path Computation Reply (PCRep) > > message to indicate to a PCC whether or not an optional object was > > considered by the PCE during path computation. Stateful PCE > > [RFC8231] specified that the P and I flags of the PCEP objects > > defined in [RFC8231] is to be set to zero on transmission and ignored > > on receipt, since they are exclusively related to the path > > computation requests. The behaviour for P and I flag in other > > messages defined in [RFC5440] and other extension was not specified. > > This document specifies how the P and I flag could be used in the > > stateful PCE model to identify optional objects in the Path > > Computation State Report (PCRpt) [RFC8231], the Path Computation > > Update Request (PCUpd) [RFC8231], and the LSP Initiate Request > > (PCInitiate) [RFC8281] message. > > I would have imagined that this would be a good place to RE: John Scudder's > No Objection on draft-ietf-pce-stateful-pce-optional-10: (with COMMENT) > introduce the fact > that the document is trying to define a new flag (R) in this document. > > > Dhruv: I was okay with the current text as the R flag is doing more of a > support role whereas P and I flag usage is the star. But I will let authors > take a call on this. > [Cheng]Let’s add a sentence to state that this document defines a new R flag. > That makes sense to me. [mj] Ok. I look forward to the update. > > > Section 3.1, paragraph 3 > > The R flag MUST be set by both PCC and PCE to indicate support for > > the handling of the P and I flag in the PCEP common object header to > > allow relaxing some constraints by marking objects as 'optional to > > process'. If the PCEP speaker did not set the R flag but receives > > PCEP objects with P or I bit set, it MUST behave as per the > > processing rule in [RFC8231]. Note that while [RFC8231] stated that > > P and I flags of the PCEP objects defined in [RFC8231] are set to 0 > > on transmission and ignored on receipt, it did not say anything about > > already existing PCEP objects and thus the behaviour remained > > undefined. To safely use this feature, both peers need to set the R > > flag. > > It is unclear from this paragraph what it means when it states that "it did > not > say anything about already existing PCEP objects". Already existing PCEP > objects that have the P and I flags set to 1?? It appears that the behavior of > when it is set to 0 is known, so it would seem that we are talking about when > the value is not set to 0. Can this be made clear? > > > Dhruv: This is the relevant text from RFC 8231 - > https://datatracker.ietf.org/doc/html/rfc8231#section-7 > <https://datatracker.ietf.org/doc/html/rfc8231#section-7> > > > > > The P and I flags of the PCEP > objects defined in the current document MUST be set to 0 on > transmission and SHOULD be ignored on receipt since they are > exclusively related to path computation requests. > > where it says "objects defined in the current document". To make it clear, I > propose the following change - > > OLD: > Note that while [RFC8231] stated that > P and I flags of the PCEP objects defined in [RFC8231] are set to 0 > on transmission and ignored on receipt, it did not say anything about > already existing PCEP objects and thus the behaviour remained > undefined. > NEW: > [RFC8231] stated that P and I flags of the PCEP objects defined in > [RFC8231] > are set to 0 on transmission and ignored on receipt. It failed to mention > the > behaviour of objects defined outside of [RFC8231] leading to ambiguity. > END > > [Cheng] I prefer to delete the text of “note that ….”, instead, let’s change > the previous sentence to > > “If the PCEP speaker did not set the R flag but receives PCEP objects with P > or I bit set, it MUST ignore the flags as per the > processing rule in [RFC8231].” > > Though the original text says SHOULD, but under the situation of MUST set as > 0 when sending. I tend to make it as MUST ignore. Thoughts? [mj] A MUST would be more clear. With a SHOULD you would have to describe what happens if it does not ignore the flags. > > > > Section 7, paragraph 0 > > 7. Manageability Considerations > > It is great to see that this document has a separate manageability > consideration section called out. > > Section 7.2, paragraph 0 > > An implementation supporting this document SHOULD allow the operator > > to view the capability defined in this document. To serve this > > purpose, the PCEP YANG module [I-D.ietf-pce-pcep-yang] could be > > extended in the future. > > Is this captured in the charter as a milestone, or in a draft that is being > considered by the WG? > > > Dhruv: When the WG will embark on an update to the PCEP YANG, we will be > going through the manageability consideration of all our RFCs to make sure we > meet the requirements set aside. Since all PCEP RFCs have this section, this > is how we plan to track this. > [Cheng]I am ok with current text here. [mj] Ok. Thanks. > > > Thanks! > Dhruv (as a document shepherd) > > > ------------------------------------------------------------------------------- > NIT > ------------------------------------------------------------------------------- > > All comments below are about very minor potential issues that you may choose > to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool > <https://github.com/larseggert/ietf-reviewtool>), so there > will likely be some false positives. There is no need to let me know what you > did with these suggestions. > > Section 3.3.2, paragraph 1 > > g in the common object header in a similar way as [RFC5440], i.e. if a PCEP > > ^^^^^^^^^^^^^^^^ > Consider replacing this phrase with the adverb "similarly" to avoid wordiness. > > > > [Cheng]Thanks, let’s leave this to RFC editors, they are experts on this😊 > > > Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
