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. > > 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. > > [Dhruv]: Two things - (1) You changed "it MUST behave as per the processing rule in [RFC8231]." to "it MUST ignore the flags as per the processing rule in [RFC8231]."; I suggest removing "as per the processing rule in [RFC8231]", as it is not coming from RFC 8231. (2) Consider adding my suggested text above. Feel free to rephrase but the ambiguity reason cited is a key motivation for this document and it should not be lost. Thanks! Dhruv
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
