Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE
draft-shiomoto-ccamp-switch-programming-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>
Subject: Document Action: 'Advice on When It is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE' to Informational RFC (draft-shiomoto-ccamp-switch-programming-05.txt)

The IESG has approved the following document:
- 'Advice on When It is Safe to Start Sending Data on Label Switched
   Paths Established Using RSVP-TE'
  (draft-shiomoto-ccamp-switch-programming-05.txt) as an Informational
RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Stewart Bryant.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-shiomoto-ccamp-switch-programming/

Ballot Text

Technical Summary

  The Resource Reservation Protocol (RSVP) has been extended to support
  Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and
  Generalized MPLS (GMPLS) networks. The protocol enables signaling
  exchanges to establish Label Switched Paths (LSPs) that traverse
  nodes and links to provide end-to-end data paths. Each node is
  programmed with "cross-connect" information as the signaling messages
  are processed. The cross-connection information instructs the node
  how to forward data that it receives.

  End points of an LSP need to know when it is safe to start sending
  data so that it is not misdelivered, and so that safety issues
  specific to optical data plane technology are satisfied. Likewise,
  all label switching routers along the path of the LSP need to know
  when to programme their data planes relative to sending and receiving
  control plane messages.

  This document clarifies and summarises the RSVP-TE protocol exchanges
  with relation to the programming of cross-connects along an LSP for
  both unidirectional and bidirectional LSPs. This document does not
  define any new procedures or protocol extensions, and defers
  completely to the documents that provide normative references. The
  clarifications set out in this document may also be used to help
  interpret LSP establishment performance figures for MPLS-TE and GMPLS
  devices.

Working Group Summary

  The document was written in the hope that the CCAMP working group
  would adopt it. In the end, the working group reviewed and
  contributed to the document, but the chairs agreed that the work was
  not central to the working group and that AD Sponsored would be a
  more appropriate course.

  The document has been reviewed on several occasions by the CCAMP
  working group including a formal review instigated by the chairs
  when it became clear that the authors would request AD sponsorship. 

Document Quality

  This Informational document does not define new protocol elements.
  It seeks to describe existing implementations and give advice for new
  implementations.

Personnel

Daniel King (daniel@olddog.co.uk) is the Document Shepherd for 
this document.

Stewart Bryant (stbryant@cisco.com) is the Responsible Area Director.

RFC Editor Note

OLD
-- section 1, paragraph 4: "...with relation to the programming..."
NEW
-- section 1, paragraph 4: "...in relation to the programming..."

RFC Editor Note