idnits 2.17.1 draft-marques-l3vpn-schema-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 23 instances of too long lines in the document, the longest one being 127 characters in excess of 72. ** The abstract seems to contain references ([RFC4364], [I-D.marques-l3vpn-end-system]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 282: '...r implementation SHOULD support access...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 2012) is 4333 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) == Unused Reference: 'I-D.arkko-core-dev-urn' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'RFC5935' is defined on line 303, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-marques-l3vpn-end-system-05 == Outdated reference: A later version (-05) exists of draft-arkko-core-dev-urn-01 ** Downref: Normative reference to an Informational draft: draft-arkko-core-dev-urn (ref. 'I-D.arkko-core-dev-urn') Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Marques 3 Internet-Draft Contrail Systems 4 Intended status: Standards Track June 2012 5 Expires: December 01, 2012 7 IF-MAP schema for BGP/MPLS IP VPNs. 8 draft-marques-l3vpn-schema-00 10 Abstract 12 This document defines the metadata schema used to define the route 13 exchange policies of an IP VPN network. Information elements 14 conforming to this schema can be distributed using the IF-MAP [if- 15 map] specification. The schema is applicable both to the standard 16 BGP IP VPN [RFC4364] deployments within service provider environments 17 as well as end-system [I-D.marques-l3vpn-end-system] based 18 deployments. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 01, 2012. 37 Copyright Notice 39 Copyright (c) 2012 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 (http://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.1.1. customer-attachment . . . . . . . . . . . . . . . . . 5 56 2.1.2. connectivity-group . . . . . . . . . . . . . . . . . . 5 57 2.1.3. route-target . . . . . . . . . . . . . . . . . . . . . 5 58 2.1.4. provider-attachment . . . . . . . . . . . . . . . . . 5 59 2.2. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.2.1. attachment-info . . . . . . . . . . . . . . . . . . . 5 61 2.2.2. attachment-state . . . . . . . . . . . . . . . . . . . 6 62 2.2.3. binding . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2.4. group-target . . . . . . . . . . . . . . . . . . . . . 6 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 Appendix A. Schema . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 The schema defined in this document allows a management console or 72 orchestration system to define IP VPNs and their access policies and 73 distribute that information to all Provider Edge (PE) devices. It 74 also allows the PE devices to publish the information of which 75 customer attachment points are locally associated with each VPN 76 routing-table, providing a mechanism by which a management entity, 77 potentially different from the one establishing access policies, can 78 verify the operational state of the network. 80 In order to define an IP VPN, a management system, must select a 81 network name and associate it with a route-target value. That 82 operation is achieved by sending the following XML document to an IF- 83 MAP server. 85 86 88 89 90 91 92 93 94 95 96 98 A symetric VPN is implemented as a single "connectivity-group". This 99 is the scenario in which all the members of the VPN have the same 100 connectivity. However there are scenarios where the connectivity is 101 assymetric. One such example is a "hub and spoke" topology in which 102 all the traffic from spoke sites must first traverse through the 103 "hub" site. In this situation a single logic VPN corresponds to two 104 "connectivity-groups". 106 PE devices that terminate circuits attached to a connectivity-group 107 instatiate a corresponding VRF, where the VRF parameters are derived 108 from the metadata associated to the given connectivity-group. 110 In the example definition above, since no further metadata was 111 defined, the import and export route-target list for the VRFs is the 112 same and constitutes of the route-target specified in the 'group- 113 target' metadata. 115 Network connectivity information is published in the MAP server and 116 available to all PE devices which may either subscribe to 117 notification or poll the information on-demand. 119 The schema defined in this document allows for connectivity-groups to 120 be interconnected via a metadata element called 'connection'. When 121 that element is present the local PE VRFs should be configured such 122 that its vrf-import target lists include the 'group-target's 123 associated with each of the groups to which the specified network is 124 connected. 126 127 129 130 131 132 133 134 135 136 138 The XML document above esblishes a connection between two 139 connectivity groups and would result in the respective VRFs importing 140 both the route-target associated with "SimpleVPN" and "Storage 141 frontend". 143 In order to associate a given customer attachment-circuit to a 144 virtual network a PE device may either consult the MAP server or rely 145 on a information that is provided by the customer device via a PE-CE 146 communication protocol. In the second case it is important for the 147 PE to be able to publish that mapping to the MAP server in order to 148 provide the operational state of the network. 150 Regardless of whether the association is centrally determined by a 151 provisioning system or by the PE it can be added to the MAP server 152 via the following message: 154 155 157 158 159 160 161 162 163 164 166 Additionally the information regarding the specific PE attachment 167 circuit that the interface is bound to as well as its operational 168 state can be published via an XML document such as: 170 171 173 174 175 176 177 178 179 up 180 181 182 183 185 By storing this information on a MAP server the provisioning and 186 operational state of all IP VPNs in a domain can be known. Note that 187 the routing information corresponding to which IP prefixes are 188 currently reachable and the selection of the preferred path for a 189 given IP packet are still done using BGP IP VPN. 191 Routing information is both very dynamic as well as potentially 192 different at each specific VRF table, since the network location 193 influences path selection. Information stored in the MAP server is, 194 typically, more global in nature. 196 2. Data Model 198 The figure bellow contains the data-model used to represent the 199 provisioning information necessary to attach a given customer circuit 200 to an IP VPN. In it identifiers are represented by boxes while 201 metadata is represented by elements in square brackets. 203 +-------------+ +---------------+ 204 | customer | | connectivity | 205 | attachment |-- [ binding ] -- | group | == [ connection ] 206 +-------------+ +---------------+ 207 | | 208 [attachment-info] [ group-target ] 209 | | 210 +-------------+ +--------------+ 211 | provider | | route-target | 212 | attachment | +--------------+ 213 +-------------+ 215 2.1. Identifiers 217 The following Identifiers are defined for this schema: 219 2.1.1. customer-attachment 221 The "customer attachment" identifier represents a circuit connecting 222 to a customer edge device in the standard BGP IP VPN application. 223 The "customer attachment" identifies the Customer Edge (CE) circuit. 225 For instance, when the network in question is using an end-system 226 [I-D.marques-l3vpn-end-system] based implementation, the "customer 227 attachment" represents the virtual interface associated with a 228 virtual machine. 230 2.1.2. connectivity-group 232 The "connectivity-group" element represents a configuration template 233 used to provision a VRF table on a PE (or a routing table on a BGP/ 234 XMPP Signaling Gateway). 236 2.1.3. route-target 238 In BGP IP VPNs, route targets are associated with VPN routing 239 information and used to express routing table import and export 240 policies. 242 2.1.4. provider-attachment 244 A "provider-attachment" element identifies an interface in a PE 245 device. 247 2.2. Metadata 249 In the IF-MAP specification [if-map] metadata determines the state of 250 the MAP database. Identifiers are immutable constants. Metadata 251 update and delete requests represent state and lead to updates being 252 sent to subscribers. 254 2.2.1. attachment-info 255 The attachment-state metadata element is used to associate a 256 "customer-attachment" with a PE interface. 258 2.2.2. attachment-state 260 The attachment-state metadata element conveys operational state for 261 the interface between the customer and provider end-points. 263 2.2.3. binding 265 The binding metadata element associates a customer attachment with a 266 connectivity-group. It contains no operational state and maybe 267 inserted by either a PE device or a provisioning system. 269 2.2.4. group-target 271 The group-target metadata associates a connectivity-group with its 272 route-target. 274 3. Security Considerations 276 When using this approach, the MAP database, rather than the 277 individual configurations on PE devices, becomes the "source of 278 truth" about the VPN membership. It is important to restrict the 279 write access to the MAP database to systems that should be allowed to 280 modified it. 282 A MAP server implementation SHOULD support access controls on a per 283 metadata element basis such that it is possible to restrict write 284 access to a set of metadata elements to a specific list of 285 certificates. 287 4. References 289 [I-D.marques-l3vpn-end-system] 290 Marques, P., Fang, L., Pan, P., Shukla, A., Napierala, M. 291 and N. Bitar, "BGP-signaled end-system IP/VPNs.", 292 Internet-Draft draft-marques-l3vpn-end-system-05, March 293 2012. 295 [I-D.arkko-core-dev-urn] 296 Arkko, J., Jennings, C. and Z. Shelby, "Uniform Resource 297 Names for Device Identifiers", Internet-Draft draft-arkko- 298 core-dev-urn-01, October 2011. 300 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 301 Networks (VPNs)", RFC 4364, February 2006. 303 [RFC5935] Ellison, M. and B. Natale, "Expressing SNMP SMI Datatypes 304 in XML Schema Definition Language", RFC 5935, August 2010. 306 [if-map] "IF-MAP Binding for SOAP Specification Version 2.0", July 307 2010. 309 Appendix A. Schema 310 311 315 317 318 319 320 322 323 324 325 327 328 329 330 331 333 334 335 336 337 339 340 341 342 343 344 346 347 348 349 350 352 353 354 355 356 358 359 360 361 362 364 365 367 368 369 370 371 372 374 375 376 377 378 379 380 381 382 383 385 388 389 390 391 392 394 395 396 397 398 399 401 404 405 406 407 408 409 410 411 412 413 414 415 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 436 Author's Address 438 Pedro Marques 439 Contrail Systems 440 440 N. Wolfe Rd. 441 Sunnyvale, CA 94085 443 Email: roque@contrailsystems.com