idnits 2.17.1 draft-berger-ccamp-attribute-bnf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4875, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5420, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4875, updated by this document, for RFC5378 checks: 2004-11-18) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 25, 2010) is 5046 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (LabN) 2 Updates: 4875, 5420, [NO-PHP-OOB] 3 Category: Standards Track George Swallow (Cisco) 4 Expiration Date: December 25, 2010 6 June 25, 2010 8 LSP Attributes Related Routing Backus-Naur Form 10 draft-berger-ccamp-attribute-bnf-00.txt 12 Abstract 14 Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) 15 established using the Resource Reservation Protocol Traffic 16 Engineering (RSVP-TE) extensions may be signaled with a set of LSP 17 specific attributes. These attributes may be carried in both Path 18 and Resv messages. This document specifies how LSP attributes are 19 to be carried in RSVP Path and Resv messages using the Routing 20 Backus-Naur Form, and clarifies related Resv message formats. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on December 25, 2010 45 Copyright and License Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1 Introduction ........................................... 2 63 1.1 Conventions Used In This Document ...................... 3 64 2 Path Messages .......................................... 3 65 2.1 Path Message Format .................................... 4 66 3 Resv Messages .......................................... 4 67 3.1 Resv Message Format -- Per LSP Operational Status ...... 5 68 3.2 Resv Message Format -- Per S2L Operational Status ...... 6 69 3.2.1 Compatibility .......................................... 6 70 4 Security Considerations ................................ 6 71 5 IANA Considerations .................................... 7 72 6 Acknowledgments ........................................ 7 73 7 References ............................................. 7 74 7.1 Normative References ................................... 7 75 7.2 Informative References ................................. 7 76 8 Authors' Addresses ..................................... 8 78 1. Introduction 80 Signaling in support of Multiprotocol Label Switching (MPLS) and 81 Generalized MPLS (GMPLS) point-to-point Label Switched Paths (LSPs) 82 is defined in [RFC3209] and [RFC3473]. [RFC4875] defines signaling 83 support for point-to-multipoint (P2MP) TE LSPs. 85 Two LSP Attributes related objects are defined in [RFC5420]. These 86 objects may be used to provide additional information related to how 87 an LSP should be setup when carried in a Path message and, when 88 carried in a Resv message, how an LSP has been established. The 89 definition of the objects includes a narrative description of related 90 message formats, see Section 9 of [RFC5420]. This definition does 91 not provide the related Routing Backus-Naur Form (BNF), [RFC5511], 92 that is typically used to define how messages are to be constructed 93 using RSVP objects. The current message format description has lead 94 to an issue in how the LSP Attributes related objects are to be 95 processed in Resv messages of P2MP LSPs. 97 This document provides the BNF for Path and Resv messages carrying 98 the LSP Attributes related object. The definition clarifies how the 99 objects are to be carried for all LSP types. Both Path and Resv 100 message BNF is provided for completeness. 102 This document presents the RSVP message related formats as modified 103 by [RFC5420]. This document modifies formats defined in [RFC3209], 104 [RFC3473] and [RFC4875]. See [RFC5511] for the syntax used by RSVP. 105 Unmodified formats are not listed. An example of a case where the 106 modified formats are applicable is described in [NO-PHP-OOB]. 108 1.1. Conventions Used In This Document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 2. Path Messages 116 This section updates [RFC4875]. Path message formatting is 117 unmodified from the narrative description provided in Section 9 of 118 [RFC5420]. As stated in [RFC5420]: 120 The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object 121 MAY be carried in a Path message. 123 The order of objects in RSVP-TE messages is recommended, but 124 implementations must be capable of receiving the objects in any 125 meaningful order. 127 On a Path message, the LSP_ATTRIBUTES object and 128 LSP_REQUIRED_ATTRIBUTES objects are RECOMMENDED to be placed 129 immediately after the SESSION_ATTRIBUTE object if it is present, 130 or otherwise immediately after the LABEL_REQUEST object. 132 If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES 133 object are present, the LSP_REQUIRED_ATTRIBUTES object is 134 RECOMMENDED to be placed first. 136 LSRs MUST be prepared to receive these objects in any order in any 137 position within a Path message. Subsequent instances of these 138 objects within a Path message SHOULD be ignored and MUST be 139 forwarded unchanged. 141 2.1. Path Message Format 143 This section presents the Path message format as modified by 144 [RFC5420]. Unmodified formats are not listed. 146 ::= [ ] 147 [ [ | ] ...] 148 [ ] 149 150 151 [ ] 152 153 [ ] 154 [ ... ] 155 [ ] 156 [ ... ] 157 [ ... ] 158 [ ] 159 [ ] 160 [ ... ] 161 162 [] 164 Note that PathErr and PathTear messages are not impacted by the 165 introduction of the LSP attributed related objects. 167 3. Resv Messages 169 This section updates [RFC4875] and [RFC5420]. Section 9 of [RFC5420] 170 contains the following Resv message related text: 172 The LSP_ATTRIBUTES object MAY be carried in a Resv message. 174 The order of objects in RSVP-TE messages is recommended, but 175 implementations must be capable of receiving the objects in any 176 meaningful order. 178 On a Resv message, the LSP_ATTRIBUTES object is placed in the flow 179 descriptor and is associated with the FILTER_SPEC object that 180 precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be 181 placed immediately after the LABEL object. 183 LSRs MUST be prepared to receive this object in any order in any 184 position within a Resv message, subject to the previous note. 185 Only one instance of the LSP_ATTRIBUTES object is meaningful 186 within the context of a FILTER_SPEC object. Subsequent instances 187 of the object SHOULD be ignored and MUST be forwarded unchanged. 189 This means that LSP attributes may be present per sender (LSP) and 190 allows for LSP attributes object to be modified using make-before- 191 break, see RFC3209. This definition is sufficient for point-to-point 192 ([RFC3209] and [RFC3473]) LSPs, and the special case where all point- 193 to-multipoint source-to-leaf (S2L) sub-LSPs ([RFC4875]) report the 194 same operational status (as used in [RFC5420]). But, this definition 195 does not allow for different egress LSRs to report different report 196 operational status. In order to allow such reporting, this document 197 adds the following definition: 199 An LSR that wishes to report operational status of a (point-to- 200 multipoint) S2L sub-LSP may include the LSP_ATTRIBUTES object in a 201 Resv message, or update the object that is already carried in a 202 Resv message. LSP_ATTRIBUTES objects representing S2L sub-LSP 203 status MUST follow a S2L_SUB_LSP object. Only the first instance 204 of the LSP_ATTRIBUTES object is meaningful within the context of a 205 S2L_SUB_LSP object. Subsequent instances of the object SHOULD be 206 ignored and MUST be forwarded unchanged. 208 When an LSP_ATTRIBUTES object is present before the first 209 S2L_SUB_LSP object, the LSP_ATTRIBUTES object represents the 210 operational status of the whole point-to-multipoint LSP. 211 Subsequent instances of the object SHOULD be ignored and MUST be 212 forwarded unchanged. Relative object positioning SHOULD be 213 preserved. 215 3.1. Resv Message Format -- Per LSP Operational Status 217 This section presents the Resv message format for LSPs as modified by 218 [RFC5420], and can be used to report operational status per LSP. 219 Unmodified formats are not listed. This following is based on 220 [RFC4875]. 222 ::= 223 [ ] 225 ::= [ ]