RE: [Pce] Last Call: <draft-ietf-pce-stateful-pce-18.txt> (PCEP Extensions for Stateful PCE) to Proposed Standard

[Jonathan Hardwick <[e-mail]>]

Hi Adrian

Many thanks for these comments.  I'm picking up this thread and replying as PCE working group chair, as the authors are unavailable.  I apologise for the delay.

Please see my proposed resolutions inline below, marked with "Jon>"

Best regards
Jon


-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: 16 February 2017 22:10
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [Pce] Last Call: <draft-ietf-pce-stateful-pce-18.txt> (PCEP Extensions for Stateful PCE) to Proposed Standard

IETF last call

I have read and commented on this document during its production by the PCE working group. It constitutes a missing piece of the puzzle that we started with RFC 4655.

The publication of this work as an RFC is long overdue to the point that implementers have become confused over the last couple of years about whether it would ever be published.

However, on re-reading this final version, I notice a few points.
Nothing major.

Thanks for the work,
Adrian

---
              
The reference to [I-D.ietf-pce-stateful-pce-app] is for some terms that are fundamental to understanding this document.  It needs to be a normative reference.

Jon> ACK. Should be RFC 8051.

---

3.1.3 has...
   Note that existing configuration tools and protocols can be used to
   set LSP state.
...which is true, but is lacking references for the inquisitive mind.

Just need some form of "(such as, ....)"

Jon> "... , such as a Command Line Interface (CLI) tool."

---

In the RBNF in section 6 there is some mismatch between hyphen and underscore. Not only is there a mixture of uses, but sometime the same construct is named in different ways (e.g., in 6.1 you have <actual_attribute_list> and <actual_attribute-list>)

Jon> ACK, will tidy this up.

---

In 6.2, would it help show consistency with 6.1 and remove potential confusion if

      <path>::= <intended_path><attribute-list>

read

      <path>::= <intended_path><intended-attribute-list>

Jon> ACK

---

The use of TBD in the document to flag where IANA allocations need to be updated in the document is going to cause the RFC editor additional work and is error prone. What you should probably do is use TBD1, TBD2, etc. in the text and then include those flags in the IANA considerations sections.

However (!) I note that early allocation has been done for most of the code points. So...
- The IANA section should refer to this and ask IANA to confirm those
  allocations and update the registry to point to this document when it
  is an RFC
- The actual numbers can be filled in in place of all the TBDs
- It would help the reader/coder if you pointed forward to the new
  registries (for example, from 7.3.3 to 8.9)

Jon> ACK although having me do it is equally error prone ;-)

---

7.3.2 Symbolic Path Name

You need to give some clues!
Is this supposed to be printable?
Is this in a particular character set?
Is it supposed to be null terminated (which would mean that if it was a multiple of 4 octets you'd need another four octets of pad)

Jon> This was also raised by others - here is my proposed resolution.

OLD
   Each LSP (path) MUST have a symbolic name that is unique in the PCC.
   This symbolic path name MUST remain constant throughout an LSP's
   lifetime, which may span across multiple consecutive PCEP sessions
   and/or PCC restarts.  The symbolic path name MAY be specified by an
   operator in a PCC's configuration.  If the operator does not specify
   a unique symbolic name for a path, the PCC MUST auto-generate one.

   The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the
   LSP State Report (PCRpt) message when during a given PCEP session an
   LSP is first reported to a PCE.  A PCC sends to a PCE the first LSP
   State Report either during State Synchronization, or when a new LSP
   is configured at the PCC.  The symbolic path name MAY be included in
   the LSP object in subsequent LSP State Reports for the LSP.

   <snip>

   Symbolic Path Name (variable): symbolic name for the LSP, unique in
   the PCC.

NEW
   Each LSP MUST have a symbolic path name that is unique in the PCC.
   The symbolic path name is a human-readable string that identifies an
   LSP in the network.  The symbolic path name MUST remain constant
   throughout an LSP's lifetime, which may span across multiple
   consecutive PCEP sessions and/or PCC restarts.  The symbolic path
   name MAY be specified by an operator in a PCC's configuration.  If the
   operator does not specify a unique symbolic name for an LSP, then the
   PCC MUST auto-generate one.   

   The PCE uses the symbolic path name as a stable identifier for the LSP.
   If the PCEP session restarts, or the PCC restarts, or the PCC re-delegates
   the LSP to a different PCE, the symbolic path name for the LSP remains
   constant and can be used to correlate across the PCEP session instances.

   The other protocol identifiers for the LSP cannot reliably be used to
   identify the LSP across multiple PCEP sessions, for the following reasons.
   -  The PLSP-ID is unique only within the scope of a single PCEP session.
   -  The LSP-IDENTIFIERS TLV is only guaranteed to be present for LSPs 
      that are signalled with RSVP-TE.

   The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the
   LSP State Report (PCRpt) message when during a given PCEP session an
   LSP is first reported to a PCE.  A PCC sends to a PCE the first LSP
   State Report either during State Synchronization, or when a new LSP
   is configured at the PCC.

   The initial PCRpt creates a binding between the symbolic path name and
   the PLSP-ID for the LSP which lasts for the duration of the PCEP session.
   The PCC MAY omit the symbolic path name from subsequent LSP State
   Reports for that LSP on that PCEP session, and just give the PLSP-ID.

   <snip>

   Symbolic Path Name (variable): symbolic name for the LSP, unique in
   the PCC.  It SHOULD be a string of printable ASCII characters and SHOULD
   be NULL-terminated.  The Symbolic Path Name (including its NULL
   terminator) MUST be padded to 4-bytes alignment; the padding itself
   MUST NOT be included in the Length field.

END NEW


---

7.3.4
While 2205 is technically a good enough reference for the ERROR_SPEC object, I wonder if the reader will automatically be aware of the additional work on that object in 3471, 4201, and 4920.

Jon> Did you mean 3473 instead of 3471?  I don't think it's necessary to exhaustively list all RFCs that make use of ERROR_SPEC.  None of these RFCs updates 2205.


> -----Original Message-----
> From: Pce [mailto:[e-mail]] On Behalf Of The IESG
> Sent: 14 February 2017 22:51
> To: IETF-Announce
> Cc: [e-mail]; [e-mail]; 
> [e-mail]
> Subject: [Pce] Last Call: <draft-ietf-pce-stateful-pce-18.txt> (PCEP
Extensions for
> Stateful PCE) to Proposed Standard
> 
> 
> The IESG has received a request from the Path Computation Element WG
> (pce) to consider the following document:
> - 'PCEP Extensions for Stateful PCE'
>   <draft-ietf-pce-stateful-pce-18.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits 
> final comments on this action. Please send substantive comments to the 
> [e-mail] mailing lists by 2017-02-28. Exceptionally, comments may 
> be sent to [e-mail] instead. In either case, please retain the 
> beginning of the Subject line to allow automated sorting.