Hi Andrew,Thanks for the detailed response. In other word, the case L=0/E=0 is purposely loose, whereas L=1/E=0 is where the document really updates RFC 5440 (E=1 being rather an extension). That's consistent with the problem statement.
Thank you for the update, I'll now prepare the proto write-up. Julien On 08/08/2022 21:13, Stone, Andrew (Nokia - CA/Ottawa) wrote:
Hi Julien, PCE WG New version -07[1] has been posted to address the review feedback. Thanks once again for the review and Shepherding this."Any reason why the case above doesn't include the legacy situation, similarly to the case below (i.e. "but MAY consider protection eligibility as a PROTECTION MANDATORY constraint")?"Good question. At the time of the original text the core intention was to clear up interop behavior differences when L=1, in addition to introducing the E flag as the strictness toggle, as that was key impacting interop problem. In other words, the E=1 specifically was to influence the behavior when L=1 or when L=0, and introduce strong enforcement when E=1. When L=0, E=0, the significance on interop and implementation isn't as impacting. If we allow backwards compatibility of L=1, E=0, by permitting "protection mandatory", that would continue to result in different interop implementations of (L=1) which is something the core of the document wanted to correct. The text on L=0, E=0 is trying to play nice with existing known implementations, since the impact in that scenario (the resulting path calculation) wasn't significant. Essentially it's a flag combination which is considered okay to provide backwards interop for in the text. Thanks Andrew [1] https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-local-protection-enforcement-07.txt On 2022-08-04, 6:06 AM, "Pce on behalf of julien.meu...@orange.com" <pce-boun...@ietf.org on behalf of julien.meu...@orange.com> wrote: Hi authors of draft-ietf-pce-local-protection-enforcement, I'm the shepherd of the aforementioned document. The problem statement is well described and the solution defined is clear. The I-D is almost ready to progress but has minor issues that need to be addressed before sending to the IESG. _From idnits:_ - The abstract should avoid using references, i.e. you may replace "[RFC5440]" by a phrase like "the base specification". - RFC 4655 is used as a normative document, though not mandatory to implement the I-D: moving it into informative reference section would not only reflect this, but would also avoid the downref. _From my reading:_ - The page header just mentions "I-D": a short title is expected there. - Even if "PCEP" has become a name for the protocol, which leads to dropping "a"/"the", the acronym "PCE" is usually used as a shortcut for the full phrase, thus one expects to see it prefixed by "a"/"the" (cf. "BGP" vs. "the IGP"). I've caught several of these below but probably missed some. - Abstract OLD: This document updates [RFC5440] to clarify usage of the local protection desired bit signalled in Path Computation Element Protocol (PCEP). NEW: This document extends the base specification to clarify the usage of the local protection desired bit signalled in the Path Computation Element Communication Protocol (PCEP). - Introduction s/Path Computation Element (PCE) Communication Protocol (PCEP)/The Path Computation Element (PCE) Communication Protocol (PCEP)/ s/Path Control Element/Path Computation Element/ [or just the acronym, since already expanded in the 1st line] NEW: this flag signals to downstream routers that local protection is desired, which indicates to transit routers that they may use a local repair mechanism. OLD: this flag signals to downstream routers that they may use a local repair mechanism. s/it's calculation/its calculation/ s/advertised into IGP/advertised into the IGP/ s/and for a given adjacency between two routers there may be/and, for a given adjacency between two routers, there may be/ s/calculated by PCE/calculated by a PCE/ s/discovered by PCE/discovered by the PCE/ - Section 3 s/...: path/...: The Path/ [x4] - Section 4 s/example,UNPROTECTED/example, UNPROTECTED/ s/by PCE/by the PCE/ s/for PCE/for the PCE/ s/traffic engineered secondary path/traffic-engineered secondary path/ s/to instruction PCE/to instruct the PCE/ - Section 5 s/When set/When set to 1/ s/When not set/When set to 0/ s/which PCE/which the PCE/ s/When set/When set to 1/ s/by PCE/by the PCE/ s/When E flag is not set/When the E flag is set to 0/ s/however PCE/however the PCE/ s/ignore L flag/ignore the L flag/ s/when E flag is unset/when the E flag is set to 0/ s/When L flag is set and E flag is set then PCE/When both the L flag and the E flag are set to 1, then the PCE/ s/as PROTECTION MANDATORY constraint/as a PROTECTION MANDATORY constraint/ s/When L flag is set and E flag is not set then PCE/When the L flag is set to 1 and the E flag is set to 0, then the PCE/ s/as PROTECTION PREFERRED constraint/as a PROTECTION PREFERRED constraint/ Any reason why the case above doesn't include the legacy situation, similarly to the case below (i.e. "but MAY consider protection eligibility as a PROTECTION MANDATORY constraint")? s/When L flag is not set and E flag is not set then PCE/When both the L flag and the E flag are set to 0, then the PCE/ s/as UNPROTECTED MANDATORY constraint/as an UNPROTECTED MANDATORY constraint/ s/When L flag is not set and E flag is set then PCE/When the L flag is set to 0 and the E flag is set to 1, then the PCE/ s/as UNPROTECTED MANDATORY constraint/as an UNPROTECTED MANDATORY constraint/ - section 5.1 To make paragraphs consistent between the 1st and the 2nd half of the section, it seems to me that line breaks at current lines 315 and 320 would be appropriate. s/between PCC and PCE for the E flag bit which/between the PCC and the PCE for the E flag which/ s/requirements for PCE and PCC/requirements for the PCE and the PCC/ s/the E flag bit is/the E flag is/ s/per ([RFC8281])/per [RFC8281]/ s/It's important/It is important/ s/permit LSP Attribute Object/permit the LSP Attribute Object/ s/PCUpd E flag (and L flag) are an echo/the PCUpd E flag (and L flag) is an echo/ s/on PCE/on the PCE/ s/with the E flag unset/with the E flag set to 0/ s/even if set in/even if set to 1 in/ s/with the E flag unset/with the E flag set to 0/ s/even if set in/even if set to 1 in/ s/MAY set E flag bit/MAY set the E flag to 1/ s/ignore the E flag bit thus/ignore the E flag, thus/ s/PCC SHOULD/the PCC SHOULD/ s/from PCE/from the PCE/ s/PCC MAY/the PCC MAY/ s/from PCE/from the PCE/ s/PCE SHOULD/The PCE SHOULD/ s/from PCC/from the PCC/ --- Cheers, Julien
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
