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 _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
