Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE
draft-shiomoto-ccamp-switch-programming-05

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Advice on When It is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Advice on When It is Safe to Start Sending Data on Label Switched
  Paths Established Using RSVP-TE'
  as an Informational
RFC

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 2011-07-18. 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


  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 program 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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-shiomoto-ccamp-switch-programming/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-shiomoto-ccamp-switch-programming/


No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document? Has the
      Document Shepherd personally reviewed this version of the document
      and, in particular, does he or she believe this version is ready
      for forwarding to the IESG for publication?

Adrian Farrel (adrian.farrel@huawei.com) is the Document Shepherd.
He has reviewed the document and believes it is ready for publication.

Note that the document shepherd is a co-author of this document.

(1.b) Has the document had adequate review both from key members of
      the interested community and others? Does the Document Shepherd
      have any concerns about the depth or breadth of the reviews that
      have been performed?

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 sponsorhsip.

(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective, e.g.,
      security, operational complexity, someone familiar with AAA,
      internationalization or XML?

No concerns.

(1.d) Does the Document Shepherd have any specific concerns or
      issues 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 interested community has discussed those issues and has
      indicated that it still wishes to advance the document, detail
      those concerns here.

No concerns.

(1.e) How solid is the consensus of the interested community behind
      this document? Does it represent the strong concurrence of a few
      individuals, with others being silent, or does the interested
      community as a whole understand and agree with it?

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.

There was no discontent with the document.

(1.f) 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
      entered into the ID Tracker.)

No threats or discontent.

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits? (See the Internet-Drafts Checklist
      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
      enough; this check needs to be thorough. Has the document met all
      formal review criteria it needs to, such as the MIB Doctor, media
      type and URI type reviews?

Yes.

(1.h) Has the document split its references into normative and
      informative? 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 strategy for their
      completion? Are there normative references that are downward
      references, as described in [RFC3967]? If so, list these downward
      references to support the Area Director in the Last Call procedure
      for them [RFC3967].

References split and no downrefs.

(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body of
      the document? If the document specifies protocol extensions, are
      reservations requested in appropriate IANA registries? Are the
      IANA registries clearly identified? If the document creates a new
      registry, does it define the proposed initial contents of the
      registry and an allocation procedure for future registrations?
      Does it suggested a reasonable name for the new registry? See
      [I-D.narten-iana-considerations-rfc2434bis]. If the document
      describes an Expert Review process has Shepherd conferred with the
      Responsible Area Director so that the IESG can appoint the needed
      Expert during the IESG Evaluation?

The document makes no request for IANA action.
A null IANA section is in place.

(1.j) Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML code,
      BNF rules, MIB definitions, etc., validate correctly in an
      automated checker?

No such sections.

(1.k) The IESG approval announcement includes a Document
      Announcement Write-Up. Please provide such a Document
      Announcement Writeup? Recent examples can be found in the
      "Action" announcements for approved documents. The approval
      announcement contains the following sections:

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 sponsorhsip.

Document Quality

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