Skip to main content

Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection
RFC 8400

Revision differences

Document history

Date Rev. By Action
2020-01-21
16 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2018-06-21
16 (System) Received changes through RFC Editor sync (added Errata tag)
2018-06-08
16 (System)
Received changes through RFC Editor sync (created alias RFC 8400, changed title to 'Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection', changed …
Received changes through RFC Editor sync (created alias RFC 8400, changed title to 'Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection', changed abstract to '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).', changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-06-08, changed IESG state to RFC Published)
2018-06-08
16 (System) RFC published
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
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