Re: [Pce] Shepherd's Review of draft-ietf-pce-local-protection-enforcement-06
Hi Julien, Thanks for following up on that. Noted, and will do on next revision when it comes up. Thanks! Andrew On 2022-08-11, 5:46 AM, "julien.meu...@orange.com" wrote: Hi Andrew, After talking with Robert Sparks about Idnits analysis, the best way to address the error below while pleasing the IESG was to say in the abstract "This document updates RFC 5440", without square brackets to avoid creating a reference. No need to trigger an update at this stage, but it would be nice to include that change in the next revision down the road. Thanks, Julien On 04/08/2022 12:05, julien.meu...@orange.com wrote: > _From idnits:_ > > - The abstract should avoid using references, i.e. you may replace > "[RFC5440]" by a phrase like "the base specification". ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Shepherd's Review of draft-ietf-pce-local-protection-enforcement-06
Hi Andrew, After talking with Robert Sparks about Idnits analysis, the best way to address the error below while pleasing the IESG was to say in the abstract "This document updates RFC 5440", without square brackets to avoid creating a reference. No need to trigger an update at this stage, but it would be nice to include that change in the next revision down the road. Thanks, Julien On 04/08/2022 12:05, julien.meu...@orange.com wrote: _From idnits:_ - The abstract should avoid using references, i.e. you may replace "[RFC5440]" by a phrase like "the base specification". smime.p7s Description: S/MIME Cryptographic Signature ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Shepherd's Review of draft-ietf-pce-local-protection-enforcement-06
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" 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
Re: [Pce] Shepherd's Review of draft-ietf-pce-local-protection-enforcement-06
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" 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/
Re: [Pce] Shepherd's Review of draft-ietf-pce-local-protection-enforcement-06
Hi Julien, Thank you very much for the detailed review. Will address the below in a document update soon. Thanks again, Andrew On 2022-08-04, 6:06 AM, "Pce 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
