Skip to main content

Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)
draft-ietf-pce-association-bidir-14

Revision differences

Document history

Date Rev. By Action
2021-06-21
14 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-06-14
14 (System) RFC Editor state changed to AUTH48
2021-04-05
14 (System) IANA Action state changed to RFC-Ed-Ack from In Progress
2021-03-25
14 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-03-11
14 (System) IANA Action state changed to In Progress from Waiting on RFC Editor
2021-03-11
14 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-03-11
14 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-03-10
14 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-03-05
14 (System) RFC Editor state changed to EDIT
2021-03-05
14 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-03-05
14 (System) Announcement was received by RFC Editor
2021-03-05
14 (System) IANA Action state changed to In Progress
2021-03-05
14 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2021-03-05
14 Cindy Morgan IESG has approved the document
2021-03-05
14 Cindy Morgan Closed "Approve" ballot
2021-03-05
14 Cindy Morgan Ballot writeup was changed
2021-03-05
14 Deborah Brungard Ballot approval text was changed
2021-02-21
14 Rakesh Gandhi New version available: draft-ietf-pce-association-bidir-14.txt
2021-02-21
14 (System) New version accepted (logged-in submitter: Rakesh Gandhi)
2021-02-21
14 Rakesh Gandhi Uploaded new revision
2021-02-19
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-02-19
13 Rakesh Gandhi New version available: draft-ietf-pce-association-bidir-13.txt
2021-02-19
13 (System) New version accepted (logged-in submitter: Rakesh Gandhi)
2021-02-19
13 Rakesh Gandhi Uploaded new revision
2021-02-18
12 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2021-02-18
12 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2021-02-18
12 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2021-02-17
12 Murray Kucherawy
[Ballot comment]
I agree with Barry that the Abstract in its current form feels kind of cluttered.  Anything we could do to tidy that up …
[Ballot comment]
I agree with Barry that the Abstract in its current form feels kind of cluttered.  Anything we could do to tidy that up would help.  I wonder how it might look with all the acronyms removed, and instead introduce them down in the Introduction or later sections.

Alvaro also raises a good point, and I'd like to see that addressed somehow.
2021-02-17
12 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-02-17
12 Benjamin Kaduk
[Ballot comment]
Alvaro makes a good point, and I'm interested in seeing the updates
made in response to it.

Section 4.1

  As per [ …
[Ballot comment]
Alvaro makes a good point, and I'm interested in seeing the updates
made in response to it.

Section 4.1

  As per [RFC8697], LSPs are associated by adding them to a common
  association group.  This document defines two new Association Types,
  called "Single-sided Bidirectional LSP" (TBD1) and "Double-sided
  Bidirectional LSP" (TBD2), based on the generic ASSOCIATION Object
  ((Object-Class value 40).  [...]

(nit) pedantically I might say that these are instances of the
ASSOCIATION object, as "based on" carries some connotation that they are
distinct but similar.  So this might become "using the generic
ASSOCIATION Object" or "for the generic ASSOCIATION Object".

  o  The Tunnel (as defined in [RFC3209]) containing the forward and
      reverse LSPs of the Single-sided Bidirectional LSP Association on
      the originating node MUST have the same LSP parameters (as
      described in section 3.1.1 of [RFC3209]), albeit both LSPs have
      reversed endpoint nodes.

There is no Section 3.1.1 of RFC 3209 (and it hardly talks about
"parameters", either).

  The Association ID, Association Source, optional Global Association
  Source and optional Extended Association ID in the Bidirectional LSP
  Association Object are initialized using the procedures defined in
  [RFC8697] and [RFC7551].

(nit?) Is it better to talk about Global Association Source and Extended
Association IDs as being TLVs?

Section 4.2

The new TLV has a flag to indicate the forward LSP, but the
forward/reverse directionality is also indicated by the respective node
addresses (for double-sided bidirectional LSPs); is there any protocol
element that should check and enforce consistency of the two
representations?

[I was going to ask about some other error handling cases here, but I
see that Section 5.7 already covers many of them -- thank you!]

If I understand correctly, the F and R flags are mutually exclusive.
Can/should that also be enforced (and with what error handling)?  I
don't think I understand why they are separate bits instead of just a
single bit (e.g., 1 for forward and 0 for reverse).

Section 5.1

Some nits in the last four bullet points: IIUC all should start with the
plural "Stateful PCEs" (for consistency), and then the verbs in the last
two would have to be adjusted to match, so "Stateful PCEs establish and
remove", and "Stateful PCEs create and update".

Section 5.2

Similarly (also nit-level), the bullet points here should probably all
use the "PCCs" plural form for consistency, and some verb conjugations
would need adjustment to match.

Section 5.4

Just to check my understanding: this text is saying that whenever you
use the bidirectional LSP association group, you also set the B flag in
the request parameters?

Section 5.5

                                              There is no change in the
  PLSP-ID allocation procedure for the forward LSP of the Single-sided
  Bidirectional LSP on the originating endpoint node.  In case of
  Double-sided Bidirectional LSP Association, there is no change in the
  PLSP-ID allocation procedure.

This snippet carefully does not say anything about the PLSP-ID
allocation procedures for the reverse LSP of a single-sided
bidirectional association.  Do those procedures change?

Section 5.7

  If a PCE speaker receives an LSP with a Bidirectional LSP Association
  Type that it does not support, the PCE speaker MUST send PCErr with
  Error-Type = 26 (Association Error) and Error-Value = 1 (Association
  Type is not supported).

This reads a little bit (but not entirely) like it's binding the
behavior of implementations that don't implement this specification,
which generally doesn't make sense to attempt to do.
(But IIRC this is the behavior required by the core spec anyway, so it
wouldn't really matter.)

Section 9.2.1

  o  Bit number (count from 0 as the most significant bit)

Thank you for including this detail!

Section 10.2

The "RECOMMENDED" for RFC 8253 usage might arguably promote it to
normative (per
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/).
2021-02-17
12 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2021-02-17
12 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-02-17
12 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-02-17
12 Warren Kumari [Ballot comment]
Thanks to the OpsDir reviewer (Al Morton) for reviewing and providing suggestions on this document, and the author for working though them.
2021-02-17
12 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2021-02-17
12 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2021-02-16
12 Martin Duke
[Ballot comment]
The figures in Section 3 repeatedly state use the phrase "reports the reverse LSP1
  (not shown for simplicity)". Not being an expert …
[Ballot comment]
The figures in Section 3 repeatedly state use the phrase "reports the reverse LSP1
  (not shown for simplicity)". Not being an expert in these technologies, I found the consistent omission of this from the figure to be confusing, not clarifying.
2021-02-16
12 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2021-02-16
12 Roman Danyliw [Ballot comment]
Thank you to Chris Lonvick for the SECDIR review.
2021-02-16
12 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2021-02-16
12 Alvaro Retana
[Ballot comment]
This document defines extensions that can be used in different modes of operation (§3.4).  However, there is no operational guidance related to the …
[Ballot comment]
This document defines extensions that can be used in different modes of operation (§3.4).  However, there is no operational guidance related to the advantages/disadvantages or considerations of using each of them.  Are there cases (beyond implementation support) when one mode could be preferred?  If all modes are supported, how should an operator choose?

I believe that the specification is incomplete without this type of guidance, but I am not making this point a DISCUSS hoping that it will be easy for the authors to address.
2021-02-16
12 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-02-15
12 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. I must admit that this document was too deep in PCE for a full …
[Ballot comment]
Thank you for the work put into this document. I must admit that this document was too deep in PCE for a full review of mine, I am trusting my routing AD peers for this review.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
-- Section 3 --
Figure 2, should there be a LSP2 label on the link between C and F (as well as between E and B) ? At the risk of overloading the figure though...

-- Section 3.1.1 --
Suggest to mention that the topology of figure 1 is reused.

== NITS ==

-- Section 1 --
Is "Path Control Element (PCE)" correct or is it "Path Computation Element (PCE) " (per RFC Editor abbreviation list) ?
2021-02-15
12 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-02-05
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-02-05
12 Rakesh Gandhi New version available: draft-ietf-pce-association-bidir-12.txt
2021-02-05
12 (System) New version accepted (logged-in submitter: Rakesh Gandhi)
2021-02-05
12 Rakesh Gandhi Uploaded new revision
2021-02-02
11 Barry Leiba
[Ballot comment]
Thanks for an easy read.  I just have two very small comments:

— Abstract —

  The Path Computation Element Communication Protocol (PCEP) …
[Ballot comment]
Thanks for an easy read.  I just have two very small comments:

— Abstract —

  The Path Computation Element Communication Protocol (PCEP) provides
  mechanisms for Path Computation Elements (PCEs) to perform path
  computations in response to Path Computation Clients (PCCs) requests.
  The Stateful PCE extensions allow stateful control of Multiprotocol
  Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
  (LSPs) using PCEP.

Hm.  I’m not clear here: Does this have something to do with path computation?

He-he... seriously, I understand the repetition, given the expansion of the abbreviations.  What I wonder is whether it’s necessary to put all those terms into the Abstract, given that the expansion of "PCEP" already includes "path computation element".  What do you think about shortening the Abstract thus?:

SUGGESTION
  This document defines Path Computation Element Communication Protocol
  (PCEP) extensions for grouping two unidirectional MPLS-TE Label
  Switched Paths (LSPs), one in each direction in the network, into an
  Associated Bidirectional LSP.  The mechanisms defined in this
  document can be applied using a Stateful PCE for both PCE-Initiated
  and PCC-Initiated LSPs, as well as when using a Stateless PCE.  The
  procedures defined are applicable to the LSPs using RSVP-TE for
  signaling.
END

I note that "MPLS-TE", "PCE", and "RSVP-TE" are all in the RFC Editor’s list of abbreviations that don’t need expansion... though, of course, you can put the expansions back in if you prefer.  I also note that "PCC" is not, but I think it would be awkward to include the expansion of "PCC" here, so maybe we can manage without it in the Abstract.

— Section 3.1 —

  Both endpoint nodes act as a PCC.

Nit: "Both" is plural, so either "Both endpoint nodes act as PCCs." or "Each endpoint node acts as a PCC."
2021-02-02
11 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2021-02-01
11 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-02-01
11 Amy Vezza Placed on agenda for telechat - 2021-02-18
2021-02-01
11 Deborah Brungard Ballot has been issued
2021-02-01
11 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2021-02-01
11 Deborah Brungard Created "Approve" ballot
2021-02-01
11 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for Writeup
2021-02-01
11 Deborah Brungard Ballot writeup was changed
2021-01-29
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-01-29
11 Rakesh Gandhi New version available: draft-ietf-pce-association-bidir-11.txt
2021-01-29
11 (System) New version accepted (logged-in submitter: Rakesh Gandhi)
2021-01-29
11 Rakesh Gandhi Uploaded new revision
2021-01-29
10 (System) IESG state changed to Waiting for Writeup from In Last Call
2021-01-28
10 Meral Shirazipour Request for Last Call review by GENART Completed: Ready. Reviewer: Meral Shirazipour. Sent review to list.
2021-01-27
10 Al Morton Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Al Morton. Sent review to list.
2021-01-27
10 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2021-01-27
10 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-pce-association-bidir-10. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-pce-association-bidir-10. 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, ASSOCIATION Type Field 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:

Type: [ TBD-at-Registration ]
Name: Single-sided Bidirectional LSP Association
Reference: [ RFC-to-be ]

Type: [ TBD-at-Registration ]
Name: Double-sided Bidirectional LSP 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 will be made as follows:

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

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

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

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

Bit No. Description Reference
-------------------------------------------------------
31 F - Forward LSP [ RFC-to-be ]
30 R - Reverse LSP [ RFC-to-be ]
29 C - Co-routed Path [ RFC-to-be ]
0-28 Unassigned

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/

Error Type 26 will be modified to add new Error Values as follows:

Error Type Description Reference
---------------------------------------------------------
26 Association Error
Error value: [ TBD-at-Registration ][ RFC-to-be ]
Bidirectional LSP Association - Group Mismatch

Error value: [ TBD-at-Registration ][ RFC-to-be ]
Bidirectional LSP Association - Tunnel Mismatch

Error value: [ TBD-at-Registration ][ RFC-to-be ]
Bidirectional LSP Association - Path Setup Type
Not Supported

Error value: [ TBD-at-Registration ][ RFC-to-be ]
Bidirectional LSP Association - Direction Mismatch

Error value: [ TBD-at-Registration ][ RFC-to-be ]
Bidirectional LSP Association - Co-routed Mismatch

Error value: [ TBD-at-Registration ][ RFC-to-be ]
Bidirectional LSP Association - Endpoint Mismatch

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
2021-01-21
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Al Morton
2021-01-21
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Al Morton
2021-01-20
10 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2021-01-20
10 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2021-01-19
10 Chris Lonvick Request for Last Call review by SECDIR Completed: Ready. Reviewer: Chris Lonvick. Sent review to list.
2021-01-15
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Chris Lonvick
2021-01-15
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Chris Lonvick
2021-01-15
10 Cindy Morgan IANA Review state changed to IANA - Review Needed
2021-01-15
10 Cindy Morgan
The following Last Call announcement was sent out (ends 2021-01-29):

From: The IESG
To: IETF-Announce
CC: db3546@att.com, dd@dhruvdhody.com, draft-ietf-pce-association-bidir@ietf.org, pce-chairs@ietf.org, pce@ietf.org …
The following Last Call announcement was sent out (ends 2021-01-29):

From: The IESG
To: IETF-Announce
CC: db3546@att.com, dd@dhruvdhody.com, draft-ietf-pce-association-bidir@ietf.org, pce-chairs@ietf.org, pce@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)) 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) Extensions for
  Associated Bidirectional Label Switched Paths (LSPs)'
  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
last-call@ietf.org mailing lists by 2021-01-29. 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


  The Path Computation Element Communication Protocol (PCEP) provides
  mechanisms for Path Computation Elements (PCEs) to perform path
  computations in response to Path Computation Clients (PCCs) requests.
  The Stateful PCE extensions allow stateful control of Multiprotocol
  Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
  (LSPs) using PCEP.

  This document defines PCEP extensions for grouping two unidirectional
  MPLS TE LSPs (one in each direction in the network) into an
  Associated Bidirectional LSP.  The mechanisms defined in this
  document can be applied using a Stateful PCE for both PCE-Initiated
  and PCC-Initiated LSPs, as well as when using a Stateless PCE.  The
  procedures defined are applicable to the LSPs using Resource
  Reservation Protocol - Traffic Engineering (RSVP-TE) for signaling.




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


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

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





2021-01-15
10 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2021-01-15
10 Deborah Brungard Last call was requested
2021-01-15
10 Deborah Brungard Ballot approval text was generated
2021-01-15
10 Deborah Brungard Ballot writeup was generated
2021-01-15
10 Deborah Brungard IESG state changed to Last Call Requested from Publication Requested
2021-01-15
10 Deborah Brungard Last call announcement was generated
2021-01-14
10 Min Ye Request closed, assignment withdrawn: Stig Venaas Last Call RTGDIR review
2021-01-14
10 Min Ye Closed request for Last Call review by RTGDIR with state 'Team Will not Review Version'
2021-01-14
10 Min Ye Closed request for Last Call review by RTGDIR with state 'Team Will not Review Version'
2021-01-12
10 Luc André Burdet Assignment of request for Last Call review by RTGDIR to Himanshu Shah was withdrawn
2021-01-12
10 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Himanshu Shah
2021-01-12
10 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Himanshu Shah
2021-01-12
10 Luc André Burdet Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Harish Sitaraman. Submission of review completed at an earlier date.
2021-01-12
10 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Harish Sitaraman
2021-01-12
10 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Harish Sitaraman
2021-01-12
10 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Stig Venaas
2021-01-12
10 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Stig Venaas
2021-01-06
10 Rakesh Gandhi New version available: draft-ietf-pce-association-bidir-10.txt
2021-01-06
10 (System) New version accepted (logged-in submitter: Rakesh Gandhi)
2021-01-06
10 Rakesh Gandhi Uploaded new revision
2020-12-30
09 Min Ye Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Harish Sitaraman.
2020-12-30
10 Luc André Burdet Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Harish Sitaraman.
2020-12-24
09 Min Ye Request for Last Call review by RTGDIR is assigned to Harish Sitaraman
2020-12-24
09 Min Ye Request for Last Call review by RTGDIR is assigned to Harish Sitaraman
2020-12-21
09 Deborah Brungard Requested Last Call review by RTGDIR
2020-12-21
09 Deborah Brungard Requested Last Call review by RTGDIR
2020-12-18
09 Deborah Brungard Requested Last Call review by RTGDIR
2020-12-18
09 Deborah Brungard Requested Last Call review by RTGDIR
2020-12-18
09 Dhruv Dhody
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 …
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 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard. This is appropriate because the draft specifies protocol extensions. The title page identifies the draft as Standards Track.

(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:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

  The Path Computation Element Communication Protocol (PCEP) provides
  mechanisms for Path Computation Elements (PCEs) to perform path
  computations in response to Path Computation Clients (PCCs) requests.
  The Stateful PCE extensions allow stateful control of Multiprotocol
  Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
  (LSPs) using PCEP.

  This document defines PCEP extensions for grouping two unidirectional
  MPLS TE LSPs (one in each direction in the network) into an
  Associated Bidirectional LSP.  The mechanisms defined in this
  document can be applied using a Stateful PCE for both PCE-Initiated
  and PCC-Initiated LSPs, as well as when using a Stateless PCE.  The
  procedures defined are applicable to the LSPs using Resource
  Reservation Protocol - Traffic Engineering (RSVP-TE) for signaling.

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?

There were discussion related to SR bidirectional association (another WG I-D) that led to some clarification in this I-D, but there were no controversies. The consensus behind the document is good, it uses association technique and further work on SR builds on this document.

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, YANG 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?

There is an existing implementation on a vendor product. Substantial review was done by the shepherd, the changes were made to accommodate those. 

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Dhruv Dhody is the Document Shepherd and Deborah Brungard is the Responsible Area Director.

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

    I have done the review of this I-D at various times through the process. A substantial review was also done post WG-LC. In my opinion, the document is ready. The shepherd review provided comments and suggestion to the authors which were handled during the latest update.

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

No

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

No such concerns.

(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. An IPR check was done and all authors responded. https://mailarchive.ietf.org/arch/msg/pce/CMUB1JbyWAx5O-3Lj3Pfytzta0g/

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

One IPR disclosure made early in the process - https://datatracker.ietf.org/ipr/2995/
No comments in the WG related to disclosed IPR.

(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?

This I-D is the PCE counterpart of a document from the TEAS WG. Support was there at adoption time and WGLC; no concern was expressed with publication.

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

No

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

None

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

No formal review is applicable.

(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?

No

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

No downrefs in this document.

(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 clear. It request allocation from existing sub-registry as well as request to create a new one as per RFC 8126.

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

None

(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, YANG modules, etc.

None appropriate.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG module here!
2020-12-18
09 Dhruv Dhody Responsible AD changed to Deborah Brungard
2020-12-18
09 Dhruv Dhody IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2020-12-18
09 Dhruv Dhody IESG state changed to Publication Requested from I-D Exists
2020-12-18
09 Dhruv Dhody IESG process started in state Publication Requested
2020-12-17
09 Dhruv Dhody Changed consensus to Yes from Unknown
2020-12-17
09 Dhruv Dhody Intended Status changed to Proposed Standard from None
2020-12-17
09 Dhruv Dhody
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 …
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 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard. This is appropriate because the draft specifies protocol extensions. The title page identifies the draft as Standards Track.

(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:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

  The Path Computation Element Communication Protocol (PCEP) provides
  mechanisms for Path Computation Elements (PCEs) to perform path
  computations in response to Path Computation Clients (PCCs) requests.
  The Stateful PCE extensions allow stateful control of Multiprotocol
  Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths
  (LSPs) using PCEP.

  This document defines PCEP extensions for grouping two unidirectional
  MPLS TE LSPs (one in each direction in the network) into an
  Associated Bidirectional LSP.  The mechanisms defined in this
  document can be applied using a Stateful PCE for both PCE-Initiated
  and PCC-Initiated LSPs, as well as when using a Stateless PCE.  The
  procedures defined are applicable to the LSPs using Resource
  Reservation Protocol - Traffic Engineering (RSVP-TE) for signaling.

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?

There were discussion related to SR bidirectional association (another WG I-D) that led to some clarification in this I-D, but there were no controversies. The consensus behind the document is good, it uses association technique and further work on SR builds on this document.

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, YANG 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?

There is an existing implementation on a vendor product. Substantial review was done by the shepherd, the changes were made to accommodate those. 

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Dhruv Dhody is the Document Shepherd and Deborah Brungard is the Responsible Area Director.

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

    I have done the review of this I-D at various times through the process. A substantial review was also done post WG-LC. In my opinion, the document is ready. The shepherd review provided comments and suggestion to the authors which were handled during the latest update.

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

No

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

No such concerns.

(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. An IPR check was done and all authors responded. https://mailarchive.ietf.org/arch/msg/pce/CMUB1JbyWAx5O-3Lj3Pfytzta0g/

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

One IPR disclosure made early in the process - https://datatracker.ietf.org/ipr/2995/
No comments in the WG related to disclosed IPR.

(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?

This I-D is the PCE counterpart of a document from the TEAS WG. Support was there at adoption time and WGLC; no concern was expressed with publication.

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

No

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

None

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

No formal review is applicable.

(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?

No

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

No downrefs in this document.

(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 clear. It request allocation from existing sub-registry as well as request to create a new one as per RFC 8126.

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

None

(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, YANG modules, etc.

None appropriate.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG module here!
2020-12-17
09 Dhruv Dhody Tag Doc Shepherd Follow-up Underway cleared.
2020-12-16
09 Rakesh Gandhi New version available: draft-ietf-pce-association-bidir-09.txt
2020-12-16
09 (System) New version accepted (logged-in submitter: Rakesh Gandhi)
2020-12-16
09 Rakesh Gandhi Uploaded new revision
2020-10-21
08 Dhruv Dhody Notification list changed to dd@dhruvdhody.com because the document shepherd was set
2020-10-21
08 Dhruv Dhody Document shepherd changed to Dhruv Dhody
2020-10-21
08 Dhruv Dhody IPR response
https://mailarchive.ietf.org/arch/msg/pce/DhWWE1oIf59tAdgzn4TfRx2cUx8/
https://mailarchive.ietf.org/arch/msg/pce/8x7nmGZxFLXvKCTH4yAV8vL792M/
https://mailarchive.ietf.org/arch/msg/pce/0Uy38PMR4yppWEw0WHzx5TeB2co/
2020-10-21
08 Dhruv Dhody Tag Doc Shepherd Follow-up Underway set.
2020-10-21
08 Dhruv Dhody IETF WG state changed to Waiting for WG Chair Go-Ahead from WG Document
2020-09-15
08 Rakesh Gandhi New version available: draft-ietf-pce-association-bidir-08.txt
2020-09-15
08 (System) New version accepted (logged-in submitter: Rakesh Gandhi)
2020-09-15
08 Rakesh Gandhi Uploaded new revision
2020-09-09
07 Rakesh Gandhi New version available: draft-ietf-pce-association-bidir-07.txt
2020-09-09
07 (System) New version accepted (logged-in submitter: Rakesh Gandhi)
2020-09-09
07 Rakesh Gandhi Uploaded new revision
2020-03-13
06 Rakesh Gandhi New version available: draft-ietf-pce-association-bidir-06.txt
2020-03-13
06 (System) New version accepted (logged-in submitter: Rakesh Gandhi)
2020-03-13
06 Rakesh Gandhi Uploaded new revision
2020-02-04
05 Rakesh Gandhi New version available: draft-ietf-pce-association-bidir-05.txt
2020-02-04
05 (System) New version accepted (logged-in submitter: Rakesh Gandhi)
2020-02-04
05 Rakesh Gandhi Uploaded new revision
2019-09-11
04 Rakesh Gandhi New version available: draft-ietf-pce-association-bidir-04.txt
2019-09-11
04 (System) New version approved
2019-09-11
04 (System) Request for posting confirmation emailed to previous authors: Colby Barth , Rakesh Gandhi , Bin Wen
2019-09-11
04 Rakesh Gandhi Uploaded new revision
2019-03-11
03 Rakesh Gandhi New version available: draft-ietf-pce-association-bidir-03.txt
2019-03-11
03 (System) New version approved
2019-03-11
03 (System) Request for posting confirmation emailed to previous authors: Colby Barth , Rakesh Gandhi , Bin Wen
2019-03-11
03 Rakesh Gandhi Uploaded new revision
2018-11-14
02 Rakesh Gandhi New version available: draft-ietf-pce-association-bidir-02.txt
2018-11-14
02 (System) New version approved
2018-11-14
02 (System) Request for posting confirmation emailed to previous authors: Colby Barth , Rakesh Gandhi , Bin Wen
2018-11-14
02 Rakesh Gandhi Uploaded new revision
2018-05-18
01 Rakesh Gandhi New version available: draft-ietf-pce-association-bidir-01.txt
2018-05-18
01 (System) New version approved
2018-05-18
01 (System) Request for posting confirmation emailed to previous authors: Colby Barth , Rakesh Gandhi , Bin Wen
2018-05-18
01 Rakesh Gandhi Uploaded new revision
2018-04-30
00 Jonathan Hardwick This document now replaces draft-barth-pce-association-bidir instead of None
2018-04-30
00 Rakesh Gandhi New version available: draft-ietf-pce-association-bidir-00.txt
2018-04-30
00 (System) WG -00 approved
2018-04-27
00 Rakesh Gandhi Set submitter to "Rakesh Gandhi ", replaces to draft-barth-pce-association-bidir and sent approval email to group chairs: pce-chairs@ietf.org
2018-04-27
00 Rakesh Gandhi Uploaded new revision