Re: [auth48] AUTH48: RFC-to-be 9488 <draft-ietf-pce-local-protection-enforcement-11> for your review

["Mustapha Aissaoui (Nokia)" <[e-mail]>]

I approve this document for publication.

Regards,
Mustapha.

From: [e-mail] <[e-mail]>
Date: Thursday, September 28, 2023 at 5:03 PM
To: Andrew Stone (Nokia) <[e-mail]>, Mustapha Aissaoui (Nokia) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: AUTH48: RFC-to-be 9488 <draft-ietf-pce-local-protection-enforcement-11> for your review

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.

1) <!-- [rfced] Please note that the title of the document has been updated as
follows. We expanded the abbreviation "PCEP" per Section 3.6 of RFC 7322
("RFC Style Guide"). Please review.

Original:
  Local Protection Enforcement in PCEP

Current:
  Local Protection Enforcement in the Path Computation Element
  Communication Protocol (PCEP)

Note that we also updated the abbreviated title (only appears in the running
header of the pdf output) to match the document title as there was space.

Original:
  Protection Enforcement

Current:
  Local Protection Enforcement in PCEP
-->


2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on https://www.rfc-editor.org/search. -->


3) <!-- [rfced] For this sentence in the Abstract, is "protection strictness"
okay, or would "protection enforcement" (like in the document title) be
better?

Original:
   This document also introduces a new flag for
   signalling protection strictness in PCEP.
-->


4) <!-- [rfced] Please review "define enforcement, or strictness of the
protection requirement" here. Would it be helpful to update to either
"define the enforcement of the protection requirement" or "define the
strictness of the protection enforcement requirement"?

Original:
   It is desirable for an operator to be able to define the enforcement,
   or strictness of the protection requirement.

Perhaps:
   It is desirable for an operator to be able to define the enforcement
   of the protection requirement.

Or:
   It is desirable for an operator to be able to define the strictness
   of the protection enforcement requirement.
-->


5) <!-- [rfced] Will readers understand what is meant by "reference notes"? Also,
we revised "is path setup type and data plane technology agnostic" as
follows to improve readability.

Original:
   The document contains reference notes for Segment Routing, however
   the content described is path setup type and data plane technology
   agnostic.

Current:
   The document contains reference notes for Segment Routing; however,
   the content described is agnostic in regard to path setup type and
   data plane technology.
-->


6) <!-- [rfced] We are having trouble understanding how the last part of this
sentence (i.e., "and the use case...") connects with the first
part. Also, would a citation be helpful for "RSVP"?

Original:
   The name of the flag uses the term "Desired", which by
   definition means "strongly wished for or intended" and the use case
   originated from the RSVP.

Perhaps:
   The name of the flag uses the term "Desired", which by
   definition means "strongly wished for or intended". The use case
   for this flag originated in RSVP.
-->


7) <!-- [rfced] May we update "Implementations of [RFC5440]" as follows for
clarity?

Original:
   Implementations of [RFC5440] have either interpreted the L flag as
   PROTECTION MANDATORY or PROTECTION PREFERRED, leading to operational
   differences.

Perhaps:
   Implementations that use PCEP [RFC5440] have interpreted the L flag as
   either PROTECTION MANDATORY or PROTECTION PREFERRED, leading to operational
   differences.
-->


8) <!-- [rfced] Should "service agreement definitions" here read "Service Level
Agreement definitions" or "SLA definitions"? Or is the current correct?

Original:
   A network may be providing transit to
   multiple service agreement definitions against the same base topology
   network, whose behavior could vary, such as wanting local protection
   to be invoked on some LSPs and not wanting local protection on
   others.
-->


9) <!-- [rfced] Please review "The boolean bit L flag". Would one of the
following options improve clarity and readability?

Original:
   The boolean bit L flag is unable to distinguish between the different
   options of PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION
   PREFERRED and UNPROTECTED PREFERRED.

Perhaps:
   The L flag is a boolean bit and thus unable to distinguish between the different
   options of PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION
   PREFERRED and UNPROTECTED PREFERRED.

Or:
   Because it is a boolean bit, the L flag is unable to distinguish between the different
   options of PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION
   PREFERRED, and UNPROTECTED PREFERRED.
-->


10) <!-- [rfced] Two consecutive paragraphs in Section 4.2 begin with "For
example". Is "For example" needed here? Or should the second one be
updated to something like "As another example"? Please review.

Also, in the second paragraph below, we updated "is when an operator" to "is
for use cases in which an operator" for clarity and for consistency with the
previous paragraph. Please review.

Original:
   For example, PROTECTION MANDATORY is for use cases where an operator
   may need the LSP to follow a path which has local protection provided
   along the full path, ensuring that if there is a failure anywhere
   along the path that traffic will be fast re-routed at the point.

   For example, UNPROTECTED MANDATORY is when an operator may
   intentionally prefer an LSP to not be locally protected, and thus
   would rather local failures cause the LSP to go down. ...

Perhaps:
   PROTECTION MANDATORY is for use cases in which an operator
   may need the LSP to follow a path that has local protection provided
   along the full path, ensuring that if there is a failure anywhere
   along the path that traffic will be fast re-routed at the point.

   UNPROTECTED MANDATORY is for use cases in which an operator may
   intentionally prefer an LSP to not be locally protected and thus
   would rather local failures cause the LSP to go down.
-->


11) <!-- [rfced] Please review "protected with path protection" here. Would
updating to just "protected" retain the intended meaning?

Original:
   An example
   scenario is one where an LSP is protected with path protection via a
   secondary diverse LSP.

Perhaps:
   An example
   scenario is one where an LSP is protected via a secondary diverse LSP.
-->


12) <!-- [rfced] In Table 1, would it be helpful to list bit 6 first and then bit 7
(matches IANA registry)? Or do you prefer the current (matches order mentioned in
text before table)?
-->


13) <!-- [rfced] We updated this sentence as follows to more accurately describe
the figure. Please let us know any objections.

Original:
   The format of the LSPA Object as defined in [RFC5440] is:

Current:
   The following shows the format of the LSPA object as defined in
   [RFC5440] with the addition of the E flag defined in this document:
-->


14) <!-- [rfced] May we rephrase this sentence to improve clarity?

Original:
   Considerations in the message passing between the PCC and the PCE for
   the E flag bit which are not supported by the entity are outlined in
   this section, with requirements for the PCE and the PCC implementing
   this document described at the end.

Perhaps:
   This section outlines considerations for the E flag bit in the message
   passing between the PCC and the PCE that are not supported by the entity.
   The requirements for the PCE and the PCC implementing this document are described
   at the end.
-->


15) <!-- [rfced] Should "PCUpd E flag (and L flag)" be updated to "the E flag (and
L flag) in a PCUpd message" or something similar? Also, we used a
semicolon and changed "therefore" to "so" for clarity. Please review.

Original:
   For PCC-initiated LSPs, PCUpd E flag (and L flag) is an echo from the
   previous PCRpt however the bit value is ignored on the PCE from the
   previous PCRpt, therefore the E flag value set in the PCUpd is zero.

Perhaps:
   For PCC-initiated LSPs, the E flag (and L flag) in a PCUpd message is an echo from the
   previous PCRpt message; however, the bit value is ignored on the PCE from the
   previous PCRpt message, so the E flag value set in the PCUpd message is 0.
-->


16) <!-- [rfced] Will readers understand what "it" refers to here?

Original:
   For a PCC which does support this document, it MAY set the E flag to
   1 depending on local configuration.

Perhaps:
   A PCC that does support this document MAY set the E flag to
   1 depending on local configuration.

Or:
   For a PCC that does support this document, the E flag MAY be set to
   1 depending on local configuration.
-->


17) <!-- [rfced] Would you like the references to be alphabetized or left in their
current order?
-->


18) <!-- [rfced] Terminology

a) Please confirm the name/description for the E flag defined in this
document. We see the following forms used in the document:

Enforcement
Protection Enforcement
Local Protection Enforcement

Note: The current name in the "LSPA Object Flag Field" registry is "Protection
Enforcement" (see
https://www.iana.org/assignments/pcep/pcep.xhtml#lspa-object-flag-field); if
needed, we will request an update to the registry prior to publication.


b) Should "a local protection desired" here read "the L flag"?

Original:
   Therefore, a local protection desired does
   not require the transit router to satisfy protection in order to
   establish the RSVP signalled path.

Perhaps:
   Therefore, the L flag does
   not require the transit router to satisfy protection in order to
   establish the RSVP-signaled path.


c) FYI - We have updated instances of "PCRpt", "PCUpd", "PCReq", and
"PCInitiate" with the word "message" (i.e., "PCRpt message", "PCUpd message",
"PCReq message", and "PCInitiate message").


d) We see "Session Attribute" (initial caps and no hyphen) in RFC 3209, but we
do not see "SESSION-ATTRIBUTE" (all caps with hyphen). Please review and let
us know if any updates are needed in the following sentence.

Original:
   One such concept in PCEP is the 'Local Protection
   Desired' (L flag in the LSPA Object in [RFC5440]), which was
   originally defined in the SESSION-ATTRIBUTE Object in RFC3209.


e) "Segment Routed path" does not appear in RFC 8664, but "Segment
Routing path" does. Are any changes needed in these sentences?

Original:
   PCEP Extensions for Segment Routing ([RFC8664]) extends support in
   PCEP for Segment Routed paths.
   ...
   When computing a Segment Routed path, It is RECOMMENDED that a PCE
   assume a Node SID is protected.

f) We see that "LSP object" is used in both RFCs 8231 and 8281,
but "LSP Attribute Object" (or "LSPA") is not used in either. Should the
sentence below be updated to reflect usage in the cited documents?

Original:
   It is
   important to note that [RFC8231] and [RFC8281] permit the LSP
   Attribute Object to be included in PCUpd messages for PCC-initiated
   and PCE-initiated LSPs.
-->


19) <!-- [rfced] FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

Path Computation Element Communication Protocol (PCEP)
Label Switched Path (LSP)
Border Gateway Protocol - Link State (BGP-LS)
Service Level Agreement (SLA)
-->


20) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->


Thank you.

RFC Editor/rv/ap

On Sep 28, 2023, at 2:02 PM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2023/09/28

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.

Planning your review
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

   Please review and resolve any questions raised by the RFC Editor
   that have been included in the XML file as comments marked as
   follows:

   <!-- [rfced] ... -->

   These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors

   Please ensure that you review any changes submitted by your
   coauthors.  We assume that if you do not speak up that you
   agree to changes submitted by your coauthors.

*  Content

   Please review the full content of the document, as this cannot
   change once the RFC is published.  Please pay particular attention to:
   - IANA considerations updates (if applicable)
   - contact information
   - references

*  Copyright notices and legends

   Please review the copyright notice and legends as defined in
   RFC 5378 and the Trust Legal Provisions
   (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

   Please review the markup in the XML file to ensure that elements of
   content are correctly tagged.  For example, ensure that <sourcecode>
   and <artwork> are set correctly.  See details at
   <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

   Please review the PDF, HTML, and TXT files to ensure that the
   formatted output, as generated from the markup in the XML file, is
   reasonable.  Please note that the TXT will have formatting
   limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:

   *  your coauthors

   *  [e-mail] (the RPC team)

   *  other document participants, depending on the stream (e.g.,
      IETF Stream participants are your working group chairs, the
      responsible ADs, and the document shepherd).

   *  [e-mail], which is a new archival mailing list
      to preserve AUTH48 conversations; it is not an active discussion
      list:

     *  More info:
        https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc

     *  The archive itself:
        https://mailarchive.ietf.org/arch/browse/auth48archive/

     *  Note: If only absolutely necessary, you may temporarily opt out
        of the archiving of messages (e.g., to discuss a sensitive matter).
        If needed, please add a note at the top of the message that you
        have dropped the address. When the discussion is concluded,
        [e-mail] will be re-added to the CC list and
        its addition will be noted at the top of the message.

You may submit your changes in one of two ways:

An update to the provided XML file
 — OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes.  Information about stream managers can be found in
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication.  Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.


Files
-----

The files are available here:
   https://www.rfc-editor.org/authors/rfc9488.xml
   https://www.rfc-editor.org/authors/rfc9488.html
   https://www.rfc-editor.org/authors/rfc9488.pdf
   https://www.rfc-editor.org/authors/rfc9488.txt

Diff file of the text:
   https://www.rfc-editor.org/authors/rfc9488-diff.html
   https://www.rfc-editor.org/authors/rfc9488-rfcdiff.html (side by side)

Diff of the XML:
   https://www.rfc-editor.org/authors/rfc9488-xmldiff1.html

The following files are provided to facilitate creation of your own
diff files of the XML.

Initial XMLv3 created using XMLv2 as input:
   https://www.rfc-editor.org/authors/rfc9488.original.v2v3.xml

XMLv3 file that is a best effort to capture v3-related format updates
only:
   https://www.rfc-editor.org/authors/rfc9488.form.xml


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
   https://www.rfc-editor.org/auth48/rfc9488

Please let us know if you have any questions.

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9488 (draft-ietf-pce-local-protection-enforcement-11)

Title            : Local Protection Enforcement in PCEP
Author(s)        : A. Stone, M. Aissaoui, S. Sidor, S. Sivabalan
WG Chair(s)      : Julien Meuric, Dhruv Dhody

Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston