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 |