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