idnits 2.17.1 draft-ietf-ccamp-attribute-bnf-02.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 abstract seems to indicate that this document updates RFC5420, but the header doesn't have an 'Updates:' line to match this. 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 (August 19, 2011) is 4596 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 (==), 3 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 3 Category: Standards Track George Swallow (Cisco) 4 Expiration Date: February 19, 2012 6 August 19, 2011 8 LSP Attributes Related Routing Backus-Naur Form 10 draft-ietf-ccamp-attribute-bnf-02.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 attribute are 19 to be carried in RSVP Path and Resv messages using the Routing 20 Backus-Naur Form, and clarifies related Resv message formats. 21 This document updates RFC 4875 and RFC 5420. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on February 19, 2012 46 Copyright and License Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1 Introduction ........................................... 2 64 1.1 Conventions Used In This Document ...................... 3 65 2 Path Messages .......................................... 3 66 2.1 Path Message Format .................................... 4 67 3 Resv Messages .......................................... 4 68 3.1 Resv Message Format -- Per LSP Operational Status ...... 5 69 3.2 Resv Message Format -- Per S2L Operational Status ...... 6 70 3.2.1 Compatibility .......................................... 6 71 4 Security Considerations ................................ 7 72 5 IANA Considerations .................................... 7 73 6 Acknowledgments ........................................ 7 74 7 References ............................................. 7 75 7.1 Normative References ................................... 7 76 7.2 Informative References ................................. 8 77 8 Authors' Addresses ..................................... 8 79 1. Introduction 81 Signaling in support of Multiprotocol Label Switching (MPLS) and 82 Generalized MPLS (GMPLS) point-to-point Label Switched Paths (LSPs) 83 is defined in [RFC3209] and [RFC3473]. [RFC4875] defines signaling 84 support for point-to-multipoint (P2MP) TE LSPs. 86 Two LSP Attributes related objects are defined in [RFC5420]. These 87 objects may be used to provide additional information related to how 88 an LSP should be setup when carried in a Path message and, when 89 carried in a Resv message, how an LSP has been established. The 90 definition of the objects includes a narrative description of related 91 message formats, see Section 9 of [RFC5420]. This definition does 92 not provide the related Routing Backus-Naur Form (BNF), [RFC5511], 93 that is typically used to define how messages are to be constructed 94 using RSVP objects. The current message format description has led 95 to an issue in how the LSP Attributes related objects are to be 96 processed in Resv messages of P2MP LSPs. 98 This document provides the BNF for Path and Resv messages carrying 99 the LSP Attributes related object. The definition clarifies how the 100 objects are to be carried for all LSP types. Both Path and Resv 101 message BNF is provided for completeness. 103 This document presents the RSVP message related formats as modified 104 by [RFC5420]. This document modifies formats defined in [RFC3209], 105 [RFC3473] and [RFC4875]. See [RFC5511] for the syntax used by RSVP. 106 Unmodified formats are not listed. An example of a case where the 107 modified formats are applicable is described in [NO-PHP-OOB]. 109 1.1. Conventions Used In This Document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2. Path Messages 117 This section updates [RFC4875]. Path message formatting is 118 unmodified from the narrative description provided in Section 9 of 119 [RFC5420]. As stated in [RFC5420]: 121 The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object 122 MAY be carried in a Path message. 124 The order of objects in RSVP-TE messages is recommended, but 125 implementations must be capable of receiving the objects in any 126 meaningful order. 128 On a Path message, the LSP_ATTRIBUTES object and 129 LSP_REQUIRED_ATTRIBUTES objects are RECOMMENDED to be placed 130 immediately after the SESSION_ATTRIBUTE object if it is present, 131 or otherwise immediately after the LABEL_REQUEST object. 133 If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES 134 object are present, the LSP_REQUIRED_ATTRIBUTES object is 135 RECOMMENDED to be placed first. 137 LSRs MUST be prepared to receive these objects in any order in any 138 position within a Path message. Subsequent instances of these 139 objects within a Path message SHOULD be ignored and MUST be 140 forwarded unchanged. 142 2.1. Path Message Format 144 This section presents the Path message format as modified by 145 [RFC5420]. Unmodified formats are not listed. 147 ::= [ ] 148 [ [ | ] ...] 149 [ ] 150 151 152 [ ] 153 154 [ ] 155 [ ... ] 156 [ ] 157 [ ... ] 158 [ ... ] 159 [ ] 160 [ ] 161 [ ... ] 162 163 [] 165 Note that PathErr and PathTear messages are not impacted by the 166 introduction of the LSP attributed related objects. 168 3. Resv Messages 170 This section updates [RFC4875] and [RFC5420]. Section 9 of [RFC5420] 171 contains the following Resv message related text: 173 The LSP_ATTRIBUTES object MAY be carried in a Resv message. 175 The order of objects in RSVP-TE messages is recommended, but 176 implementations must be capable of receiving the objects in any 177 meaningful order. 179 On a Resv message, the LSP_ATTRIBUTES object is placed in the flow 180 descriptor and is associated with the FILTER_SPEC object that 181 precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be 182 placed immediately after the LABEL object. 184 LSRs MUST be prepared to receive this object in any order in any 185 position within a Resv message, subject to the previous note. 186 Only one instance of the LSP_ATTRIBUTES object is meaningful 187 within the context of a FILTER_SPEC object. Subsequent instances 188 of the object SHOULD be ignored and MUST be forwarded unchanged. 190 This means that LSP attributes may be present per sender (LSP) and 191 allows for LSP attributes object to be modified using make-before- 192 break, see RFC3209. This definition is sufficient for point-to-point 193 ([RFC3209] and [RFC3473]) LSPs, and the special case where all point- 194 to-multipoint source-to-leaf (S2L) sub-LSPs ([RFC4875]) report the 195 same operational status (as used in [RFC5420]). But, this definition 196 does not allow for different egress LSRs to report different 197 operational status. In order to allow such reporting, this document 198 adds the following definition: 200 An LSR that wishes to report operational status of a (point-to- 201 multipoint) S2L sub-LSP, it may include the LSP_ATTRIBUTES object 202 in a Resv message, or update the object that is already carried in 203 a Resv message. LSP_ATTRIBUTES objects representing S2L sub-LSP 204 status MUST follow a S2L_SUB_LSP object. Only the first instance 205 of the LSP_ATTRIBUTES object is meaningful within the context of a 206 S2L_SUB_LSP object. Subsequent instances of the object SHOULD be 207 ignored and MUST be forwarded unchanged. 209 When an LSP_ATTRIBUTES object is present before the first 210 S2L_SUB_LSP object, the LSP_ATTRIBUTES object represents the 211 operational status of all S2L sub-LSPs identified in the message. 212 Subsequent instances of the object (e.g, in the filter spec or the 213 S2L sub-LSP flow descriptor) SHOULD be ignored and MUST be 214 forwarded unchanged. When a branch node is combining Resv state 215 from multiple receivers into a single Resv message and an 216 LSP_ATTRIBUTES object is present before the first S2L_SUB_LSP 217 object in a received Resv message, the received LSP_ATTRIBUTES 218 object SHOULD be moved to follow the first received S2L_SUB_LSP 219 object, and then SHOULD be duplicated for, and placed after, each 220 subsequent S2L_SUB_LSP object. 222 3.1. Resv Message Format -- Per LSP Operational Status 224 This section presents the Resv message format for LSPs as modified by 225 [RFC5420], and can be used to report operational status per LSP. 226 Unmodified formats are not listed. This following is based on 227 [RFC4875]. 229 ::= 230 [ ] 232 ::= [ ]