Hi Victoria,
Many thanks for your review. Please find the diff which reflects the changes we
have made following your suggestions.
https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-pcep-extension-for-pce-controller-09&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-pcep-extension-for-pce-controller-10.txt
Please find our responses in line below.
Best regards,
Shuping
From: Pritchard, Victoria [mailto:victoria.pritch...@airbus.com]
Sent: Tuesday, December 22, 2020 9:16 PM
To: rtg-...@ietf.org
Cc: rtg-...@ietf.org;
draft-ietf-pce-pcep-extension-for-pce-controller@ietf.org; pce@ietf.org
Subject: RtgDir review: draft-ietf-pce-pcep-extension-for-pce-controller-09
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.
[Shuping] Thank you!
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.
[Shuping] Thanks for providing such detailed comments with suggested text. Much
appreciated!
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: