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 <> Mon, 09 March 2015 17:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4931F1A9125; Mon, 9 Mar 2015 10:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0Z7G9koYgLp5; Mon, 9 Mar 2015 10:59:11 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id D25721A9131; Mon, 9 Mar 2015 10:59:09 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <>
To: IETF-Announce <>
Subject: Protocol Action: 'GMPLS RSVP-TE Extensions for Lock Instruct and Loopback' to Proposed Standard (draft-ietf-teas-rsvp-te-li-lb-05.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 5.12.0.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Mon, 09 Mar 2015 10:59:09 -0700
Archived-At: <>
Cc: teas chair <>, teas mailing list <>, RFC Editor <>
X-Mailman-Version: 2.1.15
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Mar 2015 17:59:13 -0000

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:

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

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.

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

RFC Editor Note

s3.2, para 2:
   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.
   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.

s3.2, para 3,
   Otherwise, the node SHOULD try to put the LSP into loopback mode.
   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.