Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection
draft-ietf-teas-rsvp-ingress-protection-17

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Vishnu Beeram <vishnupavan@gmail.com>, The IESG <iesg@ietf.org>, db3546@att.com, Vishnu Beeram <vbeeram@juniper.net>, teas-chairs@ietf.org, teas@ietf.org, vishnupavan@gmail.com, draft-ietf-teas-rsvp-ingress-protection@ietf.org, rfc-editor@rfc-editor.org
Subject: Document Action: 'Extensions to RSVP-TE for LSP Ingress FRR Protection' to Experimental RFC (draft-ietf-teas-rsvp-ingress-protection-17.txt)

The IESG has approved the following document:
- 'Extensions to RSVP-TE for LSP Ingress FRR Protection'
  (draft-ietf-teas-rsvp-ingress-protection-17.txt) as Experimental RFC

This document is the product of the Traffic Engineering Architecture and
Signaling Working Group.

The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah
Brungard.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-ingress-protection/

Ballot Text

Technical Summary

This document describes extensions to Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) for locally protecting the ingress node
of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic
Engineered (TE) Label Switched Path (LSP).

Working Group Summary

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 debate
the merits of the proposed solutions. There were also some issues 
found by the  Shepherd after the WG Last Call. An informal 1-week 
Last Call was needed after these issues got addressed.

Document Quality

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 for this document?  Vishnu Pavan Beeram
   Who is the Responsible Area Director?  Deborah Brungard

RFC Editor Note