idnits 2.17.1 draft-ietf-mpls-ldp-applicability-label-adv-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 draft header indicates that this document updates RFC6388, but the abstract doesn't seem to directly say this. It does mention RFC6388 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3212, updated by this document, for RFC5378 checks: 1999-01-27) -- 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 (January 20, 2014) is 3748 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) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Kamran Raza 2 Internet Draft Sami Boutros 3 Updates: 5036, 4447, 5918, 6388, 3212 Luca Martini 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: July 19, 2014 6 Nicolai Leymann 7 Deutsche Telekom 9 January 20, 2014 11 Label Advertisement Discipline for LDP FECs 13 draft-ietf-mpls-ldp-applicability-label-adv-02.txt 15 Abstract 17 The label advertising behavior of an LDP speaker for a given FEC is 18 governed by the FEC type and not necessarily by the LDP session's 19 negotiated label advertisement mode. This document updates RFC 5036 20 to make that fact clear, as well as updates RFC 3212, RFC 4447, 21 RFC 5918, and RFC 6388 by specifying the label advertisement mode 22 for all currently defined FECs. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on July 19, 2014. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction 2 65 2. Label Advertisement Discipline 3 66 2.1. Update to RFC-5036 3 67 2.2. Specification for LDP FECs 4 68 3. Security Considerations 4 69 4. IANA Considerations 4 70 5. References 5 71 5.1. Normative References 5 72 5.2. Informative References 5 73 6. Acknowledgments 5 75 1. Introduction 77 Label Distribution Protocol (LDP) [RFC5036] allows label 78 advertisement mode negotiation at the time of session establishment. 79 LDP specification also dictates that only single label advertisement 80 mode is negotiated, agreed and used for a given LDP session between 81 two LSRs. 83 The negotiated label advertisement mode defined in RFC 5036 and 84 carried in the LDP Initialization message is only indicative. It 85 indicates how the LDP speakers on a session will advertise labels for 86 some FECs, but it is not a rule that restricts the speakers to behave 87 in a specific way. Furthermore, for some FEC types the advertising 88 behavior of the LDP speaker is governed by the FEC type and not by 89 the negotiated behavior. 91 This document updates [RFC5036] to make that fact clear, and updates 92 [RFC3212], [RFC4447], [RFC5036], [RFC5918], and [RFC6388] to indicate 93 for each FEC type that has already been defined whether the label 94 binding advertisements for the FEC are constrained by the negotiated 95 label advertisement mode or not. Furthermore, this document specifies 96 the label advertisement mode to be used for all currently defined 97 LDP FECs. 99 2. Label Advertisement Discipline 101 To remove any ambiguity and conflict regarding label advertisement 102 discipline amongst different FEC types sharing a common LDP session, 103 this document specifies a label advertisement disciplines for FEC 104 types. 106 This document introduces following types for specifying a label 107 advertisement discipline for a FEC type: 109 - DU (Downstream Unsolicited) 110 - DoD (Downstream On Demand) 111 - As negotiated (DU or DoD) 112 - Upstream ([RFC6389]) 113 - Not Applicable 115 2.1. Update to RFC-5036 117 The section 3.5.3 of [RFC5036] is updated to add following two 118 statements under the description of "A, Label Advertisement 119 Discipline": 121 - Each document defining an LDP FEC must state the applicability 122 of the negotiated label advertisement discipline for label 123 binding advertisements for that FEC. If the negotiated label 124 advertisement discipline does not apply to the FEC, the 125 document must also explicitly state the discipline to be used 126 for the FEC. 128 - This document defines the label advertisement discipline for 129 the following FEC types: 131 +----------+----------+--------------------------------+ 132 | FEC Type | FEC Name | Label advertisement discipline | 133 +----------+----------+--------------------------------+ 134 | 0x01 | Wildcard | Not applicable | 135 | 0x02 | Prefix | As negotiated (DU or DoD) | 136 +----------+----------+--------------------------------+ 138 2.2. Specification for LDP FECs 140 Following is the specification of label advertisement disciplines to 141 be used for currently defined LDP FEC types. 143 +------+----------------+--------------------------------+------+ 144 | FEC | FEC Name | Label advertisement discipline |RFC | 145 | Type | | | | 146 +------+----------------+--------------------------------+------+ 147 | 0x01 | Wildcard | Not applicable | 5036 | 148 | 0x02 | Prefix | As negotiated (DU or DoD) | 5036 | 149 | 0x04 | CR-LSP | DoD | 3212 | 150 | 0x05 | Typed Wildcard | Not applicable | 5918 | 151 | 0x06 | P2MP | DU | 6388 | 152 | 0x07 | MP2MP-up | DU | 6388 | 153 | 0x08 | MP2MP-down | DU | 6388 | 154 | 0x80 | PWid | DU | 4447 | 155 | 0x81 | Gen. PWid | DU | 4447 | 156 +------+----------------+--------------------------------+------+ 158 The above table also lists the RFC (in which given FEC type is 159 defined), and hence this document updates all the above listed RFCs. 161 3. Security Considerations 163 This document specification only clarifies the applicability of LDP 164 session's label advertisement mode, and hence does not add any LDP 165 security mechanics and considerations to those already defined in 166 the LDP specification [RFC5036]. 168 4. IANA Considerations 170 This document mandates the specification of a label advertisement 171 discipline for each defined FEC type, and hence extends IANA's 172 "Forwarding Equivalence Class (FEC) Type Name Space" registry under 173 IANA's "Label Distribution Protocol (LDP) Parameters" as follows: 175 - Add a new column titled "Label advertisement discipline" with 176 following possible values: 177 o DU 178 o DoD 179 o As negotiated (DU or DoD) 180 o Upstream 181 o Not applicable 183 - For the existing FEC types, populate this column with the 184 values listed under section 2.2. 186 5. References 188 5.1. Normative References 190 [RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP 191 Specification", RFC 5036, September 2007. 193 [RFC3212] B. Jamoussi, et al., "Constraint-Based LSP Setup using 194 LDP", RFC 3212, January 2002 196 [RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. 197 Heron, "Pseudowire Setup and Maintenance using the Label 198 Distribution Protocol", RFC 4447, April 2006. 200 [RFC5918] R. Asati, I. Minei, and B. Thomas, "Label Distribution 201 Protocol Typed Wildcard FEC", RFC 5918, August 2010. 203 [RFC6388] I. Minei, I. Wijnands, K. Kompella, and B. Thomas, "LDP 204 Extensions for P2MP and MP2MP LSPs", RFC 6388, November 205 2011. 207 [RFC6389] R. Aggarwal, and JL. Le Roux, "MPLS Upstream Label 208 Assignment for LDP", RFC 6389, November 2011. 210 5.2. Informative References 212 None. 214 6. Acknowledgments 216 We acknowledge Eric Rosen and Rajiv Asati for their initial review 217 and input on the document. 219 This document was prepared using 2-Word-v2.0.template.dot. 221 Authors' Addresses 223 Kamran Raza 224 Cisco Systems, Inc. 225 2000 Innovation Drive, 226 Ottawa, ON K2K-3E8, Canada. 227 E-mail: skraza@cisco.com 229 Sami Boutros 230 Cisco Systems, Inc. 231 3750 Cisco Way, 232 San Jose, CA 95134, USA. 233 E-mail: sboutros@cisco.com 235 Luca Martini 236 Cisco Systems, Inc. 237 9155 East Nichols Avenue, Suite 400, 238 Englewood, CO 80112, USA. 239 E-mail: lmartini@cisco.com 241 Nicolai Leymann 242 Deutsche Telekom AG, 243 Winterfeldtstrasse 21, 244 Berlin 10781, Germany. 245 E-mail: N.Leymann@telekom.de