Last Call Review of draft-ietf-pce-pcep-extension-for-pce-controller-09
review-ietf-pce-pcep-extension-for-pce-controller-09-rtgdir-lc-pritchard-2020-12-22-00

Hello,

I have been selected as the Routing Directorate reviewer for this draft: PCEP
Procedures and Protocol Extensions for Using PCE as a Central Controller
(PCECC) of LSPs.

The Routing Directorate seeks to review all routing or routing-related drafts
as they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-pce-pcep-extension-for-pce-controller-09
Reviewer: Victoria Pritchard
Review Date: 22/12/2020
IETF LC End Date:
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved
before publication.

Comments:

    The draft is generally very good and the diagrams are also very helpful.

    A few sections may initially cause a reader to be confused. I have
    suggested some reorganisation of the text in case this is helpful.

    I also found a few things which were unclear, which could be clarified in
    the document, and have included questions in the Minor issues section.

Major Issues:

    No major issues found.

Minor Issues:

Section 5.4: I got confused reading this - the first part isn't clear but then
extra information is given, but it would be better to be clear from the
start... Here is some suggested text:
---
During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC) advertise
their support of and willingness to use PCEP extensions for PCECC using these
elements in the OPEN message:

   o  A new Path Setup Type (PST) in the PATH-SETUP-TYPE-CAPABILITY TLV to
   indicate support for PCEP extensions for PCECC - TBD1 (Path is set up via
   PCECC mode) o  A new PCECC-CAPABILITY sub-TLV inside the
   PATH-SETUP-TYPE-CAPABILITY TLV to indicate willingness to use PCEP
   extensions for PCECC o  The STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) (with
   the I flag set [RFC8281])

The new Path Setup Type is to be listed in the PATH-SETUP-TYPE-CAPABILITY TLV
by all PCEP speakers which support the PCEP extensions for PCECC in this
document.

The new PCECC-CAPABILITY sub-TLV is included in PATH-SETUP-TYPE-CAPABILITY TLV
in the OPEN object to indicate willingness to use the PCEP extensions for PCECC
during the established PCEP session. Using flags in this TLV, the PCE shows the
intention to function as a PCECC server, and the PCC shows willingness to act
as a PCECC client (see Section 7.1.1).

If the PCECC-CAPABILITY sub-TLV is advertised and the STATEFUL-PCE-CAPABILITY
TLV is not advertised, or is advertised without the I flag set, in the OPEN
Object, the receiver MUST:
   o  Send a PCErr message with Error-Type=19 (Invalid Operation) and
   Error-value=TBD4 (stateful PCE capability was not advertised) o  Terminate
   the session

The PCECC-CAPABILITY sub-TLV SHOULD NOT be used without the corresponding Path
Setup Type being listed in the PATH-SETUP-TYPE-CAPABILITY TLV. If it is present
without the corresponding Path Setup Type listed in the
PATH-SETUP-TYPE-CAPABILITY TLV, it MUST be ignored.

If support and willingness are indicated by the PCE, but not by the PCC, the
PCE MUST:
   o  Send a PCErr message with Error-Type 10 (Reception of an invalid object)
   and Error-Value TBD2 (Missing PCECC-CAPABILITY sub-TLV) o  Terminate the
   PCEP session

If support and willingness is indicated by the PCC but not the PCE, the PCE
will ignore the capability. Unknown sub-TLVs are ignored in accordance with
[RFC8408] and [RFC5440].

If one or both speakers (PCE and PCC) have not indicated support and
willingness to use the PCEP extensions for PCECC, the PCEP extensions for PCECC
MUST NOT be used. If a PCECC operation is attempted when both speakers have not
agreed in the OPEN messages, the receiver of the message MUST:
   o  Send a PCErr message with Error-Type=19 (Invalid Operation) and
   Error-Value=TBD3 (Attempted PCECC operations when PCECC capability was not
   advertised) o  Terminate the PCEP session

---
Question: If the PCE shows support and willingness, but the PCC doesn't, and
the session is closed, would the PCE attempt a new session without the use of
these extensions for PCECC? Question: If the PCC supports the extension but the
PCE doesn't, is there already text elsewhere that says unknown Path Setup Types
can be ignored by the PCE? The suggested text above may be wrong if not.
Question: If the PCC does not support the PCECC extensions but the PCE
attempted to start a PCECC operation, will the PCC be able to send an error
(the error mentioned implies support but not willingness)?

Section 5.5.1 PCE-Initiated PCECC LSP:

Again this section seems a bit jumbled, confusing at the start, but with
re-reading becomes clearer. Halfway down this section it says: "Note that the
label forwarding instructions (see Section 5.5.3) from
   PCECC are sent after the initial PCInitiate and PCRpt message
   exchange with the ingress PCC."

So the description above this, detailing the LSP-IDENTIFIER TLV and LSP object
within the CCI, is not part of the first message exchange? If there needs to be
an initial exchange without CCI first, to get the PLSP-ID etc, to put in the
next set of PCInitiate messages, then this statement should go at the beginning
of this section, maybe with a reference Figure 1, and state any differences to
the usual exchange. I think from re-reading, it means the initial exchange as
per RFC 8281 is modified with Path Setup Type set to TBD1, but still includes
an LSP object (reserved PLSP-ID = 0, Delegate flag, SYMBOLIC-PATH-NAME TLV?) as
in section 5.3 RFC 8281?

The diagram Figure 1 is really helpful. A few references to it in the
description may help, particularly to indicate the initial exchange, then the
CCI exchanges with all nodes, and describing in chronological order as shown in
the diagram would help.

Section 5.5.3.1: What does it mean to "download the label" - does this just
mean to parse the message or does it imply some further processing?

Section 5.5.4: This section also seems to be a little out of order. I would
remove the first sentence, start with the "make-before-break" procedure, make
it clear these instructions are sent to the transit and egress PCCs first, then
to the ingress PCC last. The diagram is again very good.

Section 5.5.9: This is the first mention of the P flag - is this the same P
shown in the earlier diagrams? Should the flag have been mentioned earlier?
Again the ordering could be improved. e.g. - PCE could allocate binding label
on its own accord for a PCE-initiated or delegated LSP, and inform the PCC in
the PCInitiate message or PCUpd message by including P=1 and TE-PATH-BINDING
TLV - PCE could request that the PCC allocates the binding label by setting P=0
in the PCInitiate - If binding label is not supplied in PCInitiate, a PCC could
request that the PCE allocate it by including P=1 D=1 and TE-PATH-BINDING TLV
(with no Binding Value) in a PCRpt. The PCE would allocate the binding label ...

In the capability exchange sections you mentioned error messages if someone
attempts an operation without declaring support and willingness to use that
capability - is there anything similar in case the binding label allocation is
requested/allocated when the PCECC capability has not been agreed for the
session?

Section 7.1.1 PCECC Capability sub-TLV:
"Advertisement of the PCECC capability implies support of LSPs that are set up
through PCECC" However, earlier this draft stated that advertisement of the
capability is done using the path setup type, and that this PCECC capability
TLV should not be included without the PCECC type also being listed in the
Path-Setup-Type list (and should be ignored if the path setup type is not
listed). So in this section we should avoid potential conflict with the earlier
statement. Perhaps: "The PCECC-CAPABILITY sub-TLV is an optional TLV for use in
the OPEN Object in the PATH-SETUP-TYPE-CAPABILITY TLV, when the Path Setup Type
list includes the PCECC Path Setup Type TBD1. A PCECC-CAPABILITY sub-TLV MUST
be ignored if the PST list does not contain PST=TBD1."

Should the new PATH-SETUP-TYPE be mentioned in the OPEN Object section too?

To match earlier sections, this section could use the word "willingness" when
describing the L bit.

Section 7.3: The C bit - does it mean the PCC sets the C bit to indicate it has
allocated the instruction rather than allocated the CC-ID - as far as I
understood it, the CC-ID comes from the PCE?

Nits:

Section 5.3: Brackets around the reference to section 7.3 seem like they should
be around the rest of the sentence "(see Section 7.3 for the encoding of the
central controller instructions)."

Section 5.5:
Should the Path Setup Type TBD1 be mentioned, to clearly identify that PCECC
LSP is intended? Is the requirement of the PATH-SETUP-TYPE TLV in these
messages new? This could be highlighted more clearly if so. This is the first
time "SRP" has been used - should this be expanded?

Kind regards,
Victoria Pritchard.
This email and its attachments may contain confidential and/or privileged
information.  If you have received them in error you must not use, copy or
disclose their content to any person.  Please notify the sender immediately and
then delete this email from your system.  This e-mail has been scanned for
viruses, but it is the responsibility of the recipient to conduct their own
security measures. Airbus Operations Limited is not liable for any loss or
damage arising from the receipt or use of this e-mail.

Airbus Operations Limited, a company registered in England and Wales,
registration number, 3468788.  Registered office:  Pegasus House, Aerospace
Avenue, Filton, Bristol, BS34 7PA, UK.