Re: [Pce] RtgDir review: draft-ietf-pce-pcep-extension-for-pce-controller-09

2021-01-19 Thread Pengshuping (Peng Shuping)
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:
   

[Pce] I-D Action: draft-ietf-pce-stateful-interdomain-00.txt

2021-01-19 Thread internet-drafts


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

Title   : PCEP Extension for Stateful Inter-Domain Tunnels
Authors : Olivier Dugeon
  Julien Meuric
  Young Lee
  Daniele Ceccarelli
Filename: draft-ietf-pce-stateful-interdomain-00.txt
Pages   : 34
Date: 2021-01-19

Abstract:
   This document specifies how to combine a Backward Recursive or
   Hierarchical method with inter-domain paths in the context of
   stateful Path Computation Element (PCE).  It relies on the PCInitiate
   message to set up independent paths per domain.  Combining these
   different paths together enables to operate them as end-to-end inter-
   domain paths without the need for a signaling session between inter-
   domain border routers.  A new Stitching Label is defined, new Path
   Setup Types, a new Association Type and a new PCEP communication
   Protocol (PCEP) Capability are considered for that purpose.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-interdomain/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-stateful-interdomain-00
https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-interdomain-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


[Pce] Secdir last call review of draft-ietf-pce-association-bidir-10

2021-01-19 Thread Chris Lonvick via Datatracker
Reviewer: Chris Lonvick
Review result: Ready

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

The summary of the review is Ready.

The Security Considerations section is a bit light, but addresses the matter.
The only nit I found was that in the Security Considerations section, the use
of TLS for securing the PCEP session is "recommended". I think that's a BCP 14
keyword so should be "RECOMMENDED". (I don't think that's significant enough to
change the summary to Has Nits.)

Best regards,
Chris


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


[Pce] Murray Kucherawy's No Objection on draft-ietf-pce-association-policy-15: (with COMMENT)

2021-01-19 Thread Murray Kucherawy via Datatracker
Murray Kucherawy has entered the following ballot position for
draft-ietf-pce-association-policy-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-association-policy/



--
COMMENT:
--

The use of BCP 14 language in Sections 9.1 and 9.2 seems awkward, since it
appears to be discussing operator-facing features of an implementation rather
than interoperability concerns.  See, in particular, Section 6 of RFC 2119.



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce