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