draft-ietf-ccamp-attribute-bnf-01.txt   draft-ietf-ccamp-attribute-bnf-02.txt 
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Updates: 4875, 5420, [NO-PHP-OOB] Updates: 4875, 5420
Category: Standards Track George Swallow (Cisco) Category: Standards Track George Swallow (Cisco)
Expiration Date: November 11, 2011 Expiration Date: February 19, 2012
May 11, 2011 August 19, 2011
LSP Attributes Related Routing Backus-Naur Form LSP Attributes Related Routing Backus-Naur Form
draft-ietf-ccamp-attribute-bnf-01.txt draft-ietf-ccamp-attribute-bnf-02.txt
Abstract Abstract
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
established using the Resource Reservation Protocol Traffic established using the Resource Reservation Protocol Traffic
Engineering (RSVP-TE) extensions may be signaled with a set of LSP Engineering (RSVP-TE) extensions may be signaled with a set of LSP
specific attributes. These attributes may be carried in both Path specific attributes. These attributes may be carried in both Path
and Resv messages. This document specifies how LSP attributes are and Resv messages. This document specifies how LSP attribute are
to be carried in RSVP Path and Resv messages using the Routing to be carried in RSVP Path and Resv messages using the Routing
Backus-Naur Form, and clarifies related Resv message formats. Backus-Naur Form, and clarifies related Resv message formats.
This document updates RFC 4875 and RFC 5420.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 44 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 11, 2011 This Internet-Draft will expire on February 19, 2012
Copyright and License Notice Copyright and License Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 45 skipping to change at page 3, line 5
support for point-to-multipoint (P2MP) TE LSPs. support for point-to-multipoint (P2MP) TE LSPs.
Two LSP Attributes related objects are defined in [RFC5420]. These Two LSP Attributes related objects are defined in [RFC5420]. These
objects may be used to provide additional information related to how objects may be used to provide additional information related to how
an LSP should be setup when carried in a Path message and, when an LSP should be setup when carried in a Path message and, when
carried in a Resv message, how an LSP has been established. The carried in a Resv message, how an LSP has been established. The
definition of the objects includes a narrative description of related definition of the objects includes a narrative description of related
message formats, see Section 9 of [RFC5420]. This definition does message formats, see Section 9 of [RFC5420]. This definition does
not provide the related Routing Backus-Naur Form (BNF), [RFC5511], not provide the related Routing Backus-Naur Form (BNF), [RFC5511],
that is typically used to define how messages are to be constructed that is typically used to define how messages are to be constructed
using RSVP objects. The current message format description has lead using RSVP objects. The current message format description has led
to an issue in how the LSP Attributes related objects are to be to an issue in how the LSP Attributes related objects are to be
processed in Resv messages of P2MP LSPs. processed in Resv messages of P2MP LSPs.
This document provides the BNF for Path and Resv messages carrying This document provides the BNF for Path and Resv messages carrying
the LSP Attributes related object. The definition clarifies how the the LSP Attributes related object. The definition clarifies how the
objects are to be carried for all LSP types. Both Path and Resv objects are to be carried for all LSP types. Both Path and Resv
message BNF is provided for completeness. message BNF is provided for completeness.
This document presents the RSVP message related formats as modified This document presents the RSVP message related formats as modified
by [RFC5420]. This document modifies formats defined in [RFC3209], by [RFC5420]. This document modifies formats defined in [RFC3209],
skipping to change at page 5, line 8 skipping to change at page 5, line 8
Only one instance of the LSP_ATTRIBUTES object is meaningful Only one instance of the LSP_ATTRIBUTES object is meaningful
within the context of a FILTER_SPEC object. Subsequent instances within the context of a FILTER_SPEC object. Subsequent instances
of the object SHOULD be ignored and MUST be forwarded unchanged. of the object SHOULD be ignored and MUST be forwarded unchanged.
This means that LSP attributes may be present per sender (LSP) and This means that LSP attributes may be present per sender (LSP) and
allows for LSP attributes object to be modified using make-before- allows for LSP attributes object to be modified using make-before-
break, see RFC3209. This definition is sufficient for point-to-point break, see RFC3209. This definition is sufficient for point-to-point
([RFC3209] and [RFC3473]) LSPs, and the special case where all point- ([RFC3209] and [RFC3473]) LSPs, and the special case where all point-
to-multipoint source-to-leaf (S2L) sub-LSPs ([RFC4875]) report the to-multipoint source-to-leaf (S2L) sub-LSPs ([RFC4875]) report the
same operational status (as used in [RFC5420]). But, this definition same operational status (as used in [RFC5420]). But, this definition
does not allow for different egress LSRs to report different report does not allow for different egress LSRs to report different
operational status. In order to allow such reporting, this document operational status. In order to allow such reporting, this document
adds the following definition: adds the following definition:
An LSR that wishes to report operational status of a (point-to- An LSR that wishes to report operational status of a (point-to-
multipoint) S2L sub-LSP, it may include the LSP_ATTRIBUTES object multipoint) S2L sub-LSP, it may include the LSP_ATTRIBUTES object
in a Resv message, or update the object that is already carried in in a Resv message, or update the object that is already carried in
a Resv message. LSP_ATTRIBUTES objects representing S2L sub-LSP a Resv message. LSP_ATTRIBUTES objects representing S2L sub-LSP
status MUST follow a S2L_SUB_LSP object. Only the first instance status MUST follow a S2L_SUB_LSP object. Only the first instance
of the LSP_ATTRIBUTES object is meaningful within the context of a of the LSP_ATTRIBUTES object is meaningful within the context of a
S2L_SUB_LSP object. Subsequent instances of the object SHOULD be S2L_SUB_LSP object. Subsequent instances of the object SHOULD be
skipping to change at page 7, line 8 skipping to change at page 7, line 8
is a significant issue as the LSP Attribute object is currently is a significant issue as the LSP Attribute object is currently
considered to be an unsuitable mechanism for reporting operational considered to be an unsuitable mechanism for reporting operational
status of P2MP LSPs, for example see Section 2.1 of [NO-PHP-OOB]. status of P2MP LSPs, for example see Section 2.1 of [NO-PHP-OOB].
The intent of this document is to correct this limitation and it is The intent of this document is to correct this limitation and it is
expected that networks that wish to make use of such operational expected that networks that wish to make use of such operational
reporting will deploy this extension. reporting will deploy this extension.
4. Security Considerations 4. Security Considerations
This document clarifies usage of objects defined in [RFC5420]. No This document clarifies usage of objects defined in [RFC5420]. No
new information is conveyed and therefore neither are any additional new information is conveyed and therefore neither are there any
security considerations. For a general discussion on MPLS and GMPLS additional security considerations. For a general discussion on MPLS
related security issues, see the MPLS/GMPLS security framework and GMPLS related security issues, see the MPLS/GMPLS security
[RFC5920]. framework [RFC5920].
5. IANA Considerations 5. IANA Considerations
There are no new IANA considerations introduced by this document. There are no new IANA considerations introduced by this document.
6. Acknowledgments 6. Acknowledgments
The authors would like to acknowledge the contributions of Adrian The authors would like to acknowledge the contributions of Adrian
Farrel. Farrel.
skipping to change at page 8, line 12 skipping to change at page 8, line 12
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009 Specifications", RFC 5511, April 2009
7.2. Informative References 7.2. Informative References
[NO-PHP-OOB] Ali, Z., Swallow, G., "Non PHP Behavior and [NO-PHP-OOB] Ali, Z., Swallow, G., "Non PHP Behavior and
out-of-band mapping for RSVP-TE LSPs", work in out-of-band mapping for RSVP-TE LSPs", work in
progress, draft-ietf-mpls-rsvp-te-no-php-oob-mapping. progress, draft-ietf-mpls-rsvp-te-no-php-oob-mapping.
[RFC5920] Fang, L., [RFC5920] Fang, L.,
"Security Framework for MPLS and GMPLS Networks", RFC 5920, "Security Framework for MPLS and GMPLS Networks",
July 2010. RFC 5920, July 2010.
8. Authors' Addresses 8. Authors' Addresses
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Phone: +1-301-468-9228 Phone: +1-301-468-9228
Email: lberger@labn.net Email: lberger@labn.net
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
Email: swallow@cisco.com Email: swallow@cisco.com
Generated on: Wed, May 11, 2011 6:02:06 PM Generated on: Fri, Aug 19, 2011 10:14:59 AM
 End of changes. 12 change blocks. 
14 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/