Techniques to Improve the Scalability of RSVP-TE Deployments
RFC 8370
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-12-19 |
09 | (System) | Received changes through RFC Editor sync (changed abstract to 'Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the ... Received changes through RFC Editor sync (changed abstract to 'Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed. This document defines two techniques, Refresh-Interval Independent RSVP (RI-RSVP) and Per-Peer Flow Control, that reduce the number of processing cycles required to maintain RSVP-TE LSP state in Label Switching Routers (LSRs) and hence allow implementations to support larger scale deployments.') |
2018-05-11 |
09 | (System) | Received changes through RFC Editor sync (created alias RFC 8370, changed title to 'Techniques to Improve the Scalability of RSVP-TE Deployments', changed abstract to 'Networks ... Received changes through RFC Editor sync (created alias RFC 8370, changed title to 'Techniques to Improve the Scalability of RSVP-TE Deployments', changed abstract to 'Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed.', changed pages to 11, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-05-11, changed IESG state to RFC Published) |
2018-05-11 |
09 | (System) | RFC published |
2018-05-10 |
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-04-24 |
09 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-04-16 |
09 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-02-21 |
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-02-21 |
09 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2018-02-20 |
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-02-20 |
09 | (System) | RFC Editor state changed to EDIT |
2018-02-20 |
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-02-20 |
09 | (System) | Announcement was received by RFC Editor |
2018-02-15 |
09 | (System) | IANA Action state changed to In Progress |
2018-02-15 |
09 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-02-15 |
09 | Amy Vezza | IESG has approved the document |
2018-02-15 |
09 | Amy Vezza | Closed "Approve" ballot |
2018-02-15 |
09 | Amy Vezza | Ballot writeup was changed |
2018-02-15 |
09 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2018-02-15 |
09 | Deborah Brungard | Ballot approval text was changed |
2018-02-14 |
09 | Vishnu Beeram | New version available: draft-ietf-teas-rsvp-te-scaling-rec-09.txt |
2018-02-14 |
09 | (System) | New version approved |
2018-02-14 |
09 | (System) | Request for posting confirmation emailed to previous authors: Ina Minei <inaminei@google.com>, Rob Shakir <rjs@rob.sh>, Vishnu Beeram <vbeeram@juniper.net>, Tarek Saad <tsaad@cisco.com>, Dante Pacella <dante.j.pacella@verizon.com> |
2018-02-14 |
09 | Vishnu Beeram | Uploaded new revision |
2018-02-14 |
08 | Mirja Kühlewind | [Ballot comment] Thanks for the explanation and patience! Sorry for the long delay! ------------------ Old comment: I fully agree with the gan-art review (Thanks Elwyn!) ... [Ballot comment] Thanks for the explanation and patience! Sorry for the long delay! ------------------ Old comment: I fully agree with the gan-art review (Thanks Elwyn!) and Alvaro, that this reads from time to time like a BCP but is actually an extension specification. I would strongly recommend to apply the changes proposed by the gen-art review, and there is also a very detailed list of nits/edits that should probably be applied. Please have a look at that! |
2018-02-14 |
08 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2018-02-14 |
08 | Mirja Kühlewind | [Ballot comment] Thanks for explanation and patience! Sorry for the long delay! ------------------ Old comment: I fully agree with the gan-art review (Thanks Elwyn!) and ... [Ballot comment] Thanks for explanation and patience! Sorry for the long delay! ------------------ Old comment: I fully agree with the gan-art review (Thanks Elwyn!) and Alvaro, that this reads from time to time like a BCP but is actually an extension specification. I would strongly recommend to apply the changes proposed by the gen-art review, and there is also a very detailed list of nits/edits that should probably be applied. Please have a look at that! |
2018-02-14 |
08 | Mirja Kühlewind | [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss |
2017-10-30 |
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-10-30 |
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-10-30 |
08 | Vishnu Beeram | New version available: draft-ietf-teas-rsvp-te-scaling-rec-08.txt |
2017-10-30 |
08 | (System) | New version approved |
2017-10-30 |
08 | (System) | Request for posting confirmation emailed to previous authors: Ina Minei <inaminei@google.com>, Rob Shakir <rjs@rob.sh>, Vishnu Beeram <vbeeram@juniper.net>, Tarek Saad <tsaad@cisco.com>, Dante Pacella <dante.j.pacella@verizon.com> |
2017-10-30 |
08 | Vishnu Beeram | Uploaded new revision |
2017-10-11 |
07 | Martin Stiemerling | Closed request for Last Call review by TSVART with state 'Overtaken by Events' |
2017-09-28 |
07 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2017-09-28 |
07 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2017-09-28 |
07 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2017-09-28 |
07 | Suresh Krishnan | [Ballot comment] I agree with Ben that it is not clear which recommendations are from this document and which ones are restatements from other documents. ... [Ballot comment] I agree with Ben that it is not clear which recommendations are from this document and which ones are restatements from other documents. Some of these recommendations originating from this document look like they might be updating RFC2961. Why does this draft not update RFC2961 formally? It was not immediately apparent from the shepherd write up if the WG had considered this. |
2017-09-28 |
07 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2017-09-27 |
07 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2017-09-27 |
07 | Ben Campbell | [Ballot comment] [Note: The authors revised this draft between the time I reviewed it and transcribed my notes. This is a review of version 06. ... [Ballot comment] [Note: The authors revised this draft between the time I reviewed it and transcribed my notes. This is a review of version 06. I will not have time to re-review 07 prior to the telechat to see if my comments still apply.] Substantive: - General: I agree with the "major issues" comments from Elwyn's Gen-ART review. - General: There's a fair amount of 2119 language in this draft that refers to options in prior RFCs. It's not clear which of those are new normative requirements vs restatements of existing requirements. In the former case, this draft would need to update those respective RFCs. In the latter case, this draft should use descriptive language rather than 2119 keywords (unless in the form of direct quotes.) -1, last paragraph: "In order to reap maximum scaling benefits, it is strongly RECOMMENDED that implementations support both the techniques." That statement seems to require updating ... something. Maybe 3209 or 2961? -2.1.3, 2nd paragraph: Does this update RFC 2961? Or if not, is the normative language appropriate here? -2.2, bullet list: Are these new normative requirements or restatements of existing ones? -6: "This document does not introduce new security issues." Please document the reasoning behind that statement. Editorial: -2.1, section title: Why the quotes? -2.2, first bullet: Section 1 already normatively states these. This text effectively says "MUST follow the MUSTs...". (Note that this pattern recurs in several places.) -2.3, first paragraph: "The set of recommendations discussed in this section..." As written, many of those are requirements rather than recommendations. |
2017-09-27 |
07 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2017-09-27 |
07 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2017-09-27 |
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-09-27 |
07 | Vishnu Beeram | New version available: draft-ietf-teas-rsvp-te-scaling-rec-07.txt |
2017-09-27 |
07 | (System) | New version approved |
2017-09-27 |
07 | (System) | Request for posting confirmation emailed to previous authors: Ina Minei <inaminei@google.com>, Rob Shakir <rjs@rob.sh>, Vishnu Beeram <vbeeram@juniper.net>, Tarek Saad <tsaad@cisco.com>, Dante Pacella <dante.j.pacella@verizon.com> |
2017-09-27 |
07 | Vishnu Beeram | Uploaded new revision |
2017-09-27 |
06 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2017-09-27 |
06 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2017-09-27 |
06 | Mirja Kühlewind | [Ballot comment] I fully agree with the gan-art review (Thanks Elwyn!) and Alvaro, that this reads from time to time like a BCP but is ... [Ballot comment] I fully agree with the gan-art review (Thanks Elwyn!) and Alvaro, that this reads from time to time like a BCP but is actually an extension specification. I would strongly recommend to apply the changes proposed by the gen-art review, and there is also a very detailed list of nits/edits that should probably be applied. Please have a look at that! |
2017-09-27 |
06 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2017-09-27 |
06 | Mirja Kühlewind | [Ballot discuss] I'm uncertain what section 2.1.3. actually recommends. My understanding is that it is recommend to still retransmit some message even if the Rl ... [Ballot discuss] I'm uncertain what section 2.1.3. actually recommends. My understanding is that it is recommend to still retransmit some message even if the Rl was reached and to do that every 30s basically forever. First of all I think this still needs a termination criteria when to stop to try to retransmit finally. And then I don't understand why this is needed, instead of e.g. just using a larger Rl value? Can you please clarify! |
2017-09-27 |
06 | Mirja Kühlewind | Ballot discuss text updated for Mirja Kühlewind |
2017-09-27 |
06 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2017-09-26 |
06 | Adam Roach | [Ballot comment] I have some reservations around certain aspects of the document, but they've largely been captured by other IESG members. I'll reiterate two of ... [Ballot comment] I have some reservations around certain aspects of the document, but they've largely been captured by other IESG members. I'll reiterate two of them here, phrased as concrete suggestions. Change the title to something more like "Protocol Enhancements to Improve...", and rephrase all uses of the word "recommendation" to instead refer to the techniques described in the document. Clarify that the retransmission of messages described in section 2.1.3 does not continue for years or decades: specify a limit after which retransmission ceases even without an ACK. Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - RSVP-TE - RSVP Traffic Engineering - LSR - Label Switching Router |
2017-09-26 |
06 | Adam Roach | [Ballot Position Update] Position for Adam Roach has been changed to No Objection from No Record |
2017-09-26 |
06 | Adam Roach | [Ballot comment] Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - RSVP-TE - RSVP Traffic Engineering - ... [Ballot comment] Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - RSVP-TE - RSVP Traffic Engineering - LSR - Label Switching Router |
2017-09-26 |
06 | Adam Roach | Ballot comment text updated for Adam Roach |
2017-09-26 |
06 | Mirja Kühlewind | [Ballot discuss] I'm uncertain what section 2.1.3. actually recommends. My understanding is that it is recommend to still send retransmit some message even if the ... [Ballot discuss] I'm uncertain what section 2.1.3. actually recommends. My understanding is that it is recommend to still send retransmit some message even if the Rl was reached and to that every 30s basically forever. First of all I think this still needs a termination criteria when to stop to try to retransmit finally. And the I don't understand why this is needed, instead of e.g. just using a larger Rl value? Can you please clarify! |
2017-09-26 |
06 | Mirja Kühlewind | [Ballot comment] I fully agree with the gan-art review (Thanks Elwyn!) and Alvaro, that this reads from time to time like a BCP but is ... [Ballot comment] I fully agree with the gan-art review (Thanks Elwyn!) and Alvaro, that this reads from time to time like a BCP but is actually a extension specification. I would strongly recommend to apply the changes proposed by the gen-art review, and there is also a very detailed list of nits/edits that should probably be applied. Please have a look at that! |
2017-09-26 |
06 | Mirja Kühlewind | [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind |
2017-09-25 |
06 | Spencer Dawkins | [Ballot comment] I'm confused by this SHOULD. The configurable periodic retransmission interval for this slower timer SHOULD be less than the regular ... [Ballot comment] I'm confused by this SHOULD. The configurable periodic retransmission interval for this slower timer SHOULD be less than the regular refresh interval. Could you help me understand why someone would want to set the "slower timer" to be shorter than the regular refresh timer? |
2017-09-25 |
06 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2017-09-25 |
06 | Alvaro Retana | [Ballot comment] (1) This document seems to do two things: make a series of rfc2961 recommendations, and introduce a couple of new techniques. What is ... [Ballot comment] (1) This document seems to do two things: make a series of rfc2961 recommendations, and introduce a couple of new techniques. What is not clear to me is whether the first part is independent of the second. Will the implementation of Section 2.1. ("RFC2961 Specific" Recommendations) provide scaling benefits on their own (i.e. without the new techniques)? If so, please add some text (maybe in the Introduction) to indicate that. (2) As for as the new techniques, it is confusing to me the use of rfc2119 language in Section 2.1.1. (Basic Prerequisites), which reads: An implementation that supports the techniques discussed in Sections 2.2 and 2.3 must meet certain basic prerequisites. ... o It SHOULD initiate all RSVP Refresh Overhead Reduction mechanisms... I know that the leading "must" is not an RFC2119 keyword, but it may be confusing with the "SHOULD" used later...specially because it sounds as if (in some cases) it may be ok to not "initiate all RSVP Refresh Overhead Reduction mechanisms" and still use the new mechanisms described later. What are those cases? Maybe the mandatory prerequisites should all be listed in the same sub-section, while other recommendations can be elsewhere. Note also that later in 2.2 and 2.3 the text says that an implementation "MUST support all the recommendations" in 2.1. What does that MUST mean if one of the recommendations is not an absolute requirement? (3) Section 2.1.2 (Making Acknowledgements Mandatory) seems to also be a prerequisite, right? At lease the text says that "an implementation that supports the techniques discussed in Sections 2.2 and 2.3...MUST...". The fact that it is not in the actual prerequisites section may be confusing to some. (4) Section 2.1.3. (Clarifications On Reaching Rapid Retry Limit (Rl)) is (by clarifying and using normative language) making specific changes to rfc2961. Assuming that there is value in 2.1 being used by itself (without the new techniques), why isn't there a formal Update of rfc2961? (5) This reminds me, please use the new RFC2119-related template: please take a look at rfc8174. Nits: s/interval interval/interval When defining the new capability advertisements (in 2.2.1 and 2.3.1), it would be nice to include a reference to rfc5063. Given the specification in the preceding sections, I think that 2.2.2 and 2.3.2 are superfluous. It would be nice to point at the Appendix from the main text. |
2017-09-25 |
06 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2017-09-24 |
06 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2017-09-22 |
06 | Elwyn Davies | Request for Last Call review by GENART Completed: Not Ready. Reviewer: Elwyn Davies. Sent review to list. |
2017-09-22 |
06 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2017-09-22 |
06 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-teas-rsvp-te-scaling-rec-06. If any part of this review is inaccurate, please let us ... (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-teas-rsvp-te-scaling-rec-06. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete. In the Capability Object Values registry located on the Resource Reservation Protocol (RSVP) Parameters registry page at: https://www.iana.org/assignments/rsvp-parameters two new entries are to be added as follows: Bit Number: [TBD-at-registration] Hex Value: [TBD] Name: RI-RSVP Capable (I) Reference: [ RFC-to-be ] Bit Number: [TBD-at-registration] Hex Value: [TBD] Name: Per-Peer Flow-Control Capable (F) Reference: [ RFC-to-be ] The IANA Services Operator understands that this is the only action 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 only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Services Specialist |
2017-09-22 |
06 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2017-09-22 |
06 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2017-09-20 |
06 | Liang Xia | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Liang Xia. Sent review to list. |
2017-09-20 |
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Liang Xia |
2017-09-20 |
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Liang Xia |
2017-09-20 |
06 | Deborah Brungard | Ballot has been issued |
2017-09-20 |
06 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2017-09-20 |
06 | Deborah Brungard | Created "Approve" ballot |
2017-09-20 |
06 | Deborah Brungard | Ballot writeup was changed |
2017-09-19 |
06 | Dan Romascanu | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Dan Romascanu. Sent review to list. |
2017-09-14 |
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2017-09-14 |
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2017-09-14 |
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2017-09-14 |
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2017-09-12 |
06 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Lixia Zhang |
2017-09-12 |
06 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Lixia Zhang |
2017-09-08 |
06 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2017-09-08 |
06 | Cindy Morgan | The following Last Call announcement was sent out (ends 2017-09-22): From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, db3546@att.com, teas-chairs@ietf.org, teas@ietf.org, Lou Berger <lberger@labn.net>, ... The following Last Call announcement was sent out (ends 2017-09-22): From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, db3546@att.com, teas-chairs@ietf.org, teas@ietf.org, Lou Berger <lberger@labn.net>, lberger@labn.net Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-teas-rsvp-te-scaling-rec-06.txt> (Implementation Recommendations to Improve the Scalability of RSVP-TE Deployments) to Proposed Standard The IESG has received a request from the Traffic Engineering Architecture and Signaling WG (teas) to consider the following document: - 'Implementation Recommendations to Improve the Scalability of RSVP-TE Deployments' <draft-ietf-teas-rsvp-te-scaling-rec-06.txt> 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 2017-09-22. 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 scale at which RSVP-TE Label Switched Paths (LSPs) get deployed is growing continually and the onus is on RSVP-TE implementations across the board to keep up with this increasing demand. This document introduces a couple of techniques - "Refresh-Interval Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - to help RSVP-TE deployments push the envelope on scaling. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-scaling-rec/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2643/ |
2017-09-08 |
06 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2017-09-08 |
06 | Deborah Brungard | Placed on agenda for telechat - 2017-09-28 |
2017-09-08 |
06 | Deborah Brungard | Last call was requested |
2017-09-08 |
06 | Deborah Brungard | Ballot approval text was generated |
2017-09-08 |
06 | Deborah Brungard | Ballot writeup was generated |
2017-09-08 |
06 | Deborah Brungard | IESG state changed to Last Call Requested from Publication Requested |
2017-09-08 |
06 | Deborah Brungard | Last call announcement was generated |
2017-08-10 |
06 | Vishnu Beeram | New version available: draft-ietf-teas-rsvp-te-scaling-rec-06.txt |
2017-08-10 |
06 | (System) | New version approved |
2017-08-10 |
06 | (System) | Request for posting confirmation emailed to previous authors: Ina Minei <inaminei@google.com>, Tarek Saad <tsaad@cisco.com>, Rob Shakir <rjs@rob.sh>, Vishnu Beeram <vbeeram@juniper.net>, Dante Pacella <dante.j.pacella@verizon.com> |
2017-08-10 |
06 | Vishnu Beeram | Uploaded new revision |
2017-08-01 |
05 | Jonathan Hardwick | Closed request for Last Call review by RTGDIR with state 'Withdrawn' |
2017-08-01 |
05 | Jonathan Hardwick | Assignment of request for Last Call review by RTGDIR to John Scudder was rejected |
2017-07-27 |
05 | Victoria Pritchard | Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Victoria Pritchard. |
2017-07-24 |
05 | Jonathan Hardwick | Request for Last Call review by RTGDIR is assigned to John Scudder |
2017-07-24 |
05 | Jonathan Hardwick | Request for Last Call review by RTGDIR is assigned to John Scudder |
2017-07-24 |
05 | Deborah Brungard | Requested Last Call review by RTGDIR |
2017-07-10 |
05 | Min Ye | Request for Last Call review by RTGDIR is assigned to Victoria Pritchard |
2017-07-10 |
05 | Min Ye | Request for Last Call review by RTGDIR is assigned to Victoria Pritchard |
2017-07-10 |
05 | Deborah Brungard | Requested Last Call review by RTGDIR |
2017-07-09 |
05 | Lou Berger | > As required by RFC 4858, this is the current template for the Document > Shepherd Write-Up. > > Changes are expected over time. This ... > 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)? Standards Track > Why is this the proper type of RFC? It defines protocol processing rules that must be followed by multiple nodes/independent implementations. > 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 > > 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. This document discusses Generalized Multi-Protocol Label Switching (GMPLS) Resource reSerVation Protocol with Traffic Engineering (RSVP- TE) mechanisms to improve RSVP-TE deployment scaling. > 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? This document was originally targeted to the MPLS WG. This document has been fairly noncontroversial. > > 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? The extensions defined in this document are done so in a way to be compatible with known implementations. While there have been no public statements on implementation, the authors represent multiple organizations, and implementation is expected - or more likely, already exist. > Personnel > > Who is the Document Shepherd? Lou Berger > 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 Shepherd has reviewed the document as part of normal WG progress and WG last call. The Shepherd believes this document is ready for publication. > (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? No. > 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. No blocking concerns. All areas of discomfort have been addressed by the authors. > (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, see thread at https://www.ietf.org/mail-archive/web/teas/current/msg02472.html > (8) Has an IPR disclosure been filed that references this document? > If so, summarize any WG discussion and conclusion regarding the IPR > disclosures. Yes, it has. Other than the actual disclosure and referencing by authors, there has been no specfic discussion or concerns raised within the WG, > (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? Solid among those who are interested. "strong concurrence of a few individuals, with others being silent" is a reasonable characterization. > (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 discontent seen. > > (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. The document passes ID nits. Although there is a comment on a missing 2119 boiler plate, yet it is present as section 1.1. > > (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? No. > (15) Are there downward normative references references (see RFC 3967)? > If so, list these downward references to support the Area Director in > the Last Call procedure. No. > (16) Will publication of this document change the status of any > existing RFCs? Are those RFCs listed on the title page header, listed > in the abstract, and discussed in the introduction? If the RFCs are not > listed in the Abstract and Introduction, explain why, and point to the > part of the document where the relationship of this document to the > other RFCs is discussed. If this information is not in the document, > explain why the WG considers it unnecessary. 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 5226). The IANA section was fully reviewed by the document shepherd and is appropriate for an this draft. > (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, etc. N/A |
2017-07-09 |
05 | Lou Berger | Responsible AD changed to Deborah Brungard |
2017-07-09 |
05 | Lou Berger | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2017-07-09 |
05 | Lou Berger | IESG state changed to Publication Requested |
2017-07-09 |
05 | Lou Berger | IESG process started in state Publication Requested |
2017-07-09 |
05 | Lou Berger | Changed document writeup |
2017-07-09 |
05 | Lou Berger | Changed consensus to Yes from Unknown |
2017-07-09 |
05 | Lou Berger | Intended Status changed to Proposed Standard from None |
2017-07-02 |
05 | Vishnu Beeram | New version available: draft-ietf-teas-rsvp-te-scaling-rec-05.txt |
2017-07-02 |
05 | (System) | New version approved |
2017-07-02 |
05 | (System) | Request for posting confirmation emailed to previous authors: Ina Minei <inaminei@google.com>, Tarek Saad <tsaad@cisco.com>, Rob Shakir <rjs@rob.sh>, Vishnu Beeram <vbeeram@juniper.net>, Dante Pacella <dante.j.pacella@verizon.com> |
2017-07-02 |
05 | Vishnu Beeram | Uploaded new revision |
2017-06-16 |
04 | Lou Berger | See https://www.ietf.org/mail-archive/web/teas/current/msg02504.html |
2017-06-16 |
04 | Lou Berger | IETF WG state changed to In WG Last Call from WG Document |
2017-06-16 |
04 | Lou Berger | Notification list changed to Lou Berger <lberger@labn.net> |
2017-06-16 |
04 | Lou Berger | Document shepherd changed to Lou Berger |
2017-06-16 |
04 | Lou Berger | IPR Responses: Ina Minei: https://www.ietf.org/mail-archive/web/teas/current/msg02503.html Markus Jork: https://www.ietf.org/mail-archive/web/teas/current/msg02496.html Ebben Aries: https://www.ietf.org/mail-archive/web/teas/current/msg02497.html //All responses received, IPR disclosed. |
2017-06-13 |
04 | Lou Berger | IPR Missing: Ina Minei <inaminei at google.com>, mjork@juniper.net exa@juniper.ne IPR Responses: Vishnu Beeram <vbeeram at juniper.net>, https://www.ietf.org/mail-archive/web/teas/current/msg02474.html rjs at rob.sh, https://www.ietf.org/mail-archive/web/teas/current/msg02490.html dante.j.pacella ... IPR Missing: Ina Minei <inaminei at google.com>, mjork@juniper.net exa@juniper.ne IPR Responses: Vishnu Beeram <vbeeram at juniper.net>, https://www.ietf.org/mail-archive/web/teas/current/msg02474.html rjs at rob.sh, https://www.ietf.org/mail-archive/web/teas/current/msg02490.html dante.j.pacella at verizon.com, https://www.ietf.org/mail-archive/web/teas/current/msg02480.html "Tarek Saad (tsaad)" <tsaad at cisco.com> https://www.ietf.org/mail-archive/web/teas/current/msg02481.html |
2017-06-13 |
04 | Lou Berger | Pre-LC IPR Poll: https://www.ietf.org/mail-archive/web/teas/current/msg02472.html Vishnu Beeram <vbeeram at juniper.net>, Ina Minei <inaminei at google.com>, rjs at rob.sh, dante.j.pacella at verizon.com, "Tarek ... Pre-LC IPR Poll: https://www.ietf.org/mail-archive/web/teas/current/msg02472.html Vishnu Beeram <vbeeram at juniper.net>, Ina Minei <inaminei at google.com>, rjs at rob.sh, dante.j.pacella at verizon.com, "Tarek Saad (tsaad)" <tsaad at cisco.com> mjork@juniper.net exa@juniper.net |
2017-03-12 |
04 | Vishnu Beeram | New version available: draft-ietf-teas-rsvp-te-scaling-rec-04.txt |
2017-03-12 |
04 | (System) | New version approved |
2017-03-12 |
04 | (System) | Request for posting confirmation emailed to previous authors: Dante Pacella <dante.j.pacella@verizon.com>, Vishnu Beeram <vbeeram@juniper.net>, Rob Shakir <rjs@rob.sh>, teas-chairs@ietf.org, Ina Minei <inaminei@google.com>, Tarek Saad <tsaad@cisco.com> |
2017-03-12 |
04 | Vishnu Beeram | Uploaded new revision |
2016-10-30 |
03 | Vishnu Beeram | New version available: draft-ietf-teas-rsvp-te-scaling-rec-03.txt |
2016-10-30 |
03 | (System) | New version approved |
2016-10-30 |
03 | (System) | Request for posting confirmation emailed to previous authors: "Tarek Saad" <tsaad@cisco.com>, "Ina Minei" <inaminei@google.com>, teas-chairs@ietf.org, "Dante Pacella" <dante.j.pacella@verizon.com>, "Rob Shakir" <rjs@rob.sh>, "Vishnu Beeram" <vbeeram@juniper.net> |
2016-10-30 |
03 | Vishnu Beeram | Uploaded new revision |
2016-09-21 |
02 | Vishnu Beeram | New version available: draft-ietf-teas-rsvp-te-scaling-rec-02.txt |
2016-09-21 |
02 | Vishnu Beeram | New version approved |
2016-09-21 |
02 | Vishnu Beeram | Request for posting confirmation emailed to previous authors: "Tarek Saad" <tsaad@cisco.com>, "Ina Minei" <inaminei@google.com>, "Vishnu Pavan Beeram" <vbeeram@juniper.net>, "Dante Pacella" <dante.j.pacella@verizon.com>, "Rob Shakir" <rjs@rob.sh> |
2016-09-21 |
02 | (System) | Uploaded new revision |
2016-03-21 |
01 | Vishnu Beeram | New version available: draft-ietf-teas-rsvp-te-scaling-rec-01.txt |
2015-10-05 |
00 | Lou Berger | This document now replaces draft-beeram-teas-rsvp-te-scaling-rec instead of None |
2015-10-05 |
00 | Vishnu Beeram | New version available: draft-ietf-teas-rsvp-te-scaling-rec-00.txt |