Hi Mahesh, Updated accordingly, please check: https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-stateful-pce-optional-12&url2=draft-ietf-pce-stateful-pce-optional-13&difftype=--html
Thanks, Cheng -----Original Message----- From: Mahesh Jethanandani <mjethanand...@gmail.com> Sent: Wednesday, November 27, 2024 4:14 AM To: Cheng Li <c...@huawei.com> Cc: Dhruv Dhody <d...@dhruvdhody.com>; The IESG <i...@ietf.org>; draft-ietf-pce-stateful-pce-optio...@ietf.org; pce-cha...@ietf.org; pce@ietf.org Subject: Re: [Pce] Mahesh Jethanandani's No Objection on draft-ietf-pce-stateful-pce-optional-10: (with COMMENT) HI Cheng, I prefer the NEW text that Dhruv has proposed. Cheers. > On Nov 26, 2024, at 5:51 AM, Cheng Li <c...@huawei.com> wrote: > > Hell Dhruv and Mahesh, > > I rephrase the text 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. [RFC8231] only states that P and I > flags of the PCEP objects defined in [RFC8231] are set to 0 on transmission > and ignored on receipt, while it does not describe the behaviour of objects > defined outside of [RFC8231], which brings ambiguity to the PCEP > implementation. > ” > > Please see the diff: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-stateful-pce- > optional-12 > > > Thanks, > Cheng > > > -----Original Message----- > From: Dhruv Dhody <d...@dhruvdhody.com> > Sent: Tuesday, November 26, 2024 5:17 AM > To: Mahesh Jethanandani <mjethanand...@gmail.com> > Cc: Cheng Li <c...@huawei.com>; The IESG <i...@ietf.org>; > draft-ietf-pce-stateful-pce-optio...@ietf.org; pce-cha...@ietf.org; > pce@ietf.org > Subject: Re: [Pce] Mahesh Jethanandani's No Objection on > draft-ietf-pce-stateful-pce-optional-10: (with COMMENT) > > Hi Cheng and Mahesh, > > >> >> 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 >> >> >> >> >> >> 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 Mahesh Jethanandani mjethanand...@gmail.com _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
