Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE
draft-ietf-pce-stateful-path-protection-11

Received changes through RFC Editor sync (created alias RFC 8745, changed title to 'Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE', changed abstract to 'An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs).  Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs.  This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection.', changed pages to 15, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2020-03-29, changed IESG state to RFC Published)

[Ballot comment]
Thank you for the work put into this document. I am trusting the routing AD for their deep understanding of this document and their approval.

Nevertheless, I have 2 COMMENTs which are mere questions of mine.

Regards,

-éric

== COMMENTS ==

-- Section 3.2 --
C.1) Any reason to have a field named "unassigned flags" rather than "reserved"? After all, those bits could be used later for something different than flags. Also applicable to section 6.2.

C.2) is there any reason the "P", "S" and "PT" are described right to left ?

[Ballot comment]
** Section 3.2.  It took me a bit to understand that the Path Protection Association TLV goes in an ASSOCIATION Object per Section 6 of [I-D.ietf-pce-association-group].  On initial reading of “[t]he Path Protection Association TLV is an optional TLV for use with the Path Protection Association Type” this relationship wasn’t clear.  I’d recommend an editorial update to make it clearer.  I believe this is related Ben Kaduk’s DISCUSS #5 (which I support).

** Section 3.2  The protection type field specifies the protection type of the LSP.  Section 1 notes that “one working LSP [can be associated with] one or more protection LSPs using the generic association mechanism.”  Assuming a case were multiple protection LSPs are specified, is it valid for the protections type to be different?

** Section 4.5.  For clarity, I would recommend being precise with the exact code point names when discussing conflicting combinations of protection types.  For example, s/1+1 or 1:N/1+1 (i.e., protection type=0x08 or 0x10) or 1:N (i.e., protection type = 0x04) with N=1 per /

Baring these combinations, are other any other remaining combinations of protection types legal given different protection LSPs in the same PPAG (e.g., 0x1 + 0x2)?

** Editorial Nits:
-- Section 1.  s/effect/affect/

-- Section 1.  Per “When the working LSPs are computed and controlled by the PCE, there is benefit in a mode of operation where protection LSPs are as well”, I couldn’t parse the second clause.

[Ballot discuss]
(1) draft-ietf-pce-association-group notes that "PCEP extensions that define
a new association type should clarify the relationship between the SVEC
object and the association type, if any".  Where do we do so for the
path protection association type?

(2) Section 3.2 says:

      Protection Type (PT): 6 bits - This field is as defined in
      Section 14.1 of [RFC4872] to indicate the LSP protection type in
      use.

There doesn't seem to be a registry created by RFC 4872 to track these
PT values, so I assume that the way to allocate a new value is
"standards-track RFC that Updates: RFC 4872".  Is that also the way to
allocate new PT values for PPAG usage?  How would someone updating RFC
4872 to allocate a new type know to consider/document whether it applies
for PPAG usage?

(3) In Section 4.3:

  A PCE can create/update working and protection LSPs independently.
  As specified in [I-D.ietf-pce-association-group], Association Groups
  can be created by both the PCE and the PCC.  Further, a PCE can

The requirement that source, destination, and tunnel ID of all LSPs
within a PPAG MUST be the same is new to this document, so I think we
need to specify error handling for when attempts to update LSPs
independently would violate that invariant (presumably in Section 4.5).

(4) In Section 6.3:

                                      IANA is requested to allocate new
  error values within the "PCEP-ERROR Object Error Types and Values"
  sub-registry of the PCEP Numbers registry, as follows:

The following table only lists Error-values.  What Error-type(s) should
they be associated with?

(5) We don't say which objects the PPAG TLV can appear in.  (Section 3.2
says "[t]he Path Protection Association TLV is an optional TLV for use
with the Path Protection Association Type", but it's hard to interpret
that as meaning "for use [only] with the ASSOCIATION object defined in
draft-ietf-pce-association-group", especially since there is a "path
protection association type" already (and it's a codepoint in the
"ASSOCIATION Type Field" registry).

(6) I'm not sure if a change to the document is needed here, but perhaps
some discussion is in order: we say that a given LSP can belong to more
than one PPAG, but only allow one PPAG TLV per [some context that
remains unclear; see (5)].  I don't have a good handle for whether these
two requirements are potentially in conflict: that is, whether a single
PPAG TLV would have to specify the flags that apply for both PPAGs that
a given LSP is a member of, or if the containing objects serve to scope
the PPAG TLV flags' interpretation.

(7) Do the Protection Type fields of the PPAG TLV in the various LSPs
that are members of the same PPAG need to match, in the same way that
the source/destination/tunnel-ID do?

[Ballot comment]
Section 1

  This document specifies a stateful PCEP extension to associate two or
  more LSPs for the purpose of setting up path protection.  The
  proposed extension covers the following scenarios:

nit: after publication, it doesn't really seem like a *proposed*
extension anymore.

Section 3.1

  LSPs are not associated by listing the other LSPs with which they
  interact, but rather by making them belong to an association group
  referred to as "Path Protection Association Group" (PPAG) in this
  document.  [...]

The first 2/3 of this sentence is a (true) generic statement about all
association groups, which exist outside of this document in a generic
fashion.  I strongly suggest rewording this to make clear that the PPAG
is the specific association (group) type used for this document's
functionality but that other association groups are possible.  The
current wording implies that the PPAG is the only association possible,
and it is just given a special name for this document's purposes.

  [I-D.ietf-pce-association-group] specifies the mechanism for the
  capability advertisement of the Association types supported by a PCEP
  speaker by defining a ASSOC-Type-List TLV to be carried within an
  OPEN object.  This capability exchange for the Association type
  described in this document (i.e.  Path Protection Association Type)
  MAY be done before using the policy association, i.e., the PCEP
  speaker MAY include the Path Protection Association Type (TBD1) in
  the ASSOC-Type-List TLV before using the PPAG in the PCEP messages.

Why is this only MAY and not MUST?

  This Association type is dynamic in nature and created by the PCC or

nit: is it the type that is dynamic or the associations of that type?

      Protecting (P): 1 bit - This bit is as defined in Section 14.1 of
      [RFC4872] to indicate if the LSP is working or protection LSP.

      Secondary (S): 1 bit - This bit is as defined in Section 14.1 of
      [RFC4872] to indicate if the LSP is primary or secondary LSP.  The
      S flag is ignored if the P flag is not set.

Just to check my understanding (no change expected to result): if P is
zero, the LSP is working, and thus we know that it's primary since it's
actively carrying traffic?

Section 3.2

nit(?) The section heading does not match the name of the TLV requested
in the IANA considerations, nor do we mention here that "PPAG TLV" is
synonymous with it.

  If the TLV is missing, it is considered that the LSP is the working
  LSP (i.e. as if P bit is unset).

Is this conditional on the LSP being part of a PPAG, or does it hold
generically as well?

Section 4.5

  As per the processing rules specified in section 5.4 of
  [I-D.ietf-pce-association-group], if a PCEP speaker does not support

There is no Section 5.4 in draft-ietf-pce-association-group-10;
presumably this was supposed to be Section 6.4?

  A given LSP MAY belong to more than one PPAG.  If there is a conflict

While I'm not arguing to remove this option, I'm also a bit confused at
how useful having a single LSP be in multiple PPAGs woud be, given the
need for source/destination/tunnel-ID to match.

  When the protection type is set to 1+1 or 1:N with N=1, there MUST be
  only one working LSP and one protection LSP within a PPAG.  If a PCEP
  speaker attempts to add another working/protection LSP, the PCEP peer
  MUST send PCErr with Error-Type 26 (Association Error)
  [I-D.ietf-pce-association-group] and Error-Value TBD4 (Attempt to add
  another working/protection LSP for Path Protection Association).

This seems to prevent a scenario where there's a need to change the
protection LSP and a desire to do so without removing the protected
nature of the working LSP.  Unless it's presumed that this could always
be done by updating the protection LSP and it would never be necessary
to create a new one?  (Similarly for 1:N, though maybe less severe.)

Section 5

  [RFC4872] introduces the concept and mechanisms to support the
  association of one LSP to another LSP across different RSVP - Traffic
  Engineering (RSVP-TE) sessions using ASSOCIATION and PROTECTION
  object.  The information in the PPAG TLV in PCEP as received from the
  PCE, is used to trigger the signalling of working LSP and protection
  LSP, with the Path Protection Association Flags mapped to the
  corresponding fields in the PROTECTION Object in RSVP-TE.

Just to check my understanding: this paragraph is saying that the
contents of the PPAG TLV received by the PCC is used as input to
populating the PROTECTION object that corresponds to the protection
group?

Section 10.2

I think RFCs 7525 and 8253 need to be normative (and please cite RFC
7525 as BCP 195).

[Ballot comment]
Thanks for this document.  I have only editorial suggestions.  There's no need to reply in any detail; just please consider adopting these suggestions.  Thanks.

— Abstract —

  Multiprotocol Label Switching Traffic
  Engineering Label Switched Paths (MPLS LSP)

Shouldn’t that be “(MPLS-TE LSPs)”?

— Section 1 —

  [RFC5440] describes PCEP for communication between a Path Computation
  Client (PCC) and a PCE or between a pair of PCEs as per [RFC4655].  A
  PCE computes paths for MPLS-TE LSPs based on various constraints and
  optimization criteria.

Even though you expanded some of these acronyms in the Abstract, they have to be expanded again in the Introduction, because the Abstract and the document itself each has to stand separately.

That said, “MPLS-TE” and “PCE” are in the RFC Editor’s list of common acronyms that don’t need expansion, so you can expand them or not, as you please.  But “PCEP” and “LSP” do need expansion here.

You should also be consistent in using “MPLS-TE” (with the hyphen), so please check the instances of “MPLS TE” without the hyphen, and change them.  The RFC Editor will flag this anyway, and it saves time during final editing and AUTH48 if you fix it now.

  It includes
  mechanisms to effect LSP state synchronization between PCCs and PCEs,
  delegation of control of LSPs to PCEs, and PCE control of timing and
  sequence of path computations within and across PCEP sessions and
  focuses on a model where LSPs are configured on the PCC and control
  over them is delegated to the PCE.

This is a really long sentence, and can do with being split in two.  I suggest changing “sessions and” to “sessions.  Stateful PCE”.

  Furthermore, a mechanism to
  dynamically instantiate LSPs on a PCC based on the requests from a
  stateful PCE or a controller using stateful PCE, is specified in
  [RFC8281].

This reads oddly in passive voice, and you have a clear subject to use.  So I suggest:

NEW
  Furthermore, [RFC8281] specifies a mechanism to
  dynamically instantiate LSPs on a PCC based on the requests from a
  stateful PCE or a controller using stateful PCE.
END

      computes the path for the protection LSP and update the PCC with

“updates”

  Note that protection LSP can be established (signaled) prior to the
  failure (in which case the LSP is said to be in standby mode
  [RFC4427] or a Primary LSP [RFC4872]) or post failure of the
  corresponding working LSP according to the operator choice/policy
  (known as secondary LSP [RFC4872]).

“a protection LSP”

I suggest changing “post failure” to “after failure”, as it reads better.

I’m not sure about the antecedent to “according to the operator choice/policy”.  I think you mean that the establishment can be prior to failure or after failure, according to operator choice or policy, is that right?  In that case, the sentence isn’t worded well.  May I suggest this?:

NEW
  Note that a protection LSP can be established (signaled) before
  the failure (in which case the LSP is said to be in standby mode
  [RFC4427] or a Primary LSP [RFC4872]) or after failure of the
  corresponding working LSP (known as secondary LSP [RFC4872]).
  Whether to establish it before or after failure is according
  to operator choice or policy.
END

  [I-D.ietf-pce-association-group] introduces a generic mechanism to
  create a grouping of LSPs which can then be used to define
  associations between a set of LSPs that is equally applicable to
  stateful PCE (active and passive modes) and stateless PCE.

When I first read this I thought “that is equally applicable” applied to the set of LSPs.  I think you mean it to apply to the generic mechanism — that is, the generic mechanism is equally applicable.  Assuming that’s right (note inserted comma and split sentences):

NEW
  [I-D.ietf-pce-association-group] introduces a generic mechanism to
  create a grouping of LSPs, which can then be used to define
  associations between a set of LSPs.  The mechanism is equally
  applicable to stateful PCE (active and passive modes) and stateless
  PCE.
END

— Section 3.2 —

      Protecting (P): 1 bit - This bit is as defined in Section 14.1 of
      [RFC4872] to indicate if the LSP is working or protection LSP.

At a minimum, make it “a working or protection LSP” (add the article).
Better still, “a working (0) or protection (1) LSP.”  I know it says that in RFC 4872, but I think it makes sense to include that here.

      Secondary (S): 1 bit - This bit is as defined in Section 14.1 of
      [RFC4872] to indicate if the LSP is primary or secondary LSP.  The
      S flag is ignored if the P flag is not set.

Similarly, add the article “a”, and also consider “a primary (0) or secondary (1) LSP.”

  If the TLV is missing, it is considered that the LSP is the working
  LSP (i.e. as if P bit is unset).

Is this really “the working LSP”, or should it be “a working LSP”?

— Section 4 —

  An LSP is associated with other LSPs with which they interact by
  adding them to a common association group via the ASSOCIATION object.

The number disagreement here is confusing, so I’m not sure what you mean to say.  I think you mean that the other LSPs are added to the group, in which case change “they interact” to “it interacts”.


— Section 4.2 —

  A PCC can associate a set of LSPs under its control for path
  protection purpose.

“purposes”

  PCC reports the change in association to PCE(s) via Path Computation
  Report (PCRpt) message.

Either “a Path Computation Report (PCRpt) message” or “Path Computation Report (PCRpt) messages”.

  It is expected that both working and protection LSP are delegated

“LSPs”

— Section 4.5 —

  When the protection type is set to 1+1 or 1:N with N=1, there MUST be
…
  When the protection type is set to 1:N with N>1, there MUST be

This is a style thing, so take it or leave it as you please — it’s not wrong the way it’s written.  It’s just that the “1:N with N=1” and “1:N with N>1” distinction isn’t necessary, and I think it’s distracting and invites uncertainty.  If you just made these like this:

NEW
  When the protection type is set to 1+1, there MUST be
…
  When the protection type is set to 1:N, there MUST be
END

…it would be equally correct, but also simpler and, I think, less likely to be confusing.

— Section 5 —

  association of one LSP to another LSP across different RSVP - Traffic
  Engineering (RSVP-TE) sessions

Is it typical to have that hyphen there in the first line?  Isn’t it more typical to write “RSVP Traffic Engineering (RSVP-TE)” without the extra hyphen?

  The information in the PPAG TLV in PCEP as received from the
  PCE, is used to trigger

Remove the comma.

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

The IANA Functions Operator has completed its review of draft-ietf-pce-stateful-path-protection-08. If any part of this review is inaccurate, please let us know.

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

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

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

a single, new registration is to be made as follows:

Type: [ TBD-at-Registration ]
Name: Path Protection Association
Reference: [ RFC-to-be ]

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

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

a single, new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Description: Path Protection Association Group TLV
Reference: [ RFC-to-be ]

Third, a new registry is to be created called the Path Protection Association Group TLV Flag Field registry. The new registry is to be created on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

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

The new registry is to be managed via Standards Action as defined in RFC 8126. There are initial registrations in the new registry as follows:

+------------+-----------------------+----------------+
| Bit Number | Name | Reference |
+------------+-----------------------+----------------+
| 31 | P - PROTECTION-LSP | [ RFC-to-be ] |
| 30 | S - SECONDARY-LSP | [ RFC-to-be ] |
| 0-5 | Protection Type Flags | [ RFC-to-be ] |
+------------+-----------------------+----------------+

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/

there is an early registration for Error-type 26 "Association Error" - the following three error values are to be added to Error-type 26.

+------------------------+-----------------------------------------+-------------+
| Error-value | Meaning | Reference |
+------------------------+-----------------------------------------+-------------+
| [ TBD-at-Registration ]| Tunnel ID or End points mismatch for |[ RFC-to-be ]|
| | Path Protection Association | |
| [ TBD-at-Registration ]| Attempt to add another |[ RFC-to-be ]|
| | working/protection LSP for Path | |
| | Protection Association | |
| [ TBD-at-Registration ]| Protection type is not supported |[ RFC-to-be ]|
| | | |
+------------------------+-----------------------------------------+-------------+

The IANA Functions 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 2019-08-28):

From: The IESG
To: IETF-Announce
CC: db3546@att.com, draft-ietf-pce-stateful-path-protection@ietf.org, pce@ietf.org, pce-chairs@ietf.org, Julien Meuric , julien.meuric@orange.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (PCEP Extensions for Associating Working and Protection LSPs with 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 Associating Working
and Protection LSPs with
  Stateful PCE'
  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 2019-08-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


  An active stateful Path Computation Element (PCE) is capable of
  computing as well as controlling via Path Computation Element
  Communication Protocol (PCEP) Multiprotocol Label Switching Traffic
  Engineering Label Switched Paths (MPLS LSP).  Furthermore, it is also
  possible for an active stateful PCE to create, maintain, and delete
  LSPs.  This document describes PCEP extension to associate two or
  more LSPs to provide end-to-end path protection.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-path-protection/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-path-protection/ballot/


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

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(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 technical specification of 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

  An active stateful Path Computation Element (PCE) is capable of
  computing as well as controlling via Path Computation Element
  Communication Protocol (PCEP) Multiprotocol Label Switching Traffic
  Engineering Label Switched Paths (MPLS LSP).  Furthermore, it is also
  possible for an active stateful PCE to create, maintain, and delete
  LSPs.  This document describes PCEP extension to associate two or
  more LSPs to provide end-to-end path protection.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
-> N/A

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? 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? 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?
-> One implementation is confirmed and at least 2 more have been placed on product roadmaps.

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 has been reviewed, updated and is ready to progress.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
-> No (We trust the RFC Editor to catch the few remaining nits.)

(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 reflects WG consensus, extending a generic mechanism defined by the WG and involving several companies on the document.

(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.)
-> N/A

(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.
-> A reference to a living I-D will need to be kept to the latest version.

(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

(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?
-> The base mechanism that is extended has previously been sent to the IESG.

(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.
-> No

(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 8126).
-> The IANA section is consistent with the document's body. A new sub-registry is defined for a flag field, initial values are listed.

(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

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(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 technical specification of 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

  An active stateful Path Computation Element (PCE) is capable of
  computing as well as controlling via Path Computation Element
  Communication Protocol (PCEP) Multiprotocol Label Switching Traffic
  Engineering Label Switched Paths (MPLS LSP).  Furthermore, it is also
  possible for an active stateful PCE to create, maintain, and delete
  LSPs.  This document describes PCEP extension to associate two or
  more LSPs to provide end-to-end path protection.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
-> N/A

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? 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? 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?
-> One implementation is confirmed and at least 2 more have been placed on product roadmaps.

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 has been reviewed, updated and is ready to progress.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
-> No (We trust the RFC Editor to catch the few remaining nits.)

(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 reflects WG consensus, extending a generic mechanism defined by the WG and involving several companies on the document.

(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.)
-> N/A

(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.
-> A reference to a living I-D will need to be kept to the latest version.

(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

(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?
-> The base mechanism that is extended has previously been sent to the IESG.

(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.
-> No

(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 8126).
-> The IANA section is consistent with the document's body. A new sub-registry is defined for a flag field, initial values are listed.

(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: Colby Barth , Edward Crabbe , Siva Sivabalan , Hariharan Ananthakrishnan , Ina Minei , pce-chairs@ietf.org, Raveendra Torvi , Mahendra Negi

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(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 technical specification of 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

  An active stateful Path Computation Element (PCE) is capable of
  computing as well as controlling via Path Computation Element
  Communication Protocol (PCEP) Multiprotocol Label Switching Traffic
  Engineering Label Switched Paths (MPLS LSP).  Furthermore, it is also
  possible for an active stateful PCE to create, maintain, and delete
  LSPs.  This document describes PCEP extension to associate two or
  more LSPs to provide end-to-end path protection.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
-> N/A

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? 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? 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?

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 has been reviewed, updated and is ready to progress.

(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 reflects WG consensus, extending a generic mechanism defined by the WG and involving several companies on the document.

(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.)
-> N/A

(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.
-> Done

(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

(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?
-> The base mechanism that is extended has previously been sent to the IESG.

(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.
-> No

(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 8126).
-> The IANA section is consistent with the document's body. A new sub-registry is defined for a flag field, initial values are listed.

(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: Colby Barth , Edward Crabbe , Siva Sivabalan , Hariharan Ananthakrishnan , Ina Minei , Raveendra Torvi , Mahendra Negi

Request for posting confirmation emailed to previous authors: Colby Barth , Edward Crabbe , Siva Sivabalan , Hariharan Ananthakrishnan , Ina Minei , Raveendra Torvi , Mahendra Negi

Request for posting confirmation emailed to previous authors: Colby Barth , Edward Crabbe , Siva Sivabalan , Dhruv Dhody , Hariharan Ananthakrishnan , Ina Minei , pce-chairs@ietf.org, Raveendra Torvi

Request for posting confirmation emailed to previous authors: Colby Barth , Edward Crabbe , Hariharan Ananthakrishnan , Siva Sivabalan , Dhruv Dhody , Ina Minei , pce-chairs@ietf.org, Raveendra Torvi

Request for posting confirmation emailed to previous authors: Colby Barth , Edward Crabbe , Hariharan Ananthakrishnan , Siva Sivabalan , Dhruv Dhody , Ina Minei , Raveendra Torvi

Request for posting confirmation emailed to previous authors: Colby Barth , Edward Crabbe , Hariharan Ananthakrishnan , Siva Sivabalan , Dhruv Dhody , Ina Minei , Raveendra Torvi