Re: [Pce] Shepherd's Review of draft-ietf-pce-local-protection-enforcement-06

2022-08-08 Thread Stone, Andrew (Nokia - CA/Ottawa)
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/

[Pce] I-D Action: draft-ietf-pce-local-protection-enforcement-07.txt

2022-08-08 Thread internet-drafts


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

Title   : Local Protection Enforcement in PCEP
Authors : Andrew Stone
  Mustapha Aissaoui
  Samuel Sidor
  Siva Sivabalan
  Filename: draft-ietf-pce-local-protection-enforcement-07.txt
  Pages   : 13
  Date: 2022-08-08

Abstract:
   This document extends the base specification to clarify usage of the
   local protection desired bit signalled in the Path Computation
   Element Protocol (PCEP).  This document also introduces a new flag
   for signalling protection strictness in PCEP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-local-protection-enforcement/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-local-protection-enforcement-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-local-protection-enforcement-07


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce