Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling
draft-ietf-pce-association-diversity-15

[Ballot discuss]
* Section 5.3:
  Given the fairly relaxed handling of multiple OF-codes ("the receiver MUST consider the first OF-code only and ignore others if included") I think the error handling as specified in

"the OF-code inside the OF Object MUST include one of the disjoint OFs defined in this document. If this condition is not met, the PCEP speaker MUST..."

needs to be tightened a bit since all the OF-codes but the first are ignored for processing but still considered for error handling. Suggest something like this

OLD:
the OF-code inside the OF Object MUST include one of the disjoint OFs defined in this document.

NEW:
the first OF-code inside the OF Object MUST be one of the disjoint OFs defined in this document.

[Ballot comment]
Looks like the placeholder TBD8 is being used for two totally different purposes (a new bit in the NO-PATH-VECTOR TLV and the Error-value for DISJOINTNESS-CONFIGURATION-TLV missing) and this is confusing. Please deconflict.

[Ballot comment]
Section 6.  Per “Also, as stated in [I-D.ietf-pce-association-group], much of the information carried in the Disjointness Association object, as per this document is not extra sensitive”, I appreciate that the language of “not extra sensitive” comes from Section 8 of draft-ietf-pce-association-group and this text is merely trying to reiterate this observation.  However, I would recommend not making any assumptions about the particular environments by stating the following:

OLD:
Also, as stated in [I-D.ietf-pce-association-group], much of the information carried in the Disjointness Association object, as per this document is not extra sensitive.  It often reflects information that can also be derived from the LSP Database, but association provides a much easier grouping of related LSPs and messages.  The disjointness association could provide an adversary with the opportunity to eavesdrop on the relationship between the LSPs.

NEW
Also, as stated in [I-D.ietf-pce-association-group], much of the information carried in the Disjointness Association object reflects information that can also be derived from the LSP Database, but association provides a much easier grouping of related LSPs and messages.  The disjointness association could provide an adversary with the opportunity to eavesdrop on the relationship between the LSPs and understand the network topology.

[Ballot discuss]
A couple of the points from the Gen-ART review warrant discussion I think (quoting directly from the review):

(1) 'The relationship of this mechanism with SVEC seems to be important but
is not clearly stated.  The relevant sections of the text seem to be:
section 4 para 2, section 5.3, and section 5.4 from "[RFC5440] uses
SVEC diversity flag" on.  I think that they need to be pulled into one
section.  Then it will be possible to have a good description of the
interaction with SVEC.'

(2) 'The path computation effects of the P bit are described in the "P"
item in section 5.2 and section 5.5.  But the descriptions are
unclear, or perhaps they presume that there are only two LSPs in the
group.  I think the intended meaning is that all of the LSPs in the
group with P=1 are computed first, and then with those LSPs fixed, the
LSPs in the group with P=0 are computed.  This will cause
shortest-path constraints (and other objective functions) to be
optimized on the P=1 LSPs, and those paths will not be de-optimized by
competition from the other paths.  This should probably be pulled out
of the description of the "P" in its TLV and put into a separate
paragraph.'

[Ballot comment]
Thank you for the work put into this document. The document is easy to read. I just have a minor comment (feel free to ignore it) about section 1: an early definition of 'disjoint group' would be welcome (at least for readers, like myself, who are not familiar with PCE). Even if section 3 provides more information.

Regards,

-éric

[Ballot comment]
Thanks for this generally well-written document!  Most of my comments are
pretty minor, but please do note the edge case in objective function
handling, the question about which TLVs are allowed when the ASSOCIATION
object is carried in which messages, the notation clarification question,
and the question about what "completely relax the disjointness constraint"
means.

Please check the TBD placeholders; it looks like (e.g.) TBD8 is used for
both a NO-PATH-VECTOR TLV bit and for an error code (but I didn't
double-check the others).

As a general comment (but mostly for my own curiousity), I'm curious whether
you predict much usage of the DAG association type with none of the L/N/S/T
bits set in the configuration, effectively using the association to carry
the new objective function(s) from this document.

Section 5.1

  A disjoint group can have two or more LSPs, but a PCE may be limited
  in the number of LSPs it can take into account when computing
  disjointness.  If a PCE receives more LSPs in the group than it can
  handle in its computation algorithm, it SHOULD apply disjointness
  computation to only a subset of LSPs in the group.  The subset of
  disjoint LSPs will be decided by PCE as a local policy.  Local

Just to double-check: this "only apply disjointness to a subset, using local
policy" behavior is preferred to returning an error for the last LSP
attempting to join the group?  I do see that the relaxation of disjointness
is reported back via the DISJOINTNESS-STATUS-TLV, so at least there
shouldn't be surprises about what's (not) happening, unless the PCE decides
to not send that TLV for some reason.

  of T, S, N, L flags in the DISJOINTNESS-CONFIGURATION-TLV.  If a PCEP
  peer receives a PCEP messages for LSPs belonging to the same disjoint
  group but having an inconsistent combination of T, S, N, L flags, the
  PCEP peer MUST NOT try to add the LSPs in disjoint group and MUST
  reply with a PCErr with Error-type 26 (Association Error) and Error-
  Value 6 (Association information mismatch).

nit: s/in disjoint group/to the disjoint group/

  A particular LSP MAY be associated to multiple disjoint groups, but
  in that case, the PCE SHOULD try to consider all the disjoint groups
  during path computation if possible.  Otherwise a local policy MAY
  define the computational behavior.  If a PCE does not support such a
  path computation it MUST NOT add the LSP into association group and
  return a PCErr with Error-type 26 (Association Error) and Error-Value
  7 (Cannot join the association group).

It's interesting that "be in multiple disjoint groups" gets error-on-failure
semantics but (above) "too many LSPs in a single group" gets
degrade-and-report semantics.  But it's clearly documented, so I don't see
any problems per se.

Section 5.2

It looks like we only talk about which messages carry the
DISJOINTNESS-STATUS-TLV; is the implication that the other TLVs are not
restricted in which message can carry them a correct one?  (Also, that
DISJOINTNESS-CONFIGURATION-TLV must be present even in PCRep?)

  The disjoint group MUST carry the following TLV:

Since we're talking about protocol elements now, I'd suggest to explicitly
say "TBD1 Disjoint Association Type group" or something else that clearly
identifies the association-group as a protocol element.

  In addition, the disjoint group MAY carry the following TLV:

nit: "TLVs" plural.

  If a PCEP speaker receives a disjoint-group without DISJOINTNESS-
  CONFIGURATION-TLV, it SHOULD reply with a PCErr Error-type=6
  (Mandatory Object missing) and Error-value=TBD8 (DISJOINTNESS-
  CONFIGURATION-TLV missing).

I suggest being more explicit about (e.g) "ASSOCIATION object of type TBD1",
since "disjoint-group" is somewhat of a colloquialism.

Seciion 5.3

  An objective function (OF) MAY be applied to the disjointness
  computation to drive the PCE computation behavior.  In this case, the
  OF-List TLV (defined in ([RFC5541]) is used as an optional TLV in the
  Association Group Object.  Whereas the PCEP OF-List TLV allows
  multiple OF-codes inside the TLV, a sender SHOULD include a single
  OF-code in the OF-List TLV when included in the Association Group,
  and the receiver MUST consider the first OF-code only and ignore
  others if included.

This usage seems a little weird (albeit unlikely to be problematic), since
RFC 5441 uses the OF-List TLV to indicate what OFs are supported, and has it
carried in the OPEN object, with a dedicated OF object used to indicate the
particular OF requested/used for a given path computation.  Repurposing the
TLV to now be a container for the requested OF for a specific computation
feels like a qualitatively different usage than the original one.

  MSL
    [...]
      *  A path P passes through K links {Lpi,(i=1...K)}.

      *  A set of paths {P1...Pm} have L links that are common to more
        than one path {Lpi,(i=1...L)}.

Can you double-check the notation here?  In the first quoted item it seems
that Lpi indicates the i-th link on path P, but in the second it looks like
Lpi indicates the i-th link in common across paths P1...Pm.  I'd suggest
using a different term for the different meaning.

  MSS
  [...]
      *  A path P passes through K links {Lpi,(i=1...K)} belonging to
        unique M SRLGs {Spi,(i=1..M)}.

What is the relationship between K and M?  Is it always true that M <= K?

      *  A set of paths {P1...Pm} have L SRLGs that are common to more
        than one path {Spi,(i=1...L)}.

[same comment about terminology reuse]

  MSN
      [...]
      *  A path P passes through K nodes {Npi,(i=1...K)}.

      *  A set of paths {P1...Pm} have L nodes that are common to more
        than one path {Npi,(i=1...L)}.

[same comment about terminology reuse]

  If the OF-list TLV is included in the Association Object, the OF-code
  inside the OF Object MUST include one of the disjoint OFs defined in
  this document.  If this condition is not met, the PCEP speaker MUST
  respond with a PCErr message with Error-Type=10 (Reception of an
  invalid object) and Error-Value=TBD9 (Incompatible OF code).

Looking at edge cases, I think that the MUST-level requirements allow for me
to send an OF-list TLV with two items the first of which is nonsense (i.e.,
not one of these three), and the second of which is one of these three.  The
recipient would be obligated to use the first one in the list (by the
previous text "the receiver MUST consider the first OF-code only") despite
it being nonsensical.  We should probably try to close that edge case,
though there are several approaches to choose from and I don't have a sense
for what might cause us to prefer one over the other.

Section 5.4

  SVEC object.  The PCE MUST consider both the objects as per the
  processing rules and aim to find a path that meets both of these
  constraints.  In case no such path is possible, the PCE MUST send a
  path computation reply (PCRep) with a NO-PATH object indicating path
  computation failure as per [RFC5440].  It should be noted that the

I would consider reminding the reader that the 'T' bit controls how strictly
the PCE needs to interpret the DAG constraints, and thus that it's possible
for the PCE to degrade the request without needint to return NO-PATH in such
cases.

Section 5.5

  into account the disjointness constraint.  Setting P flag changes the
  relationship between LSPs to a one-sided relationship (LSP 1 with P=0
  depends of LSP 2 with P=1, but LSP 2 with P=1 does not depend of LSP
  1 with P=0).  Multiple LSPs in the same disjoint group may have the P

nits: "Setting the P flag", "depends on LSP 2"

I suggest specifying "link disjoint" for at least the example using Figure 4
(if not the one using Figure 3 as well), since the paths
PE1->R1->R4->R2->PE2 and PE3->R3->R4->PE4 are not node-disjoint.

Section 5.6

  There are some cases where the PCE may need to completely relax the
  disjointness constraint in order to provide a path to all the LSPs
  that are part of the association.  A mechanism that allows the PCE to
  fully relax a constraint is considered by the authors as more global
  to PCEP rather than linked to the disjointness use case.  As a
  consequence, it is considered as out of scope of the document.

I'm not sure how to interpret this.  Is it supposed to prevent a PCE from
falling back to "no disjointness" (e.g., all of L/N/S/T are clear in
DISJOINTNESS-STATUS-TLV)?  If so, I would have expected this limitation to
be spelled out more clearly much earlier in the document.

Section 6

I suggest also mentioning the security considerations of RFC 7470, as we
have very little control over what information goes in
VENDOR-INFORMATION-TLV.  (Not that there's a whole lot of content there, but
maybe it will get people thinking.)

I might also consider mentioning again that certain combinations of flags
(notably, the 'T' bit) can result in unsatisfiable requests.  But that's
only somewhat a "security" consideration; security aspects only really come
into play for it if someone is spoofing that T bit, and we already recommend
TLS.

Section 8.1

  Range MUST be allowed to be set by the operator.  Operator SHOULD be
  allowed to set the local policies to define various disjoint

nit: The operator"

Section 8.2

  associations configured or created dynamically.  Further
  implementation SHOULD allow to view disjoint associations reported by
  each peer, and the current set of LSPs in this association.  The PCEP

nit: "Furthermore, implementations"

Section 8.4

  Mechanisms defined in this document do not imply any new operation
  verification requirements in addition to those already listed in
  [RFC5440].

We don't think that someone should check that the computed LSPs actually
supply the disjointness properties they're claimed to provide?

Section 10.2

I guess a strict reading of
https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/
would require RFC 7470 to be a normative reference, but that doesn't really
seem like the right thing to do for this specific case.

On the other hand, a RECOMMENDation for RFC 8253's use does feel like it
would place it as a normative reference.

[Ballot comment]
(1) §5.1: I-D.ietf-pce-association-group is not explicit about the "capability exchange mentioned in this piece of text:

                This capability exchange for the Disjointness
  Association Type (TBD1) MUST be done before using the disjointness
  association.  Thus the PCEP speaker MUST include the Disjointness
  Association Type in the ASSOC-Type-List TLV before using the Disjoint
  Association Group (DAG) in PCEP messages.

It seems to me that the exchange implies sending and receiving the Assoc-type, but then the second sentence implies sending to be enough.  What is the expected behavior?  Please reword.


(2) §5.2 says, while defining the T flag, says that "if disjoint paths cannot be found, PCE SHOULD return no path", but §5.6 reads:

  When the T flag is set (Strict disjointness requested), if
  disjointness cannot be ensured for one or more LSPs, the PCE MUST
  reply to a Path Computation Request (PCReq) with a Path Computation
  Reply (PCRep) message containing a NO-PATH object. 

There is a conflict between the SHOULD and the MUST.


(3) TBD1 is used with 3 different names: "Disjoint Association Type (DAT)", "Disjointness Association Type" and "Disjoint-group Association".  Please be consistent.


(4) [nits]

s/DISJOINTNESS-CONFIGURATION-TLVSection 5.2/DISJOINTNESS-CONFIGURATION-TLV (Section 5.2)

s/SHOULD NOT try to add/SHOULD NOT add

s/with example inA Section 5.5/with an example in Section 5.5

s/by Section 5.5either/by either

s/Setting P flag/Setting the P flag

s/case of network event/case of a network event

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

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

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

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

IANA understands that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document:

[I-D.ietf-pce-association-group]

First, in the Association Type registry to be created by section 7.4 of [I-D.ietf-pce-association-group], a new registration is to be made as follows:

Type: [ TBD-at-Registration ]
Name: Disjoint-group Association
Reference: [ RFC-to-be ]

Second, 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/

two, new registrations are to be made as follows:

TLV Type: [ TBD-at-Registration ]
TLV Name: Disjointness Configuration TLV
Reference: [ RFC-to-be ]

TLV Type: [ TBD-at-Registration ]
TLV Name: Disjointness Status TLV
Reference: [ RFC-to-be ]

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

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

The new registry is managed via Standards Action as defined by [RFC8126]. There are initial registrations in the new registry as follows:

+------------+-------------------------+-------------+
| Bit Number | Name | Reference |
+------------+-------------------------+-------------+
| 31 | L - Link Diverse |[ RFC-to-be ]|
| 30 | N - Node Diverse |[ RFC-to-be ]|
| 29 | S - SRLG Diverse |[ RFC-to-be ]|
| 28 | P - Shortest Path |[ RFC-to-be ]|
| 27 | T - Strict Disjointness |[ RFC-to-be ]|
+------------+-------------------------+-------------+

IANA Question --> Should bits 26-0 be marked as unassigned in the new registry?

Fourth, in the Objective Function registry, also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

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

three, new registrations are to be made as follows:

Code Point: [ TBD-at-Registration ]
Name: Minimize the number of shared Links (MSL)
Reference: [ RFC-to-be ]

Code Point: [ TBD-at-Registration ]
Name: Minimize the number of shared SRLGs (MSS)
Reference: [ RFC-to-be ]

Code Point: [ TBD-at-Registration ]
Name: Minimize the number of shared Nodes (MSN)
Reference: [ RFC-to-be ]

Fifth, in the NO-PATH-VECTOR TLV Flag Field registry, also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

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

two, new registrations are to be made as follows:

Bit: [ TBD-at-Registration ]
Description: Disjoint path not found
Reference: [ RFC-to-be ]

Bit: [ TBD-at-Registration ]
Description: Requested disjoint computation not supported
Reference: [ RFC-to-be ]

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

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

Error-Type 6, Mandatory Object missing will have a new Error-value added as follows:

[ TBD-at-Registration ]: DISJOINTNESS-CONFIGURATION TLV missing
Reference: [ RFC-to-be ]

and, Error-Type 10, Reception of an invalid object will have a new Error-value added as follows:

[ TBD-at-Registration ]: Incompatible OF code
Reference: [ 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-10-18):

From: The IESG
To: IETF-Announce
CC: db3546@att.com, draft-ietf-pce-association-diversity@ietf.org, pce@ietf.org, pce-chairs@ietf.org, Julien Meuric , julien.meuric@orange.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Path Computation Element Communication Protocol (PCEP) Extension for LSP Diversity Constraint Signaling) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'Path Computation Element Communication
Protocol (PCEP) Extension for
  LSP Diversity Constraint Signaling'
  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-10-18. 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


  This document introduces a simple mechanism to associate a group of
  Label Switched Paths (LSPs) via an extension to the Path Computation
  Element (PCE) communication Protocol (PCEP) with the purpose of
  computing diverse paths for those LSPs.  The proposed extension
  allows a Path Computation Client (PCC) to advertise to a PCE that a
  particular LSP belongs to a disjoint-group, thus the PCE knows that
  the LSPs in the same group need to be disjoint from each other.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-association-diversity/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pce-association-diversity/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3493/

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

  This document introduces a simple mechanism to associate a group of
  Label Switched Paths (LSPs) via an extension to the Path Computation
  Element (PCE) Communication Protocol (PCEP) with the purpose of
  computing diverse paths for those LSPs.  The proposed extension
  allows a Path Computation Client (PCC) to advertise to a PCE that a
  particular LSP belongs to a disjoint-group, thus the PCE knows that
  LSPs in the same group need to be disjoint from each other.

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?
-> At least 3 implementations 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.
-> Yes. The disclosure was notified during WG last call. The WG was requested to share any concern: since none has showed up, the normal process resumes, as proposed.

(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

  This document introduces a simple mechanism to associate a group of
  Label Switched Paths (LSPs) via an extension to the Path Computation
  Element (PCE) Communication Protocol (PCEP) with the purpose of
  computing diverse paths for those LSPs.  The proposed extension
  allows a Path Computation Client (PCC) to advertise to a PCE that a
  particular LSP belongs to a disjoint-group, thus the PCE knows that
  LSPs in the same group need to be disjoint from each other.

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?
-> At least 3 implementations 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.
-> Yes. The disclosure was notified during WG last call. The WG was requested to share any concern: since none has showed up, the normal process resumes, as proposed.

(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

  This document introduces a simple mechanism to associate a group of
  Label Switched Paths (LSPs) via an extension to the Path Computation
  Element (PCE) Communication Protocol (PCEP) with the purpose of
  computing diverse paths for those LSPs.  The proposed extension
  allows a Path Computation Client (PCC) to advertise to a PCE that a
  particular LSP belongs to a disjoint-group, thus the PCE knows that
  LSPs in the same group needs to be disjoint from each other.

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?
-> At least 3 implementations 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.
-> Yes. The disclosure was notified during WG last call. The WG was requested to share any concern: since none has showed up, the normal process resumes, as proposed.

(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

  This document introduces a simple mechanism to associate a group of
  Label Switched Paths (LSPs) via an extension to the Path Computation
  Element (PCE) Communication Protocol (PCEP) with the purpose of
  computing diverse paths for those LSPs.  The proposed extension
  allows a Path Computation Client (PCC) to advertise to a PCE that a
  particular LSP belongs to a disjoint-group, thus the PCE knows that
  LSPs in the same group needs to be disjoint from each other.

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?
-> At least 3 implementations 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.
-> Yes. The disclosure was notified during WG last call. The WG was requested to share any concern: since none has showed up, the normal process resumes, as proposed.

(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