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 (dbrungard@att.com) is the Document Shepherd Adrian Farrel (adrian@olddog.co.uk) 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 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
