Subject: [CCAMP] Protocol Action: 'LSP Attributes Related Routing Backus-Naur Form' to Proposed Standard (draft-ietf-ccamp-attribute-bnf-02.txt)

From: The IESG <[email-masked]>
Date: Mon, 24 Oct 2011 10:26:54 -0700

The IESG has approved the following document:
- 'LSP Attributes Related Routing Backus-Naur Form'
  (draft-ietf-ccamp-attribute-bnf-02.txt) as a Proposed Standard

This document is the product of the Common Control and Measurement Plane
Working Group.

The IESG contact persons are Adrian Farrel and Stewart Bryant.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-ccamp-attribute-bnf/

Technical Summary

  Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
  established using the Resource Reservation Protocol Traffic
  Engineering (RSVP-TE) extensions may be signaled with a set of LSP
  specific attributes. These attributes may be carried in both Path
  and Resv messages. This document specifies how LSP attribute are
  to be carried in RSVP Path and Resv messages using the Routing
  Backus-Naur Form, and clarifies related Resv message formats.
  This document updates RFC 4875 and RFC 5420.

Working Group Summary

  No issues. The document is considered to be both stable and
  complete.

  Note that the "updates" cahin for RSVP-TE is quite complex and it
  is customary to only show the updates for the head of the chain in
  any new update. Thus, this document is shown as updating RFC 4875
  and RFC 5420, but not RFC 3209 or RFC 3473.

Document Quality

  Note that no formal tool exists for checking RBNF as defined in
  RFC 5511. Thus, all checks have been done by hand/eye.

  No implementations have been publicly discussed. 

  However, implementations of RFC 4875 and RFC 5420 are
  known to exist, and are conformant with this specification.

  Furthermore, this document is required as a normative 
  reference from draft-ietf-mpls-rsvp-te-no-php-oob-mapping
  which is known to have been implemented.

Personnel

   Deborah Brungard ([email-masked]) is the Document Shepherd
   Adrian Farrel ([email-masked]) is the Responsible AD

RFC Editor Note

Please edit for consistency:
    The objects are called "LSP Attributes" and "LSP Required Attributes"

Section 1
OLD:
   processed in Resv messages of P2MP LSPs.
NEW
   processed in Resv messages of P2MP LSPs (which are defined in
   [RFC4875]).
END

Section 1
OLD:
   The current message format description has led
   to an issue in how the LSP Attributes related objects are to be
   processed...
NEW
   The current message format description has led to the open
   question of how the LSP Attributes related objects are to be
   processed...
END

Section 3.2.1
OLD:
   A node that does not support the LSP Attribute object formatting as
   defined in this section will interpret the first present LSP
   Attribute object as representing LSP operational status even when it
   is intended to represent S2L sub-LSP status.
NEW:
   A node that supports [RFC4875] and [RFC5420], but not this
   document, will interpret the first LSP Attribute object present in
   a received message, which is formatted as described in this
   document, as representing LSP operational status rather than S2L
   sub-LSP status.
END