Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages
draft-ietf-pce-lsp-setup-type-10

Received changes through RFC Editor sync (created alias RFC 8408, changed title to 'Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages', changed abstract to 'A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints.  Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol.  However, other TE path setup methods are possible within the PCE architecture.  This document proposes an extension to the PCE Communication Protocol (PCEP) to allow support for different path setup methods over a given PCEP session.', changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-07-24, changed IESG state to RFC Published)

[Ballot discuss]
Ignas balloted NoObj; I'll be the baddie.

Section 6.  Manageability Considerations says:
---
Each document that introduces a new path setup type to PCEP must
  include a manageability section.  The manageability section must
  explain how operators can manage PCEP with the new path setup type.
  It must address the following questions, which are generally
  applicable when working with multiple path setup types in PCEP.

  o  What are the criteria for when devices will use the new path setup
      type in PCEP, and how can the operator control this?

  o  How can the network be migrated to the new path setup type, and
      are there any backwards compatibility issues that operators need
      to be aware of?

  o  Are paths set up using the new path setup type intended to coexist
      with other paths over the long term and, if so, how is this
      situation managed with PCEP?
----

So, I see lots of open questions, but no answers to any of these....

[Ballot comment]
Please expand RP and SRP on first use.

What is the backward compatibility story here? I.e., say I only support method X and the peer doesn't know about this TLV at all? How will it behave?

[Ballot comment]
This is a major comment, I am not balloting DISCUSS at this time as author's intentions may have been to do the right thing, and it has simply slipped or not yet done.

Manageability section lists the right questions, but there are no answers to those questions. Could authors please answer the questions in section 9?

Would capabilities be augmenting the PCEP YANG model, under entity or peer branches? It does not seem that there is a need for a separate model just for this extension?

[Ballot comment]
Substantive Comments:

§1.1: There are at least a few instances of lower case versions of 2119 keywords. Please consider using the boilerplate from RFC 8174.

§7:
Doesn't this need to say something about the possible security considerations when adding new path setup types ?

Editorial Comments and Nits:

§5: "... it MUST consider that the peer suports only ...: I think perhaps "consider" should have been "assume"? Also, s/suports/supports.

[Ballot comment]
Mostly editorial (and I guess already flagged by Alvaro and Martin):

This sentence (in sec 3 as well as the similar sentence in sec 4) should not use normative language because that basically non-sensical:
"If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY
  TLV, it MUST ignore the TLV in accordance with ([RFC5440])."
Should be instead:
"If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY
  TLV, it will ignore the TLV in accordance with ([RFC5440])."

[Ballot comment]
Document says:
  If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY
  TLV, it MUST ignore the TLV in accordance with ([RFC5440]).
and:
  If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it MUST
  ignore the TLV in accordance with ([RFC5440]).

I am fine with this but it does not say anything, explicitly, on what shall be the selected signalling protocol. I guess it will be RSVP-TE because I guess we treat this situation in the same way as if there had been no TLV. But since I am guessing, I feel it wouldn't hurt to be explicit.
On the assumption that my guesses are correct, what about adding, for example, the following sentence (or anything else you'd judge more appropriate):
  From a signalling protocol selection point of view, this situation is treated as if the ... TLV was absent.

[Ballot comment]
I'll let you folks work with Benjamin on this, but I echo his concern about the level of specification covering sub-TLVs (Spencer's summary: "not much specification").  As a related comment, I note that not defining any sub-TLVs in this document prevents the authors from giving any examples of what sub-TLVs might be appropriate, which would have been helpful for me in both the Abstract and Introduction.

(I usually prefer clues about whether the reader should be reading a specification or not. It would be easier for me to know whether this document is relevant to me, if I knew what kinds of sub-TLVs were envisioned, even if only a couple of examples were provided. But do the right thing, of course)

[Ballot comment]
I'm concerned about defining the space for optional sub-TLVs in PATH-SETUP-TYPE-CAPABILITY but
not giving much description of how future sub-TLVs would work (since none are currently defined).
Is there expected to be a one-to-one mapping from PST to sub-TLV, or one-to-many, or something else?
If a given sub-TLV can be associated with more than one PST, some rules would need to be specified for
how that mapping works, what dependency there is on the order in which sub-TLVs appear in the message,
etc.  I am not balloting DISCUSS because I suspect the intent is for each sub-TLV to correspond to exactly one
PST, in which case the behavior is pretty easy.  But I would like to see more description of how this is expected
to work.

Both new TLVs have 'Reserved' fields that MUST be set to zero.  Should they be ignored on receipt (to allow
for potential future use as an extension) or can the receiver validate that they are zero?

The Security Considerations defer to RFCs 5440 and 8281, which (as the secdir review notes) is mostly okay.
RFC 5440 does have a long discussion of the value of TCP authentication, but IIUC it does not mandate that
TCP authentication be used.  That would leave open the possibility that an attacker (e.g., TCP MITM) could
generate error messages when a particular PST is used, potentially forcing the use of a different PST, and this
attacker capability seems to be new in this document.  As such, it would merit a mention in the Security Considerations.
(This attack only becomes relevant in the face of some additional weakness or flaw in a PST that makes forcing
its use advantageous to the attacker for other reasons.)

[Ballot comment]
(1) The Length field in S3 has no units.  I'm sure people can guess it is in bytes, from the rest of the description, but it should be explicit.

(2) The Reserved fields "MUST be set to zero".  What happens if they're not?  Typically they are also ignored by the receiver...

(3) S3: "Each sub-TLV MUST obey the rules for TLV formatting defined in ([RFC5440]).  That is, each sub-TLV MUST be padded to a four byte alignment, and the length field of each sub-TLV MUST NOT include the padding bytes."  The first sentence is ok.  The second one tries to paraphrase what rfc5440 says -- but rfc5440 doesn't say that, it doesn't even use Normative language!  This is the text from rfc5440:

  The Length field defines the length of the value portion in bytes.
  The TLV is padded to 4-bytes alignment; padding is not included in
  the Length field (so a 3-byte value would have a length of 3, but the
  total size of the TLV would be 8 bytes).

(3a) The text in this document shouldn't use Normative language to describe what rfc5440 says and specifies.

(3b) Note that the text from rfc5440 (specifically the part about "padding is not included in the Length field") is not aligned with the description of the Length field in this document: "The TLV Length field MUST be equal to the size of the appended sub-TLVs plus the size of the PST list (rounded up to the nearest multiple of four) plus four bytes."  Rounding up includes the padding.

(4) S6: "Each document that introduces a new path setup type to PCEP must include a manageability section."  Why is a Normative "MUST" not used?

(5) rfc6123 is a Historic document.  Maybe a reference to rfc5706 is more appropriate (even in addition to rfc6123).

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-pce-lsp-setup-type-08. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the PCEP TLV Type Indicators registry on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

the existing temporary registration will be made permanent and its reference changed to [ RFC-to-be ]:

Value: 28
Description: PATH-SETUP-TYPE
Reference: [ RFC-to-be ]

Second, also in the PCEP TLV Type Indicators registry on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

a new registration will be made as follows:

Value: [ TBD-at-Registration ]
Description: PATH-SETUP-TYPE-CAPABILITY
Reference: [ RFC-to-be ]

Third, a new registry is to be created called the PCEP Path Setup Types registry. The new registry will be located on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

The registration policy for the new registry will be IETF Consensus as defined by RFC 8126.

There is a single, initial registration in the new registry as follows:

Value Description Reference

0 Path is setup using the RSVP- [ RFC-to-be ]
TE signaling protocol.

IANA Question --> What is the range of values for this new registry?

Fourth, in the PCEP-ERROR Object Error Types and Values registry also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

https://www.iana.org/assignments/pcep/

the following temporary registrations will be made permanent and their references changed to [ RFC-to-be ]:

Error-Type Meaning
10 Reception of an invalid object

Error-value?: Malformed object

Error-Type Meaning
21 Invalid traffic engineering path setup type

Error-value=0: Unassigned
Error-value=1: Unsupported path setup type
Error-value=2: Mismatched path setup type

IANA notes that the temporary registration for:

Error-Type Meaning
10 Reception of an invalid object

Error-value?: Malformed object

was not done by this document. However, this document is making the registration permanent.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-03-28):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pce-lsp-setup-type@ietf.org, db3546@att.com, pce@ietf.org, pce-chairs@ietf.org, Julien Meuric , julien.meuric@orange.com
Reply-To: ietf@ietf.org
Sender:
Subject: EXTENDED Last Call:  (Conveying path setup type in PCEP messages) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'Conveying path setup type in PCEP
messages'
  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@ietf.org mailing lists by 2018-03-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  A Path Computation Element can compute Traffic Engineering (TE) paths
  through a network that are subject to various constraints.
  Currently, TE paths are Label Switched Paths (LSPs) which are set up
  using the RSVP-TE signaling protocol.  However, other TE path setup
  methods are possible within the PCE architecture.  This document
  proposes an extension to PCEP to allow support for different path
  setup methods over a given PCEP session.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/ballot/


No IPR declarations have been submitted directly on this I-D.

The following Last Call announcement was sent out (ends 2018-03-06):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pce-lsp-setup-type@ietf.org, db3546@att.com, pce@ietf.org, pce-chairs@ietf.org, Julien Meuric , julien.meuric@orange.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Conveying path setup type in PCEP messages) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'Conveying path setup type in PCEP
messages'
  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@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  A Path Computation Element can compute Traffic Engineering (TE) paths
  through a network that are subject to various constraints.
  Currently, TE paths are Label Switched Paths (LSPs) which are set up
  using the RSVP-TE signaling protocol.  However, other TE path setup
  methods are possible within the PCE architecture.  This document
  proposes an extension to PCEP to allow support for different path
  setup methods over a given PCEP session.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard

Why is this the proper type of RFC?

It is a protocol extension.

Is this type of RFC indicated in the title page header?

Yes

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  A Path Computation Element can compute traffic engineering paths (TE
  paths) through a network that are subject to various constraints.
  Currently, TE paths are label switched paths (LSPs) which are set up
  using the RSVP-TE signaling protocol.  However, other TE path setup
  methods are possible within the PCE architecture.  This document
  proposes an extension to PCEP to allow support for different path
  setup methods over a given PCEP session.

Working Group Summary

No controversy. The capability feature added after the 1st LC resulted in a significant change, agreed on the list, and a 2nd WGLC.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?

There are several PCEP implementations supporting Segment Routing, which implies the support of this I-D. The discussion on the list about backward compatible changes showed the I-D is implemented.

Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?

As a shepherd, I triggered the latest changes about a missing feature.

If there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

N/A

Personnel

  Who is the Document Shepherd?

Julien Meuric

Who is the Responsible Area Director?

Deborah Brungard

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document is ready. The latest change was the inclusion of a capability TLV, as a resolution of my main comment.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

N/A

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

N/A

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

It is a building block used for Segment Routing in PCEP, which has clear consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

OK

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes (all being considered as normative)

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

N/A

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section is very clear, since it really had to. It mixes existing early allocation, new request and import from another I-D in an precise manner.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A

Request for posting confirmation emailed to previous authors: Jonathan Hardwick , Siva Sivabalan , Jeff Tantsura , Jan Medved , Ina Minei , pce-chairs@ietf.org, Robert Varga