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:adrian(_at_)olddog(_dot_)co(_dot_)uk]
Sent: 16 February 2017 22:10
To: ietf(_at_)ietf(_dot_)org
Cc: draft-ietf-pce-stateful-pce(_at_)ietf(_dot_)org; pce(_at_)ietf(_dot_)org;
pce-chairs(_at_)ietf(_dot_)org
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:pce-bounces(_at_)ietf(_dot_)org] On Behalf Of The IESG
Sent: 14 February 2017 22:51
To: IETF-Announce
Cc: draft-ietf-pce-stateful-pce(_at_)ietf(_dot_)org; pce(_at_)ietf(_dot_)org;
pce-chairs(_at_)ietf(_dot_)org
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
ietf(_at_)ietf(_dot_)org mailing lists by 2017-02-28. Exceptionally, comments
may
be sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain
the
beginning of the Subject line to allow automated sorting.