idnits 2.17.1 draft-bishnoi-mpls-mldp-opaque-types-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 contain references ([MLDP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 26, 2009) is 5295 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) == Missing Reference: 'BGP-MVPN' is mentioned on line 225, but not defined == Missing Reference: 'BGP-MPN' is mentioned on line 200, but not defined == Missing Reference: 'RFC-2119' is mentioned on line 154, but not defined == Unused Reference: 'RFC2119' is defined on line 294, but no explicit reference was found in the text == Unused Reference: 'RFC2685' is defined on line 297, but no explicit reference was found in the text == Unused Reference: 'MVPN-BGP' is defined on line 306, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-06 == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-08 == Outdated reference: A later version (-08) exists of draft-ietf-l3vpn-2547bis-mcast-bgp-07 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Sandeep Bishnoi 2 Internet Draft Pranjal Kumar Dutta 3 Intended status: Standards Track Alcatel-Lucent 4 Expires: April 2010 5 IJsbrand Wijnands 6 Cisco Systems, Inc. 8 October 26, 2009 10 LDP Multipoint Opaque Value Element Types 12 draft-bishnoi-mpls-mldp-opaque-types-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on April 26, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the BSD License. 52 Abstract 54 [MLDP] describes extensions to the Label Distribution Protocol (LDP) 55 for setup of point to multi-point (P2MP) and multipoint-to-multipoint 56 (MP2MP) Label Switched Paths (LSPs). LDP forwarding equivalence class 57 (FEC) elements used to establish P2MP and MP2MP LSPs include type- 58 length-value (TLV) fields that carry information meaningful to 59 Ingress LSRs and Leaf LSRs and are termed as Opaque Value Elements in 60 [MLDP]. This document defines Opaque Value Element structure to be 61 used for provisioning P2MP and MP2MP Provider tunnels (P-Tunnels) for 62 Multicast Virtual Private Network (MVPN). It is envisioned that this 63 would be useful for security and manageability of P-Tunnels used for 64 MVPN from the ones provisioned for other applications and vice-versa. 66 Table of Contents 68 1. Introduction...................................................2 69 2. Terminology....................................................4 70 3. Conventions used in this document..............................4 71 4. Structure for the New Opaque Value Element Type................4 72 4.1. Opaque Value Element Type 0...............................4 73 4.2. Opaque Value Element Type 1...............................5 74 4.3. Opaque Value Element Type 2...............................6 75 5. Security Considerations........................................7 76 6. IANA Considerations............................................7 77 7. Conclusions....................................................7 78 8. References.....................................................7 79 8.1. Normative References......................................7 80 8.2. Informative References....................................8 81 9. Acknowledgments................................................8 83 1. Introduction 85 [MLDP] defines the extensions to LDP and procedures for establishing 86 P2MP and MP2MP LSPs in Multi-Protocol Label Switch (MPLS) networks. 87 Throughout this document P2MP and MP2MP LSPs are collectively 88 referred as multi-point (MP) LSPs. When a MP LSP is setup, the LDP 89 signaling messages include a forwarding equivalence class (FEC) 90 element that uniquely identifies the MP LSP in LDP. 92 For the setup of a P2MP LSP with LDP, P2MP FEC Element is used as a 93 FEC Element in LDP FEC TLV. Similarly for MP2MP LSP, MP2MP FEC 94 Element is used. Both types of FEC elements contain MP Opaque Value 95 Element in type-length-value format. 97 The LDP MP Opaque Value Element defined in [MLDP] is as follows: 99 0 1 2 3 100 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Type | Length | Value ... | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 104 ~ ~ 105 | | 106 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 Figure 1. 112 The use of the opaque value in MP FEC Element provides the 113 flexibility to structure an MP FEC Element to best fit the needs of a 114 particular application or provisioning model. 116 An opaque value that is globally unique would facilitate MP LSP 117 management and security in large inter-AS (autonomous system) and 118 inter-provider environments. Providers would not have to worry about 119 opaque value overlap during provisioning LDP MP LSPs for various 120 applications. Globally unique opaque values per application types 121 could aid in troubleshooting as well. 123 For example, a provider may provision P2MP LSPs in its network by 124 manually provisioning at the root and the leaf nodes. The same root 125 node may also initiate dynamic provisioning of P2MP LSPs for MVPN 126 P-Tunnels by using BGP auto-discovery (AD) procedures described in 127 [BGP-MVPN]. For manageability and security reasons, it is required to 128 have a separate Opaque Value Element space available entirely for 129 manual provisioning and another space for allocation and distribution 130 by BGP AD procedures for MVPNs. 132 This document defines opaque value structures based on [MLDP] that: 134 . Ensures uniqueness among applications if desired by provider. 135 This will facilitate provisioning of LDP MP Tunnels for various 136 applications without conflict of Opaque Value Element space. 138 This is accomplished by defining new opaque value element types and 139 the associated formats of the value field. 141 2. Terminology 143 This document uses the terminology defined in [MLDP], [MVPN] and 144 [BGP-MPN]. 146 3. Conventions used in this document 148 In examples, "C:" and "S:" indicate lines sent by the client and 149 server respectively. 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC-2119]. 155 4. Structure for the New Opaque Value Element Type 157 [MLDP] defines the format of P2MP and MP2MP FEC Element and the use 158 and semantics of Opaque Value Elements. 160 4.1. Opaque Value Element Type 0 162 This document recommends to use type 0 to manage the identifier space 163 for manual or statically provisioned general purpose P2MP and MP2MP 164 LSPs. Mapping of traffic to MP LSPs provisioned with this type is 165 outside the scope of this document. 167 Statically provisioned P2MP and MP2MP LSPs preferably should have a 168 common identifier space across implementations. Recommendation to use 169 type 0 for all statically provisioned P2MP and MP2MP LSPs would allow 170 common identifier space to be available across all implementations. 171 This would avoid incompatibility of identifier space across multiple 172 vendor implementations and allow seamless replacement of root node 173 without changing configuration on all leaf nodes. 175 0 1 2 3 176 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Type= 00 | Length |LSP Identifier | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | LSP Identifier (contd.) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 2. 183 . AII Type = 0x00 184 . Length = length of value field in octets. The length is set to 185 4. 186 . LSP Identifier = A 4-octet field containing a value that is 187 unique at a root node. 189 4.2. Opaque Value Element Type 1 191 Opaque Value Element Type 1 is defined to be used exclusively for 192 dynamically provisioned MP LDP Tunnels for MVPNs [BGP-MVPN]. This 193 enables the opaque value space to be managed and used entirely for 194 BGP MVPNs without any risk of overlap with other applications that 195 use LDP MP Tunnels. 197 [BGP-MVPN] defines and uses a new BGP attribute, called P-Multicast 198 Service Interface Tunnel (PMSI Tunnel) attribute that is distributed 199 with MVPN AD routes in BGP. The attribute carries a Tunnel Type and 200 Tunnel Identifier of the P-Tunnel bound to MCAST-VPN-NLRI [BGP-MPN]. 201 If Tunnel type is set to LDP P2MP LSP then it carries P2MP FEC 202 Element with Opaque Value Element type 1. If tunnel type is set to 203 mLdp MP2MP LSP then it carries MP2MP FEC Element with Opaque Value 204 Element type 1. 206 The Opaque Value Element type 1 uses a 32 bit Global-ID to create 207 globally unique values of P-Tunnels. The encoding of opaque value 208 element type 1 is shown in Figure 3. below. 210 0 1 2 3 211 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Type= 01 | Length | Global ID | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Global ID (contd.) | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 3. 218 . AII Type = 0x01 219 . Length = length of value field in octets. The length is set to 220 4. 221 . Global ID = This is a 4-octet field containing a value that is 222 unique within P-Tunnels initiated by BGP AD at a root node. 224 This type of Opaque Value Element is mapped to traffic by procedures 225 defined in [BGP-MVPN] and is outside the scope of this document. 227 4.3. Opaque Value Element Type 2 229 Opaque Value Element Type 2 is defined to be used exclusively for 230 statically provisioned MP LDP Tunnels for MVPNs [MVPN]. This enables 231 the opaque value space to be managed and used entirely for static 232 MVPNs without any risk of overlap with other applications that use 233 LDP MP Tunnels. 235 Statically provisioned P2MP and MP2MP LSPs for MVPN is based on the 236 encoding as specified in RFC2685 in combination with a PMSI ID. PSMI 237 ID number 0 indicates a Mi-PMSI, non-zero numbers indicate a S-PMSI. 239 0 1 2 3 240 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Type= 2 | Length | OUI | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | OUI (contd.) | VPN Index | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | VPN Index (contd.) | PMSI ID | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | PMSI ID (contd.) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Figure 4. 252 . AII Type = 0x02 253 . Length = length of value field in octets. The length is set to 254 11. 255 . OUI = Organization Unique Identifier. The length is set to 3 256 bytes. 258 . VPN Index = Identifying the VPN according to the OUI. The length 259 is set to 4 bytes. 260 . PMSI ID = Mi-PMSI or S-PMSI identifier. The length is set to 4 261 bytes. 263 This type of Opaque Value Element is mapped to traffic by procedures 264 defined in [MVPN] and is outside the scope of this document. 266 5. Security Considerations 268 The same security considerations apply as for the base LDP 269 specification, as described in [RFC5036] and MP LDP specification, as 270 described in [MLDP]. 272 6. IANA Considerations 274 This document requires allocation of new Opaque Value Element Types 275 (0x00 and 0x02). 277 7. Conclusions 279 Further types of Opaque Value Elements are a subject of future study 280 and would be defined in later versions based on requirements. 282 8. References 284 8.1. Normative References 286 [MLDP] I. Minei, K., Kompella, I. Wijnands, B. Thomas, "Label 287 Distribution Protocol Extensions for Point-to-Multipoint 288 and Multipoint-to-Multipoint Label Switched Paths", 289 draft-ietf-mpls-ldp-p2mp-06.txt, May 2008 291 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 292 Specification", RFC 5036, October 2007. 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 [RFC2685] Fox, B., Gleeson, B., ''Virtual Private Networks 298 Identifier'', RFC 2685, September 1999. 300 8.2. Informative References 302 [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in MPLS/BGP 303 IP VPNs", draft-ietf-l3vpn-2547bis-mcast-08.txt, 304 March 5 2009 306 [MVPN-BGP] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, 307 C.Kodeboniya, "BGP Encodings for Multicast in MPLS/BGP IP 308 VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt, 309 April 2009 311 9. Acknowledgments 313 The authors would like acknowledge the comments and suggestions from 314 Wim Henderickx and Mustapha Aissaoui. 316 This document was prepared using 2-Word-v2.0.template.dot. 318 Authors' Addresses 320 Sandeep Bishnoi 321 Alcatel-Lucent 322 701 E Middlefield Road, 323 Mountain View, CA 94043 324 USA 326 Email: sandeep.bishnoi@alcatel-lucent.com 328 Pranjal Kumar Dutta 329 Alcatel-Lucent 330 701 E Middlefield Road, 331 Mountain View, CA 94043 332 USA 334 Email: pranjal.dutta@alcatel-lucent.com 335 IJsbrand Wijnands 336 Cisco Systems, Inc. 337 De kleetlaan 6a 338 Diegem 1831 339 Belgium 341 Email: ice@cisco.com