GMPLS RSVP-TE Extensions for Lock Instruct and Loopback
draft-ietf-teas-rsvp-te-li-lb-05

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: RFC Editor <rfc-editor@rfc-editor.org>,
    teas mailing list <teas@ietf.org>,
    teas chair <teas-chairs@tools.ietf.org>
Subject: Protocol Action: 'GMPLS RSVP-TE Extensions for Lock Instruct and Loopback' to Proposed Standard (draft-ietf-teas-rsvp-te-li-lb-05.txt)

The IESG has approved the following document:
- 'GMPLS RSVP-TE Extensions for Lock Instruct and Loopback'
  (draft-ietf-teas-rsvp-te-li-lb-05.txt) as Proposed Standard

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

The IESG contact persons are Alia Atlas and Adrian Farrel.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-li-lb/

Ballot Text

Technical Summary

   This document specifies extensions to Resource Reservation Protocol-
   Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and
   Loopback (LB) mechanisms for Label Switched Paths (LSPs).  These
   mechanisms are applicable to technologies which use Generalized
   Multi-Protocol Label Switching (GMPLS) for the control plane.

Working Group Summary

  This document moved from the CCAMP to TEAS WGs as part of
  the routing WG changes.  This document has been fairly
   noncontroversial.

Document Quality

  The base GMPLS protocol has been implemented.  The extensions
  defined in this document are compatible with earlier implementations
  and satisfy requirements previously documented in RFCs. While
  there have been no public statements on implementation, the
  authors are from multiple vendors and an operator, and
  implementation is expected.

Personnel
 
  Lou Berger is the Document Shepherd
  Adrian Farrel  is the Responsible Area Director

RFC Editor Note

s3.2, para 2:
OLD:
   The ingress node MUST ensure that the entity (node or interface), at 
   which loopback is intended to occur, is marked as a strict hop in the
   Explicit Route Object (ERO) subobject.
NEW:
   The ingress node MUST ensure that the entity at which loopback is
   intended to occur is explicitly identified by the immediately 
   preceding subobject of the ERO Hop Attributes subobject.
END

s3.2, para 3,
AFTER 
   Otherwise, the node SHOULD try to put the LSP into loopback mode.
ADD
   The loopback SHOULD be enabled on the entity identified by the ERO
   subobject immediately prior to the ERO Hop Attributes subobject. If
   the immediately preceding subobject is a label subobject [RFC3473],
   the loopback SHOULD be enabled for the direction indicated by the U
   bit of the label subobject.
END

RFC Editor Note