Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection
draft-ietf-teas-rsvp-egress-protection-16
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-06-06
|
16 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-05-23
|
16 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-05-10
|
16 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-03-26
|
16 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2018-03-22
|
16 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-03-22
|
16 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2018-03-22
|
16 | (System) | IANA Action state changed to Waiting on Authors |
2018-03-19
|
16 | (System) | RFC Editor state changed to EDIT |
2018-03-19
|
16 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-03-19
|
16 | (System) | Announcement was received by RFC Editor |
2018-03-18
|
16 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup |
2018-03-18
|
16 | Amy Vezza | IESG has approved the document |
2018-03-18
|
16 | Amy Vezza | Closed "Approve" ballot |
2018-03-18
|
16 | Amy Vezza | Ballot approval text was generated |
2018-03-18
|
16 | Amy Vezza | Ballot writeup was changed |
2018-03-18
|
16 | Deborah Brungard | Ballot approval text was changed |
2018-03-18
|
16 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-03-18
|
16 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-16.txt |
2018-03-18
|
16 | (System) | New version approved |
2018-03-18
|
16 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen , Lu Huang , Tarek Saad , Autumn Liu , Fengman Xu |
2018-03-18
|
16 | Huaimo Chen | Uploaded new revision |
2018-03-08
|
15 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2018-03-08
|
15 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2018-03-08
|
15 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-03-07
|
15 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-03-07
|
15 | Eric Rescorla | [Ballot comment] https://mozphab-ietf.devsvcdev.mozaws.net/D4328 I found this document a little hard to follow because it took me a while to understand the difference between the current … [Ballot comment] https://mozphab-ietf.devsvcdev.mozaws.net/D4328 I found this document a little hard to follow because it took me a while to understand the difference between the current situation and the change in the draft. Would you consider putting part of the material from S 6 in the introduction so non-experts could have more context? locally protecting the egress node(s) of an LSP. This document fills that void and specifies extensions to RSVP-TE for For those of us who are not experts, can you say what "protecting" means? egresses L1 and L2 of a primary P2MP LSP from ingress R1 to two egresses L1 and L2. La and Lb are the designated backup egresses for primary egresses L1 and L2 respectively. The backup LSP for This might be the tiniest bit confusing, as it mentions L1 and L2 twice. The exact mechanism by which the failure of the primary egress is detected by the upstream node is out of the scope of this document. It would be helpful for me if you specified what the upstream node is. Is it R3? node does not provide any fast local protection against the failure of the primary egress node. In this case, the backup LSP from the branch node to the backup egress node protects against failures on This sentence would be clearer if it said "If the direct upstream node does not provide any fast local protection ....." the subobject in bytes, including Type, Length and Contents fields. The Reserved field MUST be set to zero. What are the semantics of the optional subobjects? To protect the VPN traffic against the failure of the egress L1 of the LSP, an existing solution (refer to Figure 2) includes: I wasn't reading this closely, so it took me a minute to be like "hold on, this is reroute from R1, nor R3". Probably just me being stupid, but it might have helped to have a subsection like "Existing solution before this draft" The PLR R3 is closer to L1 than the ingress R1. It may detect the failure of the egress L1 faster and more reliable. Thus we can have faster protection for egress. Nit: "more more reliably" |
2018-03-07
|
15 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-03-07
|
15 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-03-07
|
15 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-03-06
|
15 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-03-06
|
15 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-03-06
|
15 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2018-03-06
|
15 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-03-05
|
15 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-03-05
|
15 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-15.txt |
2018-03-05
|
15 | (System) | New version approved |
2018-03-05
|
15 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen , Lu Huang , Tarek Saad , Autumn Liu , Fengman Xu |
2018-03-05
|
15 | Huaimo Chen | Uploaded new revision |
2018-03-05
|
14 | Stewart Bryant | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Stewart Bryant. Sent review to list. |
2018-03-05
|
14 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-03-04
|
14 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-03-03
|
14 | Kathleen Moriarty | [Ballot comment] Thank you for addressing the SecDir comments. |
2018-03-03
|
14 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2018-03-02
|
14 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-14.txt |
2018-03-02
|
14 | (System) | New version approved |
2018-03-02
|
14 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen , Lu Huang , Tarek Saad , Autumn Liu , Fengman Xu |
2018-03-02
|
14 | Huaimo Chen | Uploaded new revision |
2018-03-02
|
13 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-03-01
|
13 | Jean Mahoney | Request for Telechat review by GENART is assigned to Stewart Bryant |
2018-03-01
|
13 | Jean Mahoney | Request for Telechat review by GENART is assigned to Stewart Bryant |
2018-03-01
|
13 | Rifaat Shekh-Yusef | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Rifaat Shekh-Yusef. Sent review to list. |
2018-03-01
|
13 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Rifaat Shekh-Yusef |
2018-03-01
|
13 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Rifaat Shekh-Yusef |
2018-02-28
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-02-28
|
13 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-13.txt |
2018-02-28
|
13 | (System) | New version approved |
2018-02-28
|
13 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen , Lu Huang , Tarek Saad , Autumn Liu , Fengman Xu |
2018-02-28
|
13 | Huaimo Chen | Uploaded new revision |
2018-02-28
|
12 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-02-28
|
12 | Deborah Brungard | Ballot has been issued |
2018-02-28
|
12 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2018-02-28
|
12 | Deborah Brungard | Created "Approve" ballot |
2018-02-28
|
12 | Deborah Brungard | Ballot writeup was changed |
2018-02-27
|
12 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-02-26
|
12 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-02-24
|
12 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-12.txt |
2018-02-24
|
12 | (System) | New version approved |
2018-02-24
|
12 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen , Lu Huang , Tarek Saad , Autumn Liu , Fengman Xu |
2018-02-24
|
12 | Huaimo Chen | Uploaded new revision |
2018-02-23
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2018-02-23
|
11 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-11.txt |
2018-02-23
|
11 | (System) | New version approved |
2018-02-23
|
11 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen , Lu Huang , Tarek Saad , Autumn Liu , Fengman Xu |
2018-02-23
|
11 | Huaimo Chen | Uploaded new revision |
2018-02-23
|
10 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-02-23
|
10 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-teas-rsvp-egress-protection-09. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-teas-rsvp-egress-protection-09. If any part of this review is inaccurate, please let us know. We have a note and a question about one of the actions required by this document. The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the Class Types or C-Types - 37 PROTECTION subregistry of the Class Names, Class Numbers, and Class Types registry on the Resource Reservation Protocol (RSVP) Parameters registry page located at: https://www.iana.org/assignments/rsvp-parameters/ a single new registration is to be made as follows: Value: [ TBD-at-Registration - 3 suggested] Description: Egress Protection Reference: [ RFC-to-be ] NOTE: As we can't reserve values, we can't guarantee that value 3 will be available for registration when this document is approved. The working group chairs and AD for this document, if the working group agrees, can request a temporary early allocation for this value, as described by RFC 7120 (see Section 3 for procedure). If an early allocation won't be requested, we recommend specifying in the document that 3 is a suggested value. Second, a new subregistry is to be created called Sub-object types - 37 PROTECTION - C-Type 3. This new registry will be a subregistry of the registry Class Types or C-Types - 37 PROTECTION subregistry of the Class Names, Class Numbers, and Class Types registry on the Resource Reservation Protocol (RSVP) Parameters registry page located at: https://www.iana.org/assignments/rsvp-parameters/ The registration procedure for the new registry will be IETF Review as defined by RFC 8126. There are new registrations in the new registry: Value Name Reference -----+--------------------+------------- 1 IPv4_PRIMARY_EGRESS [ RFC-to-be ] 2 IPv6_PRIMARY_EGRESS [ RFC-to-be ] 3 IPv4_P2P_LSP_ID [ RFC-to-be ] 4 IPv6_P2P_LSP_ID [ RFC-to-be ] IANA QUESTION --> What is this registry's maximum value? Should value 0 be marked "Unassigned" (i.e. available for assignment) or "Reserved"? The IANA Services Operator understands that these are the only actions required 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, Amanda Baber Lead IANA Services Specialist |
2018-02-22
|
10 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-10.txt |
2018-02-22
|
10 | (System) | New version approved |
2018-02-22
|
10 | (System) | Request for posting confirmation emailed to previous authors: Huaimo Chen , Lu Huang , Tarek Saad , Autumn Liu , Fengman Xu |
2018-02-22
|
10 | Huaimo Chen | Uploaded new revision |
2018-02-20
|
09 | Rifaat Shekh-Yusef | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Rifaat Shekh-Yusef. Sent review to list. |
2018-02-19
|
09 | Stewart Bryant | Request for Last Call review by GENART Completed: On the Right Track. Reviewer: Stewart Bryant. Sent review to list. |
2018-02-16
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Rifaat Shekh-Yusef |
2018-02-16
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Rifaat Shekh-Yusef |
2018-02-15
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2018-02-15
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2018-02-14
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
2018-02-14
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
2018-02-13
|
09 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2018-02-13
|
09 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-02-27): From: The IESG To: IETF-Announce CC: Vishnu Beeram , db3546@att.com, teas-chairs@ietf.org, teas@ietf.org, … The following Last Call announcement was sent out (ends 2018-02-27): From: The IESG To: IETF-Announce CC: Vishnu Beeram , db3546@att.com, teas-chairs@ietf.org, teas@ietf.org, vishnupavan@gmail.com, draft-ietf-teas-rsvp-egress-protection@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Extensions to RSVP-TE for LSP Egress Local Protection) to Proposed Standard The IESG has received a request from the Traffic Engineering Architecture and Signaling WG (teas) to consider the following document: - 'Extensions to RSVP-TE for LSP Egress Local Protection' 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 2018-02-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the egress node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-egress-protection/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-egress-protection/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2537/ https://datatracker.ietf.org/ipr/2310/ https://datatracker.ietf.org/ipr/2079/ |
2018-02-13
|
09 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2018-02-13
|
09 | Deborah Brungard | Placed on agenda for telechat - 2018-03-08 |
2018-02-13
|
09 | Deborah Brungard | Last call was requested |
2018-02-13
|
09 | Deborah Brungard | Ballot approval text was generated |
2018-02-13
|
09 | Deborah Brungard | Ballot writeup was generated |
2018-02-13
|
09 | Deborah Brungard | IESG state changed to Last Call Requested from Expert Review |
2018-02-13
|
09 | Deborah Brungard | Last call announcement was generated |
2017-12-18
|
09 | Min Ye | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Russ White. |
2017-12-04
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Russ White |
2017-12-04
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Russ White |
2017-11-28
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Stig Venaas |
2017-11-28
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Stig Venaas |
2017-11-24
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Henning Rogge |
2017-11-24
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Henning Rogge |
2017-11-21
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Victoria Pritchard |
2017-11-21
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Victoria Pritchard |
2017-11-13
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Jon Mitchell |
2017-11-13
|
09 | Min Ye | Request for Last Call review by RTGDIR is assigned to Jon Mitchell |
2017-11-13
|
09 | Deborah Brungard | IESG state changed to Expert Review from Publication Requested |
2017-11-13
|
09 | Deborah Brungard | Requested Last Call review by RTGDIR |
2017-11-03
|
09 | Vishnu Beeram | > As required by RFC 4858, this is the current template for the Document > Shepherd Write-Up. > > Changes are expected over time. … > 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? The document defines RSVP related formats and behaviors. > 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 describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the egress node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP). > 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 moved from the MPLS WG to TEAS WG as part of the routing WG changes. The document was adopted by the MPLS WG in March 2014 and it has gone through several iterations since then. There was a virtual interim meeting held in January 2016 to help get things moving for the draft. There were also some issues (including a serious backwards compatibility issue) found by the Shepherd after the WG Last Call. An informal 1-week Last Call was needed after these issues got addressed. > > 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 base MPLS RSVP protocol has been implemented. The extensions defined in this document are compatible with earlier implementations. While there have been no public statements on implementation, the authors are from multiple vendors, and implementation is expected. > Personnel > > Who is the Document Shepherd? Vishnu Pavan Beeram > 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 it has progressed through the WG (first MPLS, then TEAS). 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 specific 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, see thread https://mailarchive.ietf.org/arch/msg/teas/p0k3lW_LycG2NTkB6JZ9yAIJXCg > > (8) Has an IPR disclosure been filed that references this document? > If so, summarize any WG discussion and conclusion regarding the IPR > disclosures. Yes, an IPR disclosure has been filed that references this document https://datatracker.ietf.org/ipr/2537/ > (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 extreme 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. > > (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. All protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. > (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-11-03
|
09 | Vishnu Beeram | Responsible AD changed to Deborah Brungard |
2017-11-03
|
09 | Vishnu Beeram | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2017-11-03
|
09 | Vishnu Beeram | IESG state changed to Publication Requested |
2017-11-03
|
09 | Vishnu Beeram | IESG process started in state Publication Requested |
2017-11-03
|
09 | Vishnu Beeram | Changed consensus to Yes from Unknown |
2017-11-03
|
09 | Vishnu Beeram | Intended Status changed to Proposed Standard from None |
2017-11-03
|
09 | Vishnu Beeram | Changed document writeup |
2017-10-15
|
09 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-09.txt |
2017-10-15
|
09 | (System) | New version approved |
2017-10-15
|
09 | (System) | Request for posting confirmation emailed to previous authors: Fengman Xu , Autumn Liu , teas-chairs@ietf.org, So Ning , Huaimo Chen , Lu Huang , … Request for posting confirmation emailed to previous authors: Fengman Xu , Autumn Liu , teas-chairs@ietf.org, So Ning , Huaimo Chen , Lu Huang , Tarek Saad |
2017-10-15
|
09 | Huaimo Chen | Uploaded new revision |
2017-08-03
|
08 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-08.txt |
2017-08-03
|
08 | (System) | New version approved |
2017-08-03
|
08 | (System) | Request for posting confirmation emailed to previous authors: Tarek Saad , Autumn Liu , So Ning , Huaimo Chen , Lu Huang , Fengman Xu |
2017-08-03
|
08 | Huaimo Chen | Uploaded new revision |
2017-07-03
|
07 | Vishnu Beeram | Last Call complete. Shepherd Review/Write-Up pending. |
2017-07-03
|
07 | Vishnu Beeram | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2017-05-15
|
07 | Vishnu Beeram | Notification list changed to Vishnu Beeram <vishnupavan@gmail.com> |
2017-05-15
|
07 | Vishnu Beeram | Document shepherd changed to Vishnu Pavan Beeram |
2017-03-13
|
07 | Matt Hartley | fengman.xu@verizon.com - no IPR Still waiting on: hliu@ciena.com |
2017-03-08
|
07 | Matt Hartley | mengnan@huawei.com - no IPR liu.cmri@gmail.com - no IPR Still waiting on: fengman.xu@verizon.com hliu@ciena.com |
2017-03-07
|
07 | Matt Hartley | mehmet.toy@verizon.com - no IPR lliu@us.fujitsu.com - no IPR huanglu@chinamobile.com - no IPR lizhenbin@huawei.com - no IPR prejeeth@gmail.com - no IPR ningso01@gmail.com - no IPR tsaad@cisco.com … mehmet.toy@verizon.com - no IPR lliu@us.fujitsu.com - no IPR huanglu@chinamobile.com - no IPR lizhenbin@huawei.com - no IPR prejeeth@gmail.com - no IPR ningso01@gmail.com - no IPR tsaad@cisco.com - no IPR Boris.Zhang@telus.com - no IPR huaimo.chen@huawei.com - IPR exists and has been disclosed. fengman.xu@verizon.com hliu@ciena.com liu.cmri@gmail.com mengnan@huawei.com |
2017-03-07
|
07 | Matt Hartley | IPR poll started 3/6/17 |
2017-02-18
|
07 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-07.txt |
2017-02-18
|
07 | (System) | New version approved |
2017-02-18
|
07 | (System) | Request for posting confirmation emailed to previous authors: "Lu Huang" , "Huaimo Chen" , "Tarek Saad" , teas-chairs@ietf.org, "Autumn Liu" , "Ning So" , … Request for posting confirmation emailed to previous authors: "Lu Huang" , "Huaimo Chen" , "Tarek Saad" , teas-chairs@ietf.org, "Autumn Liu" , "Ning So" , "Fengman Xu" |
2017-02-18
|
07 | Huaimo Chen | Uploaded new revision |
2016-10-28
|
06 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-06.txt |
2016-10-28
|
06 | (System) | New version approved |
2016-10-28
|
05 | (System) | Request for posting confirmation emailed to previous authors: "Lu Huang" , "Huaimo Chen" , "Tarek Saad" , "Autumn Liu" , "Ning So" , "Fengman Xu" |
2016-10-28
|
05 | Huaimo Chen | Uploaded new revision |
2016-08-08
|
05 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-05.txt |
2016-03-18
|
04 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-04.txt |
2015-12-19
|
03 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-03.txt |
2015-06-18
|
02 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-02.txt |
2015-02-17
|
Naveen Khan | Posted related IPR disclosure: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-teas-rsvp-egress-protection | |
2015-02-03
|
01 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-01.txt |
2014-12-31
|
00 | Lou Berger | This document now replaces draft-ietf-mpls-rsvp-egress-protection instead of None |
2014-12-29
|
00 | Huaimo Chen | New version available: draft-ietf-teas-rsvp-egress-protection-00.txt |