idnits 2.17.00 (12 Aug 2021)
/tmp/idnits42455/draft-ietf-l3sm-l3vpn-service-model-19.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 contain references ([RFC4364], [RFC4026],
[RFC4110]), which it shouldn't. Please replace those with straight
textual mentions of the documents in question.
== There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 409 has weird spacing: '...ntifier str...'
== Line 419 has weird spacing: '...site-id leafr...'
== Line 422 has weird spacing: '...site-id leafr...'
== Line 465 has weird spacing: '...tion-id svc-...'
== Line 473 has weird spacing: '...vice-id svc-...'
== (16 more instances...)
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
The management system SHOULD honor the customer constraints, if the
constraint is too strict and can not be filled, the management system
MUST not provision the site and SHOULD provide an information to the
user. How the information is provided is out of scope of the document.
It would then be up to the user to relax the constraint or not.
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
pe-diverse: the current site-network-access MUST not be connected
to the same PE as the targeted site-network-accesses.
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
pop-diverse: the current site-network-access MUST not be connected
to the same PoP as the targeted site-network-accesses.
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
linecard-diverse: the current site-network-access MUST not be
connected to the same linecard as the targeted site-network-accesses.
-- The document date (November 04, 2016) is 2017 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: 'VPN2' is mentioned on line 1600, but not defined
== Missing Reference: 'VPN3' is mentioned on line 1609, but not defined
== Outdated reference: draft-ietf-netconf-restconf has been published as
RFC 8040
** Downref: Normative reference to an Informational RFC: RFC 4026
** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341)
Summary: 3 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 L3SM Working Group S. Litkowski
3 Internet-Draft Orange Business Services
4 Intended status: Standards Track L. Tomotaki
5 Expires: May 8, 2017 Verizon
6 K. Ogaki
7 KDDI
8 November 04, 2016
10 YANG Data Model for L3VPN service delivery
11 draft-ietf-l3sm-l3vpn-service-model-19
13 Abstract
15 This document defines a YANG data model that can be used for
16 communication between customers and network operators and to deliver
17 a Layer 3 Provider Provisioned VPN service. The document is limited
18 to the BGP PE-based VPNs as described in [RFC4026], [RFC4110] and
19 [RFC4364]. This model is intended to be instantiated at management
20 system to deliver the overall service. This model is not a
21 configuration model to be used directly on network elements. This
22 model provides an abstracted view of the Layer 3 IPVPN service
23 configuration components. It will be up to a management system to
24 take this as an input and use specific configurations models to
25 configure the different network elements to deliver the service. How
26 configuration of network elements is done is out of scope of the
27 document.
29 Requirements Language
31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
33 document are to be interpreted as described in [RFC2119].
35 Status of This Memo
37 This Internet-Draft is submitted in full conformance with the
38 provisions of BCP 78 and BCP 79.
40 Internet-Drafts are working documents of the Internet Engineering
41 Task Force (IETF). Note that other groups may also distribute
42 working documents as Internet-Drafts. The list of current Internet-
43 Drafts is at http://datatracker.ietf.org/drafts/current/.
45 Internet-Drafts are draft documents valid for a maximum of six months
46 and may be updated, replaced, or obsoleted by other documents at any
47 time. It is inappropriate to use Internet-Drafts as reference
48 material or to cite them other than as "work in progress."
49 This Internet-Draft will expire on May 8, 2017.
51 Copyright Notice
53 Copyright (c) 2016 IETF Trust and the persons identified as the
54 document authors. All rights reserved.
56 This document is subject to BCP 78 and the IETF Trust's Legal
57 Provisions Relating to IETF Documents
58 (http://trustee.ietf.org/license-info) in effect on the date of
59 publication of this document. Please review these documents
60 carefully, as they describe your rights and restrictions with respect
61 to this document. Code Components extracted from this document must
62 include Simplified BSD License text as described in Section 4.e of
63 the Trust Legal Provisions and are provided without warranty as
64 described in the Simplified BSD License.
66 Table of Contents
68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
69 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
70 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 5
71 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
72 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
73 4. Layer 3 IP VPN service model . . . . . . . . . . . . . . . . 7
74 5. Service data model usage . . . . . . . . . . . . . . . . . . 8
75 6. Design of the Data Model . . . . . . . . . . . . . . . . . . 9
76 6.1. Features and augmentation . . . . . . . . . . . . . . . . 16
77 6.2. VPN service overview . . . . . . . . . . . . . . . . . . 17
78 6.2.1. VPN service topology . . . . . . . . . . . . . . . . 17
79 6.2.1.1. Route Target allocation . . . . . . . . . . . . . 17
80 6.2.1.2. Any to any . . . . . . . . . . . . . . . . . . . 18
81 6.2.1.3. Hub and Spoke . . . . . . . . . . . . . . . . . . 18
82 6.2.1.4. Hub and Spoke disjoint . . . . . . . . . . . . . 19
83 6.2.2. Cloud access . . . . . . . . . . . . . . . . . . . . 20
84 6.2.3. Multicast service . . . . . . . . . . . . . . . . . . 22
85 6.2.4. Extranet VPNs . . . . . . . . . . . . . . . . . . . . 24
86 6.3. Site overview . . . . . . . . . . . . . . . . . . . . . . 25
87 6.3.1. Devices and locations . . . . . . . . . . . . . . . . 26
88 6.3.2. Site network accesses . . . . . . . . . . . . . . . . 27
89 6.3.2.1. Bearer . . . . . . . . . . . . . . . . . . . . . 28
90 6.3.2.2. Connection . . . . . . . . . . . . . . . . . . . 28
91 6.3.2.3. Inheritance of parameters between site and site-
92 network-access . . . . . . . . . . . . . . . . . 29
93 6.4. Site role . . . . . . . . . . . . . . . . . . . . . . . . 30
94 6.5. Site belonging to multiple VPNs . . . . . . . . . . . . . 30
95 6.5.1. Site vpn flavor . . . . . . . . . . . . . . . . . . . 30
96 6.5.1.1. Single VPN attachment : site-vpn-flavor-single . 30
97 6.5.1.2. Multi VPN attachment : site-vpn-flavor-multi . . 31
98 6.5.1.3. Sub VPN attachment : site-vpn-flavor-sub . . . . 31
99 6.5.1.4. NNI : site-vpn-flavor-nni . . . . . . . . . . . . 33
100 6.5.2. Attaching a site to a VPN . . . . . . . . . . . . . . 34
101 6.5.2.1. Reference a VPN . . . . . . . . . . . . . . . . . 35
102 6.5.2.2. VPN policy . . . . . . . . . . . . . . . . . . . 35
103 6.6. Deciding where to connect the site . . . . . . . . . . . 38
104 6.6.1. Constraint: Device . . . . . . . . . . . . . . . . . 39
105 6.6.2. Constraint/parameter: Site location . . . . . . . . . 39
106 6.6.3. Constraint/parameter: access type . . . . . . . . . . 41
107 6.6.4. Constraint: access diversity . . . . . . . . . . . . 41
108 6.6.5. Impossible access placement . . . . . . . . . . . . . 47
109 6.6.6. Examples of access placement . . . . . . . . . . . . 48
110 6.6.6.1. Multihoming . . . . . . . . . . . . . . . . . . . 48
111 6.6.6.2. Site offload . . . . . . . . . . . . . . . . . . 50
112 6.6.6.3. Parallel links . . . . . . . . . . . . . . . . . 56
113 6.6.6.4. SubVPN with multihoming . . . . . . . . . . . . . 57
114 6.6.7. Route Distinguisher and VRF allocation . . . . . . . 61
115 6.7. Site network access availability . . . . . . . . . . . . 62
116 6.8. Traffic protection . . . . . . . . . . . . . . . . . . . 63
117 6.9. Security . . . . . . . . . . . . . . . . . . . . . . . . 64
118 6.9.1. Authentication . . . . . . . . . . . . . . . . . . . 64
119 6.9.2. Encryption . . . . . . . . . . . . . . . . . . . . . 64
120 6.10. Management . . . . . . . . . . . . . . . . . . . . . . . 65
121 6.11. Routing protocols . . . . . . . . . . . . . . . . . . . . 66
122 6.11.1. Dual stack handling . . . . . . . . . . . . . . . . 66
123 6.11.2. Direct LAN connection onto SP network . . . . . . . 67
124 6.11.3. Direct LAN connection onto SP network with
125 redundancy . . . . . . . . . . . . . . . . . . . . . 67
126 6.11.4. Static routing . . . . . . . . . . . . . . . . . . . 68
127 6.11.5. RIP routing . . . . . . . . . . . . . . . . . . . . 68
128 6.11.6. OSPF routing . . . . . . . . . . . . . . . . . . . . 68
129 6.11.7. BGP routing . . . . . . . . . . . . . . . . . . . . 70
130 6.12. Service . . . . . . . . . . . . . . . . . . . . . . . . . 71
131 6.12.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . 71
132 6.12.2. QoS . . . . . . . . . . . . . . . . . . . . . . . . 72
133 6.12.2.1. QoS classification . . . . . . . . . . . . . . . 72
134 6.12.2.2. QoS profile . . . . . . . . . . . . . . . . . . 75
135 6.12.3. Multicast . . . . . . . . . . . . . . . . . . . . . 79
136 6.13. Enhanced VPN features . . . . . . . . . . . . . . . . . . 79
137 6.13.1. Carrier's Carrier . . . . . . . . . . . . . . . . . 79
138 6.14. External ID references . . . . . . . . . . . . . . . . . 81
139 6.15. Defining NNIs . . . . . . . . . . . . . . . . . . . . . . 81
140 6.15.1. Defining NNI with option A flavor . . . . . . . . . 83
141 6.15.2. Defining NNI with option B flavor . . . . . . . . . 86
142 6.15.3. Defining NNI with option C flavor . . . . . . . . . 88
143 7. Service model usage example . . . . . . . . . . . . . . . . . 90
144 8. Interaction with Other YANG Modules . . . . . . . . . . . . . 95
145 9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 99
146 10. Security Considerations . . . . . . . . . . . . . . . . . . . 153
147 11. Contribution . . . . . . . . . . . . . . . . . . . . . . . . 154
148 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 154
149 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 154
150 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 154
151 14.1. Changes between versions -18 and-19 . . . . . . . . . . 154
152 14.2. Changes between versions -17 and-18 . . . . . . . . . . 155
153 14.3. Changes between versions -16 and-17 . . . . . . . . . . 155
154 14.4. Changes between versions -15 and-16 . . . . . . . . . . 156
155 14.5. Changes between versions -13 and-14 . . . . . . . . . . 156
156 14.6. Changes between versions -12 and-13 . . . . . . . . . . 156
157 14.7. Changes between versions -11 and-12 . . . . . . . . . . 156
158 14.8. Changes between versions -09 and-10 . . . . . . . . . . 156
159 14.9. Changes between versions -08 and-09 . . . . . . . . . . 157
160 14.10. Changes between versions -07 and-08 . . . . . . . . . . 157
161 14.11. Changes between versions -06 and-07 . . . . . . . . . . 157
162 14.12. Changes between versions -05 and-06 . . . . . . . . . . 157
163 14.13. Changes between versions -04 and-05 . . . . . . . . . . 158
164 14.14. Changes between versions -02 and-03 . . . . . . . . . . 158
165 14.15. Changes between versions -01 and-02 . . . . . . . . . . 158
166 14.16. Changes between versions -00 and-01 . . . . . . . . . . 159
167 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 159
168 15.1. Normative References . . . . . . . . . . . . . . . . . . 159
169 15.2. Informative References . . . . . . . . . . . . . . . . . 161
170 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 161
172 1. Introduction
174 This document defines a Layer 3 VPN service data model written in
175 YANG. The model defines service configuration elements that can be
176 used in communication protocols between customers and network
177 operators. Those elements can be used also as input to automated
178 control and configuration applications.
180 1.1. Terminology
182 The following terms are defined in [RFC6241] and are not redefined
183 here:
185 o client
187 o configuration data
189 o server
191 o state data
192 The following terms are defined in [RFC7950] and are not redefined
193 here:
195 o augment
197 o data model
199 o data node
201 The terminology for describing YANG data models is found in
202 [RFC7950].
204 This document presents some configuration examples using XML
205 representation.
207 1.2. Tree diagram
209 A simplified graphical representation of the data model is presented
210 in Section 6.
212 The meaning of the symbols in these diagrams is as follows:
214 o Brackets "[" and "]" enclose list keys.
216 o Curly braces "{" and "}" contain names of optional features that
217 make the corresponding node conditional.
219 o Abbreviations before data node names: "rw" means configuration
220 (read-write), and "ro" state data (read-only).
222 o Symbols after data node names: "?" means an optional node and "*"
223 denotes a "list" or "leaf-list".
225 o Parentheses enclose choice and case nodes, and case nodes are also
226 marked with a colon (":").
228 o Ellipsis ("...") stands for contents of subtrees that are not
229 shown.
231 2. Acronyms
233 AAA: Authentication, Authorization, Accounting.
235 ACL: Access Control List.
237 ASM: Any-Source Multicast.
239 BFD: Bidirectional Forwarding Detection.
241 BGP: Border Gateway Protocol.
243 CE: Customer Edge.
245 CLI: Command Line Interface.
247 CsC: Carrier's Carrier.
249 CSP: Cloud Service Provider.
251 DHCP: Dynamic Host Configuration Protocol.
253 IGMP: Internet Group Management Protocol.
255 LAN: Local Area Network.
257 MLD: Multicast Listener Discovery.
259 MTU: Maximum Transmission Unit.
261 NAT: Network Address Translation.
263 NNI: Network to Network Interface.
265 OAM: Operation Administration and Management.
267 OSPF: Open Shortest Path First.
269 OSS: Operations Support System.
271 PE: Provider Edge.
273 POP: Point Of Presence.
275 PIM: Protocol Independent Multicast.
277 QoS: Quality Of Service.
279 RIP: Routing Information Protocol.
281 RD: Route Distinguisher.
283 RP: Rendez-vous Point.
285 RT: Route Target.
287 SLA: Service Level Agreement.
289 SLAAC: Stateless Address AutoConfiguration.
291 SP: Service Provider.
293 SSM: Source-Specific Multicast.
295 VPN: Virtual Private Network.
297 VRF: VPN Routing and Forwarding.
299 VRRP: Virtual Router Redundancy Protocol.
301 3. Definitions
303 Customer Edge (CE) Device: Equipment that is dedicated to a
304 particular customer and is directly connected (at layer 3) to one or
305 more PE devices via attachment circuits. A CE is usually located at
306 the customer premises, and is usually dedicated to a single VPN,
307 although it may support multiple VPNs if each one has separate
308 attachment circuits.
310 Provider Edge (PE) Device: Equipment managed by the Service Provider
311 (SP) that can support multiple VPNs for different customers, and is
312 directly connected (at layer 3) to one or more CE devices via
313 attachment circuits. A PE is usually located at an SP point of
314 presence (PoP) and is managed by the SP.
316 PE-Based VPNs: The PE devices know that certain traffic is VPN
317 traffic. They forward the traffic (through tunnels) based on the
318 destination IP address of the packet, and optionally on based on
319 other information in the IP header of the packet. The PE devices are
320 themselves the tunnel endpoints. The tunnels may make use of various
321 encapsulations to send traffic over the SP network (such as, but not
322 restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels).
324 4. Layer 3 IP VPN service model
326 A layer 3 IPVPN service is a collection of sites that are authorized
327 to exchange traffic between each other over a shared IP
328 infrastructure. This layer 3 VPN service model aims at providing a
329 common understanding on how the corresponding IP VPN service is to be
330 deployed over the shared infrastructure. This service model is
331 limited to BGP PE-Based VPNs as described in [RFC4110] and [RFC4364].
333 5. Service data model usage
335 L3VPN-SVC |
336 MODEL |
337 |
338 +------------------+ +-----+
339 | Orchestration | < --- > | OSS |
340 +------------------+ +-----+
341 | |
342 +----------------+ |
343 | Config manager | |
344 +----------------+ |
345 | |
346 | Netconf/CLI ...
347 | |
348 +------------------------------------------------+
349 Network
351 +++++++
352 + AAA +
353 +++++++
355 ++++++++ Bearer ++++++++ ++++++++ ++++++++
356 + CE A + ------- + PE A + + PE B + ---- + CE B +
357 ++++++++ Cnct ++++++++ ++++++++ ++++++++
359 Site A Site B
361 The idea of the L3 IPVPN service model is to propose an abstracted
362 interface between customers and network operators to manage
363 configuration of components of a L3VPN service. A typical usage is
364 to use this model as an input for an orchestration layer who will be
365 responsible to translate it to orchestrated configuration of network
366 elements who will be part of the service. The network elements can
367 be routers, but also servers (like AAA), and not limited to these
368 examples. The configuration of network elements can be done by the
369 CLI, or by NETCONF ([RFC6241])/RESTCONF ([I-D.ietf-netconf-restconf])
370 coupled with specific configuration YANG data models (BGP, VRF, BFD
371 ...) or any other way.
373 The usage of this service model is not limited to this example, it
374 can be used by any component of the management system but not
375 directly by network elements.
377 6. Design of the Data Model
379 The YANG module is divided in two main containers : vpn-services,
380 sites.
382 The vpn-service under vpn-services defines global parameters for the
383 VPN service for a specific customer.
385 A site is composed of at least one site-network-access and may have
386 multiple site-network-access in case of multihoming. The site-
387 network-access attachment is done through a bearer with an IP
388 connection on top. The bearer refers to properties of the attachment
389 that are below layer 3 while the connection refers to layer 3
390 protocol oriented properties. The bearer may be allocated
391 dynamically by the service provider and the customer may provide some
392 constraints or parameters to drive the placement.
394 Authorization of traffic exchange is done through what we call a VPN
395 policy or VPN service topology defining routing exchange rules
396 between sites.
398 The figure below describe the overall structure of the YANG module:
400 module: ietf-l3vpn-svc
401 +--rw l3vpn-svc
402 +--rw vpn-services
403 | +--rw vpn-service* [vpn-id]
404 | +--rw vpn-id svc-id
405 | +--rw customer-name? string
406 | +--rw vpn-service-topology? identityref
407 | +--rw cloud-accesses {cloud-access}?
408 | | +--rw cloud-access* [cloud-identifier]
409 | | +--rw cloud-identifier string
410 | | +--rw (list-flavor)?
411 | | | +--:(permit-any)
412 | | | | +--rw permit-any? empty
413 | | | +--:(deny-any-except)
414 | | | | +--rw permit-site* leafref
415 | | | +--:(permit-any-except)
416 | | | +--rw deny-site* leafref
417 | | +--rw authorized-sites
418 | | | +--rw authorized-site* [site-id]
419 | | | +--rw site-id leafref
420 | | +--rw denied-sites
421 | | | +--rw denied-site* [site-id]
422 | | | +--rw site-id leafref
423 | | +--rw address-translation
424 | | +--rw nat44
425 | | +--rw enabled? boolean
426 | | +--rw nat44-customer-address? inet:ipv4-address
427 | +--rw multicast {multicast}?
428 | | +--rw enabled? boolean
429 | | +--rw customer-tree-flavors
430 | | | +--rw tree-flavor* identityref
431 | | +--rw rp
432 | | +--rw rp-group-mappings
433 | | | +--rw rp-group-mapping* [id]
434 | | | +--rw id uint16
435 | | | +--rw provider-managed
436 | | | | +--rw enabled? boolean
437 | | | | +--rw rp-redundancy? boolean
438 | | | | +--rw optimal-traffic-delivery? boolean
439 | | | +--rw rp-address? inet:ip-address
440 | | | +--rw groups
441 | | | +--rw group* [id]
442 | | | +--rw id uint16
443 | | | +--rw (group-format)?
444 | | | +--:(startend)
445 | | | | +--rw group-start? inet:ip-address
446 | | | | +--rw group-end? inet:ip-address
447 | | | +--:(singleaddress)
448 | | | +--rw group-address? inet:ip-address
449 | | +--rw rp-discovery
450 | | +--rw rp-discovery-type? identityref
451 | | +--rw bsr-candidates
452 | | +--rw bsr-candidate-address* inet:ip-address
453 | +--rw carrierscarrier? boolean {carrierscarrier}?
454 | +--rw extranet-vpns {extranet-vpn}?
455 | +--rw extranet-vpn* [vpn-id]
456 | +--rw vpn-id svc-id
457 | +--rw local-sites-role? identityref
458 +--rw sites
459 +--rw site* [site-id]
460 +--rw site-id svc-id
461 +--rw requested-site-start? yang:date-and-time
462 +--rw requested-site-stop? yang:date-and-time
463 +--rw locations
464 | +--rw location* [location-id]
465 | +--rw location-id svc-id
466 | +--rw address? string
467 | +--rw postal-code? string
468 | +--rw state? string
469 | +--rw city? string
470 | +--rw country-code? string
471 +--rw devices
472 | +--rw device* [device-id]
473 | +--rw device-id svc-id
474 | +--rw location? leafref
475 | +--rw management
476 | +--rw address-family? address-family
477 | +--rw address? inet:ip-address
478 +--rw site-diversity {site-diversity}?
479 | +--rw groups
480 | +--rw group* [group-id]
481 | +--rw group-id string
482 +--rw management
483 | +--rw type? identityref
484 +--rw vpn-policies
485 | +--rw vpn-policy* [vpn-policy-id]
486 | +--rw vpn-policy-id svc-id
487 | +--rw entries* [id]
488 | +--rw id svc-id
489 | +--rw filter
490 | | +--rw (lan)?
491 | | +--:(prefixes)
492 | | | +--rw ipv4-lan-prefix* inet:ipv4-prefix {ipv4}?
493 | | | +--rw ipv6-lan-prefix* inet:ipv6-prefix {ipv6}?
494 | | +--:(lan-tag)
495 | | +--rw lan-tag* string
496 | +--rw vpn
497 | +--rw vpn-id leafref
498 | +--rw site-role? identityref
499 +--rw site-vpn-flavor? identityref
500 +--rw maximum-routes
501 | +--rw address-family* [af]
502 | +--rw af address-family
503 | +--rw maximum-routes? uint32
504 +--rw security
505 | +--rw authentication
506 | +--rw encryption {encryption}?
507 | +--rw enabled? boolean
508 | +--rw layer enumeration
509 | +--rw encryption-profile
510 | +--rw (profile)?
511 | +--:(provider-profile)
512 | | +--rw profile-name? string
513 | +--:(customer-profile)
514 | +--rw algorithm? string
515 | +--rw (key-type)?
516 | +--:(psk)
517 | | +--rw preshared-key? string
518 | +--:(pki)
519 +--rw service
520 | +--rw qos {qos}?
521 | | +--rw qos-classification-policy
522 | | | +--rw rule* [id]
523 | | | +--rw id uint16
524 | | | +--rw (match-type)?
525 | | | | +--:(match-flow)
526 | | | | | +--rw match-flow
527 | | | | | +--rw dscp? inet:dscp
528 | | | | | +--rw dot1p? uint8
529 | | | | | +--rw ipv4-src-prefix? inet:ipv4-prefix
530 | | | | | +--rw ipv6-src-prefix? inet:ipv6-prefix
531 | | | | | +--rw ipv4-dst-prefix? inet:ipv4-prefix
532 | | | | | +--rw ipv6-dst-prefix? inet:ipv6-prefix
533 | | | | | +--rw l4-src-port? inet:port-number
534 | | | | | +--rw target-sites* svc-id
535 | | | | | +--rw l4-src-port-range
536 | | | | | | +--rw lower-port? inet:port-number
537 | | | | | | +--rw upper-port? inet:port-number
538 | | | | | +--rw l4-dst-port? inet:port-number
539 | | | | | +--rw l4-dst-port-range
540 | | | | | | +--rw lower-port? inet:port-number
541 | | | | | | +--rw upper-port? inet:port-number
542 | | | | | +--rw protocol-field? union
543 | | | | +--:(match-application)
544 | | | | +--rw match-application? identityref
545 | | | +--rw target-class-id? string
546 | | +--rw qos-profile
547 | | +--rw (qos-profile)?
548 | | +--:(standard)
549 | | | +--rw profile? string
550 | | +--:(custom)
551 | | +--rw classes {qos-custom}?
552 | | +--rw class* [class-id]
553 | | +--rw class-id string
554 | | +--rw rate-limit? uint8
555 | | +--rw latency
556 | | | +--rw (flavor)?
557 | | | ...
558 | | +--rw jitter
559 | | | +--rw (flavor)?
560 | | | ...
561 | | +--rw bandwidth
562 | | +--rw guaranteed-bw-percent? uint8
563 | | +--rw end-to-end? empty
564 | +--rw carrierscarrier {carrierscarrier}?
565 | | +--rw signalling-type? enumeration
566 | +--rw multicast {multicast}?
567 | +--rw multicast-site-type? enumeration
568 | +--rw multicast-address-family
569 | | +--rw ipv4? boolean {ipv4}?
570 | | +--rw ipv6? boolean {ipv6}?
571 | +--rw protocol-type? enumeration
572 +--rw traffic-protection {fast-reroute}?
573 | +--rw enabled? boolean
574 +--rw routing-protocols
575 | +--rw routing-protocol* [type]
576 | +--rw type identityref
577 | +--rw ospf {rtg-ospf}?
578 | | +--rw address-family* address-family
579 | | +--rw area-address? yang:dotted-quad
580 | | +--rw metric? uint16
581 | | +--rw sham-links {rtg-ospf-sham-link}?
582 | | +--rw sham-link* [target-site]
583 | | +--rw target-site svc-id
584 | | +--rw metric? uint16
585 | +--rw bgp {rtg-bgp}?
586 | | +--rw autonomous-system? uint32
587 | | +--rw address-family* address-family
588 | +--rw static
589 | | +--rw cascaded-lan-prefixes
590 | | +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}?
591 | | | +--rw lan inet:ipv4-prefix
592 | | | +--rw lan-tag? string
593 | | | +--rw next-hop inet:ipv4-address
594 | | +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}?
595 | | +--rw lan inet:ipv6-prefix
596 | | +--rw lan-tag? string
597 | | +--rw next-hop inet:ipv6-address
598 | +--rw rip {rtg-rip}?
599 | | +--rw address-family* address-family
600 | +--rw vrrp {rtg-vrrp}?
601 | +--rw address-family* address-family
602 +--ro actual-site-start? yang:date-and-time
603 +--ro actual-site-stop? yang:date-and-time
604 +--rw site-network-accesses
605 +--rw site-network-access* [site-network-access-id]
606 +--rw site-network-access-id svc-id
607 +--rw site-network-access-type? identityref
608 +--rw (location-flavor)
609 | +--:(location)
610 | | +--rw location-reference? leafref
611 | +--:(device)
612 | +--rw device-reference? leafref
613 +--rw access-diversity {site-diversity}?
614 | +--rw groups
615 | | +--rw group* [group-id]
616 | | +--rw group-id string
617 | +--rw constraints
618 | +--rw constraint* [constraint-type]
619 | +--rw constraint-type identityref
620 | +--rw target
621 | +--rw (target-flavor)?
622 | +--:(id)
623 | | +--rw group* [group-id]
624 | | ...
625 | +--:(all-accesses)
626 | | +--rw all-other-accesses? empty
627 | +--:(all-groups)
628 | +--rw all-other-groups? empty
629 +--rw bearer
630 | +--rw requested-type {requested-type}?
631 | | +--rw requested-type? string
632 | | +--rw strict? boolean
633 | +--rw always-on? boolean {always-on}?
634 | +--rw bearer-reference? string {bearer-reference}?
635 +--rw ip-connection
636 | +--rw ipv4 {ipv4}?
637 | | +--rw address-allocation-type? identityref
638 | | +--rw number-of-dynamic-address? uint8
639 | | +--rw dhcp-relay
640 | | | +--rw customer-dhcp-servers
641 | | | +--rw server-ip-address* inet:ipv4-address
642 | | +--rw addresses
643 | | +--rw provider-address? inet:ipv4-address
644 | | +--rw customer-address? inet:ipv4-address
645 | | +--rw mask? uint8
646 | +--rw ipv6 {ipv6}?
647 | | +--rw address-allocation-type? identityref
648 | | +--rw number-of-dynamic-address? uint8
649 | | +--rw dhcp-relay
650 | | | +--rw customer-dhcp-servers
651 | | | +--rw server-ip-address* inet:ipv6-address
652 | | +--rw addresses
653 | | +--rw provider-address? inet:ipv6-address
654 | | +--rw customer-address? inet:ipv6-address
655 | | +--rw mask? uint8
656 | +--rw oam
657 | +--rw bfd {bfd}?
658 | +--rw enabled? boolean
659 | +--rw (holdtime)?
660 | +--:(profile)
661 | | +--rw profile-name? string
662 | +--:(fixed)
663 | +--rw fixed-value? uint32
664 +--rw security
665 | +--rw authentication
666 | +--rw encryption {encryption}?
667 | +--rw enabled? boolean
668 | +--rw layer enumeration
669 | +--rw encryption-profile
670 | +--rw (profile)?
671 | +--:(provider-profile)
672 | | +--rw profile-name? string
673 | +--:(customer-profile)
674 | +--rw algorithm? string
675 | +--rw (key-type)?
676 | +--:(psk)
677 | | ...
678 | +--:(pki)
679 +--rw service
680 | +--rw svc-input-bandwidth? uint32
681 | +--rw svc-output-bandwidth? uint32
682 | +--rw svc-mtu? uint16
683 | +--rw qos {qos}?
684 | | +--rw qos-classification-policy
685 | | | +--rw rule* [id]
686 | | | +--rw id uint16
687 | | | +--rw (match-type)?
688 | | | | +--:(match-flow)
689 | | | | | +--rw match-flow
690 | | | | | ...
691 | | | | +--:(match-application)
692 | | | | +--rw match-application? identityref
693 | | | +--rw target-class-id? string
694 | | +--rw qos-profile
695 | | +--rw (qos-profile)?
696 | | +--:(standard)
697 | | | +--rw profile? string
698 | | +--:(custom)
699 | | +--rw classes {qos-custom}?
700 | | +--rw class* [class-id]
701 | | ...
702 | +--rw carrierscarrier {carrierscarrier}?
703 | | +--rw signalling-type? enumeration
704 | +--rw multicast {multicast}?
705 | +--rw multicast-site-type? enumeration
706 | +--rw multicast-address-family
707 | | +--rw ipv4? boolean {ipv4}?
708 | | +--rw ipv6? boolean {ipv6}?
709 | +--rw protocol-type? enumeration
710 +--rw routing-protocols
711 | +--rw routing-protocol* [type]
712 | +--rw type identityref
713 | +--rw ospf {rtg-ospf}?
714 | | +--rw address-family* address-family
715 | | +--rw area-address? yang:dotted-quad
716 | | +--rw metric? uint16
717 | | +--rw sham-links {rtg-ospf-sham-link}?
718 | | +--rw sham-link* [target-site]
719 | | +--rw target-site svc-id
720 | | +--rw metric? uint16
721 | +--rw bgp {rtg-bgp}?
722 | | +--rw autonomous-system? uint32
723 | | +--rw address-family* address-family
724 | +--rw static
725 | | +--rw cascaded-lan-prefixes
726 | | +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}?
727 | | | +--rw lan inet:ipv4-prefix
728 | | | +--rw lan-tag? string
729 | | | +--rw next-hop inet:ipv4-address
730 | | +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}?
731 | | +--rw lan inet:ipv6-prefix
732 | | +--rw lan-tag? string
733 | | +--rw next-hop inet:ipv6-address
734 | +--rw rip {rtg-rip}?
735 | | +--rw address-family* address-family
736 | +--rw vrrp {rtg-vrrp}?
737 | +--rw address-family* address-family
738 +--rw availability
739 | +--rw access-priority? uint32
740 +--rw vpn-attachment
741 +--rw (attachment-flavor)
742 +--:(vpn-policy-id)
743 | +--rw vpn-policy-id? leafref
744 +--:(vpn-id)
745 +--rw vpn-id? leafref
746 +--rw site-role? identityref
748 6.1. Features and augmentation
750 The model implements a lot of features allowing implementations to be
751 modular. As example, an implementation may support only IPv4 VPNs
752 (ipv4 feature), IPv6 (ipv6 feature), or both (by advertising both
753 features). The routing protocols proposed to the customer may also
754 be enabled through features. This model proposes also some features
755 for more advanced options like : extranet-vpn support
756 (Section 6.2.4), site diversity (Section 6.6), qos (Section 6.12.2),
757 ...
759 In addition, as for any YANG model, this service model can be
760 augmented to implement new behaviors or specific features. For
761 example, this model proposes different options for the IP address
762 assignment, if those options are not filling all requirements, new
763 options can be added through augmentation.
765 6.2. VPN service overview
767 A vpn-service list item contains generic informations about the VPN
768 service. The vpn-id of the vpn-service refers to an internal
769 reference for this VPN service, while customer name refers to a more
770 explicit reference to the customer. This identifier is purely
771 internal to the organization responsible for the VPN service.
773 6.2.1. VPN service topology
775 The type of VPN service topology is required for configuration.
776 Current proposal supports: any-to-any, hub and spoke (where hubs can
777 exchange traffic), and hub and spoke disjoint (where hubs cannot
778 exchange traffic). New topologies could be added by augmentation.
779 By default, any-to-any VPN service topology is used.
781 6.2.1.1. Route Target allocation
783 Layer 3 PE-based VPN is built using route-targets as described in
784 [RFC4364]. It is expected the management system to allocate
785 automatically a set of route-targets upon a VPN service creation
786 request. How the management system allocates route-targets is out of
787 scope of the document but multiple ways could be envisaged as
788 described below.
790 Management system
791 <------------------------------------------------->
792 Request RT
793 +-----------------------+ Topo a2a +----------+
794 RESTCONF | | -----> | |
795 User ------------- | Service Orchestration | |NetworkOSS|
796 l3vpn-svc | | <----- | |
797 model +-----------------------+ Response +----------+
798 RT1,RT2
800 In the example above, a service orchestration, owning the
801 instantiation of this service model, request route-targets to the
802 network OSS. Based on the requested VPN service topology, the
803 network OSS replies with one or multiple route-targets. The
804 interface between this service orchestration and network OSS is out
805 of scope of this document.
807 +---------------------------+
808 RESTCONF | |
809 User ------------- | Service Orchestration |
810 l3vpn-svc | |
811 model | |
812 | RT pool : 10:1->10:10000 |
813 | RT pool : 20:50->20:5000 |
814 +---------------------------+
816 In the example above, a service orchestration, owning the
817 instantiation of this service model, owns one or more pools of route-
818 target (specified by service provider) that can be allocated. Based
819 on the requested VPN service topology, it will allocate one or
820 multiple route-targets from the pool.
822 The mechanism displayed above are just examples and should not be
823 considered as an exhaustive list of solutions.
825 6.2.1.2. Any to any
827 +------------------------------------------------------------+
828 | VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 |
829 | |
830 | VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 |
831 +------------------------------------------------------------+
833 Figure - Any-to-any VPN service topology
835 In the any-to-any VPN service topology, all VPN sites can communicate
836 between each other without any restriction. It is expected that the
837 management system that receives an any-to-any IPVPN service request
838 through this model needs to assign and then configure the VRF and
839 route-targets on the appropriate PEs. In the any-to-any case, in
840 general a single route-target is required and every VRF imports and
841 exports this route-target.
843 6.2.1.3. Hub and Spoke
845 +-------------------------------------------------------------+
846 | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
847 | +----------------------------------+
848 | |
849 | +----------------------------------+
850 | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
851 +-------------------------------------------------------------+
853 Figure - Hub and Spoke VPN service topology
855 In the hub and spoke VPN service topology, all spoke sites can
856 communicate only with Hub sites but not between each other, and hubs
857 can also communicate between each other. It is expected that the
858 management system that owns an any to any IPVPN service request
859 through this model, needs to assign and then configure the VRF and
860 route-targets on the appropriate PEs. In the hub and spoke case, in
861 general a two route-targets are required (one route-target for Hub
862 routes, one route-target for spoke routes). A Hub VRF, connecting
863 Hub sites, will export Hub routes with Hub route-target, and will
864 import Spoke routes through Spoke route-target. It will also import
865 the Hub route-target to allow Hub to Hub communication. A Spoke VRF,
866 connecting Spoke sites, will export Spoke routes with Spoke route-
867 target, and will import Hub routes through Hub route-target.
869 The management system MUST take into account Hub and Spoke
870 connections constraints. For example, if a management system decides
871 to mesh a spoke site and a hub site on the same PE, it needs to mesh
872 connections in different VRFs as displayed in the figure below.
874 Hub_Site ------- (VRF_Hub) PE1
875 (VRF_Spoke)
876 / |
877 Spoke_Site1 -------------------+ |
878 |
879 Spoke_Site2 -----------------------+
881 6.2.1.4. Hub and Spoke disjoint
883 +-------------------------------------------------------------+
884 | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
885 +--------------------------+ +-------------------------------+
886 | |
887 +--------------------------+ +-------------------------------+
888 | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
889 +-------------------------------------------------------------+
891 Figure - Hub and Spoke disjoint VPN service topology
893 In the Hub and Spoke disjoint VPN service topology, all Spoke sites
894 can communicate only with Hub sites but not between each other and
895 Hubs cannot communicate between each other. It is expected that the
896 management system that owns an any to any IPVPN service request
897 through this model, needs to assign and then configure the VRF and
898 route-targets on the appropriate PEs. In the Hub and Spoke case, two
899 route-targets are required (one route-target for Hub routes, one
900 route-target for Spoke routes). A Hub VRF, connecting Hub sites,
901 will export Hub routes with Hub route-target, and will import Spoke
902 routes through Spoke route-target. A Spoke VRF, connecting Spoke
903 sites, will export Spoke routes with Spoke route-target, and will
904 import Hub routes through Hub route-target.
906 The management system MUST take into account Hub and Spoke
907 connections constraints as in the previous case.
909 Hub and Spoke disjoint can also be seen as multiple Hub and Spoke
910 VPNs (one per Hub) sharing with a common set of Spoke sites.
912 6.2.2. Cloud access
914 The proposed model provides a cloud access configuration through the
915 cloud-access container. The usage of cloud-access is targeted for
916 public cloud. An Internet access can also be considered as a public
917 cloud access service. The cloud-access container provides parameters
918 for network address translations and authorization rules.
920 A private cloud access may be addressed through NNIs as described in
921 Section 6.15.
923 A cloud identifier is used to reference the target service. This
924 identifier is local to each administration.
926 The model allows for source address translation before accessing the
927 cloud. IPv4 to IPv4 address translation (nat44) is the only
928 supported option but other options can be added through augmentation.
929 If IP source address translation is required to access the cloud, the
930 enabled leaf MUST be set to true in the "nat44" container. An IP
931 address may be provided in the customer-address leaf, in case the
932 customer is providing the IP address to be used for the cloud access.
933 If the service provider is providing this address, the customer-
934 address is not necessary as it can be picked from a service provider
935 pool.
937 By default, all sites in the IPVPN MUST be authorized to access to
938 the cloud. In case restrictions are required, a user MAY configure
939 the permit-site or deny-site leaf-list. The "permit-site" defines
940 the list of sites authorized for cloud access. The "deny-site"
941 defines the list of sites denied for cloud access. The model
942 supports both "deny any except" and "permit any except"
943 authorization.
945 How the restrictions will be configured on network elements is out of
946 scope of this document.
948 IPVPN
949 ++++++++++++++++++++++++++++++++ +++++++++++
950 + Site 3 + --- + Cloud1 +
951 + Site 1 + +++++++++++
952 + +
953 + Site 2 + --- ++++++++++++
954 + + + Internet +
955 + Site 4 + ++++++++++++
956 ++++++++++++++++++++++++++++++++
957 |
958 ++++++++++
959 + Cloud2 +
960 ++++++++++
962 In the example above, we may configure the global VPN to access
963 Internet by creating a cloud-access pointing to the cloud identifier
964 for the Internet service. No authorized-sites will be configured as
965 all sites are required to access the Internet. The "address-
966 translation/nat44/enabled" leaf will be set to true.
968
969 123456487
970
971
972 INTERNET
973
974
975 true
976
977
978
979
980
982 If Site1 and Site2 requires access to Cloud1, a new cloud-access will
983 be created pointing to the cloud identifier of Cloud1. The "permit-
984 site" leaf-list will be filled with a reference to Site1 and Site2.
986
987 123456487
988
989
990 Cloud1
991 site1
992 site2
993
994
995
997 If all sites except Site1 requires access to Cloud2, a new cloud-
998 access will be created pointing to the cloud identifier of Cloud2.
999 The "deny-site" leaf-list will be filled with a reference to Site1.
1001
1002 123456487
1003
1004
1005 Cloud2
1006 site1
1007
1008
1009
1011 6.2.3. Multicast service
1013 Multicast in IP VPN is described in [RFC6513].
1015 If multicast support is required for an IPVPN, some global multicast
1016 parameters are required as input of the service request.
1018 The user of this model will need to fill the flavor of trees that
1019 will be used by customer within the IPVPN (Customer tree). The
1020 proposed model supports bidirectional, shared and source-based trees
1021 (and can be augmented). Multiple flavors of tree can be supported
1022 simultaneously.
1024 Operator network
1025 ______________
1026 / \
1027 | |
1028 (SSM tree) |
1029 Recv (IGMPv3) -- Site2 ------- PE2 |
1030 | PE1 --- Site1 --- Source1
1031 | | \
1032 | | -- Source2
1033 | |
1034 (ASM tree) |
1035 Recv (IGMPv2) -- Site3 ------- PE3 |
1036 | |
1037 (SSM tree) |
1038 Recv (IGMPv3) -- Site4 ------- PE4 |
1039 | / |
1040 Recv (IGMPv2) -- Site5 -------- |
1041 (ASM tree) |
1042 | |
1043 \_______________/
1045 In case of an ASM flavor requested, this model requires to fill the
1046 rp and rp-discovery parameters. Multiple RP to group mappings can be
1047 created using the rp-group-mappings container. For each mapping, the
1048 RP service can be managed by the service provider using the leaf
1049 "provider-managed/enabled" set to true. In case of provider managed
1050 RP, the user can request a rendez-vous point redundancy and/or an
1051 optimal traffic delivery. Those parameters will help the service
1052 provider to select the appropriate technology or architecture to
1053 fulfill the customer service requirement: for instance, in case of a
1054 request for an optimal traffic delivery, a service provider may use
1055 Anycast-RP or RP-tree to SPT switchover architectures.
1057 In case of a customer managed RP, the RP address must be filled in
1058 the RP to group mappings using the "rp-address" leaf. This leaf is
1059 not needed for a provider managed RP.
1061 User can define a specific rp-discovery mechanism like: auto-rp,
1062 static-rp, bsr-rp modes. By default, the model considers static-rp
1063 if ASM is requested. A single rp-discovery mechanism is allowed for
1064 the VPN. The "rp-discovery" container can be used for both provider
1065 and customer managed RPs. In case of a provider managed RP, if the
1066 user wants to use bsr-rp as a discovery protocol, a service provider
1067 should consider the provider managed rp-group-mappings for the bsr-rp
1068 configuration. The service provider will then configure its selected
1069 RPs to be bsr-rp-candidates. In case of a customer managed RP and a
1070 bsr-rp discovery mechanism, the rp-address provided will be
1071 considered as bsr-rp candidate.
1073 6.2.4. Extranet VPNs
1075 There are some cases where a particular VPN needs to access to
1076 resources (servers, hosts ...) that are external. These resources
1077 may be located in another VPN.
1079 +-----------+ +-----------+
1080 / \ / \
1081 SiteA -- | VPN A | --- | VPN B | --- SiteB
1082 \ / \ / (Shared
1083 +-----------+ +-----------+ resources)
1085 In the figure above, VPN B has some resources on Site B that need to
1086 be available to some customers/partners. VPN A must be able to
1087 access those VPN B resources.
1089 Such VPN connection scenario can be achieved by the VPN policy
1090 defined in Section 6.5.2.2. But there are some simple cases where a
1091 particular VPN (VPN A) needs to access to all resources in a VPN B.
1092 The model provides an easy way to setup this connection using the
1093 "extranet-vpns" container.
1095 The "extranet-vpns" container defines a list of VPNs a particular VPN
1096 wants to access. The "extranet-vpns" must be used on customer VPNs
1097 accessing extranet resources in another VPN. In the figure above, in
1098 order to give access for VPN A to VPN B, extranet-vpns container
1099 needs to be configured under VPN A with an entry corresponding to VPN
1100 B and there is no service configuration requirement on VPN B.
1102 Readers should note that even if there is no configuration
1103 requirement on VPN B, if VPN A lists VPN B as extranet, all sites in
1104 VPN B will gain access to all sites in VPN A.
1106 The "site-role" leaf defines the role of the local VPN sites in the
1107 target extranet VPN service topology. Site roles are defined in
1108 Section 6.4. Based on this, the requirements described in
1109 Section 6.4 regarding the site-role leaf are also applicable here.
1111 In the example below, VPN A accesses to VPN B resources through an
1112 extranet connection, a Spoke role is required for VPN A sites as
1113 sites from VPN A must not be able to communicate between each other
1114 through the extranet VPN connection.
1116
1117 VPNB
1118 hub-Spoke
1119
1120
1121 VPNA
1122 any-to-any
1123
1124
1125 VPNB
1126 spoke-role
1127
1128
1129
1131 This model does not define how the extranet configuration will be
1132 achieved.
1134 Any more complex VPN interconnection scenario (e.g. only part of
1135 sites of VPN A accessing only part of sites of VPN B) needs to be
1136 achieved using the vpn attachment defined in Section 6.5.2 and
1137 especially the VPN policy defined in Section 6.5.2.2.
1139 6.3. Site overview
1141 A site represents a connection of a customer office to one or more
1142 VPN services.
1144 +-------------+
1145 / \
1146 +------------------+ +-----| VPN1 |
1147 | | | \ /
1148 | New York Office | ----- (site) -----+ +-------------+
1149 | | | +-------------+
1150 +------------------+ | / \
1151 +-----| VPN2 |
1152 \ /
1153 +-------------+
1155 A site is composed of some characteristics :
1157 o Unique identifier (site-id): to uniquely identify the site within
1158 the overall network infrastructure. The identifier is a string
1159 allowing to any encoding for the local administration of the VPN
1160 service.
1162 o Locations (locations): site location information to allow easy
1163 retrieval on nearest available resources. A site may be composed
1164 of multiple locations.
1166 o Devices: the customer can request one or more customer premise
1167 equipments from the service provider for a particular site.
1169 o Management (management): defines the model of management of the
1170 site, for example : co-managed, customer managed or provider
1171 managed.
1173 o Site network accesses (site-network-accesses): defines the list of
1174 network accesses associated to the sites and their properties :
1175 especially bearer, connection and service parameters.
1177 A site-network-access represents an IP logical connection of a site.
1178 A site may have multiple site-network-accesses.
1180 +------------------+ Site
1181 | |-----------------------------------
1182 | |****** (site-network-access#1) ******
1183 | New York Office |
1184 | |****** (site-network-access#2) ******
1185 | |-----------------------------------
1186 +------------------+
1188 Multiple site-network-accesses are used for instance in case of
1189 multihoming. Some other meshing cases may also involve multiple
1190 site-network-accesses.
1192 The site configuration is viewed as a global entity, we assume that
1193 it is mostly the role of the management to split the parameters
1194 between the different elements within the network. For example, in
1195 the case of the site-network-access configuration, the management
1196 system needs to split the overall parameters between the PE
1197 configuration and the CE configuration.
1199 6.3.1. Devices and locations
1201 A site may be composed of multiple locations. All the locations will
1202 need to be configured as part of the "locations" container and list.
1203 A typical example of multilocation site is an headquarter in a city
1204 composed of multiple buildings. Those buildings may be located in
1205 different parts of the city and may be linked by intra-city fibers
1206 (customer metropolitan area network). In such a case, when
1207 connecting to a VPN service, the customer may ask for multihoming
1208 based on its distributed locations.
1210 New York Site
1212 +------------------+ Site
1213 | +--------------+ |-----------------------------------
1214 | | Manhattan | |****** (site-network-access#1) ******
1215 | +--------------+ |
1216 | +--------------+ |
1217 | | Brooklyn | |****** (site-network-access#2) ******
1218 | +--------------+ |
1219 | |-----------------------------------
1220 +------------------+
1222 A customer may also request some premise equipments (CEs) to the
1223 service provider through the "devices" container. Requesting a CE
1224 implies a provider-managed or co-managed model. A particular device
1225 must be ordered to a particular already configured location. This
1226 would help the service provider to send the device to the appropriate
1227 postal address. In a multilocation site, a customer may for example
1228 request a CE for each location on the site where multihoming must be
1229 implemented. In the figure above, one device may be requested for
1230 the Manhattan location and one other for the Brooklyn location.
1232 By using devices and locations, the user can influence the
1233 multihoming scenario he wants to implement: single CE, dual CE...
1235 6.3.2. Site network accesses
1237 As mentioned, a site may be multihomed. Each IP network access for a
1238 site is defined in the site-network-accesses list. The site-network-
1239 access defines how the site is connected on the network and is split
1240 into three main classes of parameters:
1242 o bearer: defines requirements of the attachment (below Layer 3).
1244 o connection: defines Layer 3 protocol parameters of the attachment.
1246 o availability: defines the site availability policy. The
1247 availability parameters are defined in Section 6.7
1249 The site-network-access has a specific type (site-network-access-
1250 type). This documents defines two types :
1252 o point-to-point: describes a point to point connection between the
1253 service provider and the customer.
1255 o multipoint: describes a multipoint connection between the service
1256 provider and the customer.
1258 The type of site-network-access may have an impact on the parameters
1259 offered to the customer, e.g., a service provider may not offer
1260 encryption for multipoint accesses. Deciding what parameter is
1261 supported for point-to-point and/or multipoint accesses is up to the
1262 provider and is out of scope of this document. Some containers
1263 proposed in the model may require extension in order to work properly
1264 for multipoint accesses.
1266 6.3.2.1. Bearer
1268 The "bearer" container defines the requirements for the site
1269 attachment to the provider network that are below Layer 3.
1271 The bearer parameters will help to determine the access media to be
1272 used. This is further described in Section 6.6.3.
1274 6.3.2.2. Connection
1276 The "ip-connection" container defines the protocol parameters of the
1277 attachment (IPv4 and IPv6). Depending on the management mode, it
1278 refers to the PE-CE addressing or CE to customer LAN addressing. In
1279 any case, it describes the provider to customer responsibility
1280 boundary. For a customer managed site, it refers to the PE-CE
1281 connection. For a provider managed site, it refers to the CE to LAN
1282 connection.
1284 6.3.2.2.1. IP addressing
1286 An IP subnet can be configured for either layer 3 protocols. For a
1287 dual stack connection, two subnets will be provided, one for each
1288 address family.
1290 The address-allocation-type determines how the address allocation
1291 needs to be done. The current model proposes five ways of IP address
1292 allocation:
1294 o provider-dhcp: the provider will provide DHCP service for customer
1295 equipments, this is can be applied to either IPv4 and IPv6
1296 containers.
1298 o provider-dhcp-relay: the provider will provide DHCP relay service
1299 for customer equipments, this is applicable to both IPv4 and IPv6
1300 addressing. The customer needs to fill DHCP server list to be
1301 used.
1303 o static-address: Addresses will be assigned manually, this is
1304 applicable to both IPv4 and IPv6 addressing.
1306 o slaac: enables stateless address autoconfiguration ([RFC4862]).
1307 This is applicable only for IPv6.
1309 o provider-dhcp-slaac: the provider will provide DHCP service for
1310 customer equipments as well as stateless address
1311 autoconfiguration. This is applicable only for IPv6.
1313 In the dynamic addressing mechanism, it is expected from the service
1314 provider to provide at least the IP address, mask and default gateway
1315 information.
1317 6.3.2.2.2. OAM
1319 A customer may require a specific IP connectivity fault detection
1320 mechanism on the IP connection. The model supports BFD as a fault
1321 detection mechanism. This can be extended with other mechanisms by
1322 augmentation. The provider can propose some profiles to the customer
1323 depending of the service level the customer wants to achieve.
1324 Profile names must be communicated to the customer. This
1325 communication is out of scope of this document. Some fixed values
1326 for the holdtime period may also be imposed by the customer if the
1327 provider enables it.
1329 The OAM container can easily be augmented by other mechanisms,
1330 especially work from LIME Working Group may be reused.
1332 6.3.2.3. Inheritance of parameters between site and site-network-access
1334 Some parameters can be configured both at the site level at the site-
1335 network-access level: e.g. routing, services, security... Inheritance
1336 applies when parameters are defined at site level. If a parameter is
1337 configured at both site and access level, the access level parameter
1338 MUST override the site level parameter. Those parameters will be
1339 described later in the document.
1341 In terms of provisionning impact, it will be up to the implementation
1342 to decide of the appropriate behavior when modifying existing
1343 configurations. But the service provider will need to communicate to
1344 the user about the impact of using inheritance. For example, if we
1345 consider that a site has already provisionned three site-network-
1346 accesses, what will happen if customer is changing a service
1347 parameter at site level ? An implementation of this model may update
1348 the service parameters of all already provisionned site-network-
1349 accesses (with potential impact on live traffic) or it may take into
1350 account this new parameter only for the new sites.
1352 6.4. Site role
1354 A VPN has a particular service topology as described in
1355 Section 6.2.1. As a consequence, each site belonging to a VPN is
1356 assigned with a particular role in this topology. The site-role
1357 defines the role of the site in a particular VPN topology.
1359 In the any-to-any VPN service topology, all sites MUST have the same
1360 role which is any-to-any-role.
1362 In the hub-spoke or hub-spoke-disjoint VPN service topology, sites
1363 MUST have a hub-role or a spoke-role.
1365 6.5. Site belonging to multiple VPNs
1367 6.5.1. Site vpn flavor
1369 A site may be part of one or multiple VPNs. The site flavor defines
1370 the way the VPN multiplexing is done. The current version of the
1371 model supports four flavors:
1373 o site-vpn-flavor-single: the site belongs to only one VPN.
1375 o site-vpn-flavor-multi: the site belongs to multiple VPNs and all
1376 the logical accesses of the sites belongs to the same set of VPNs.
1378 o site-vpn-flavor-sub: the site belongs to multiple VPNs with
1379 multiple logical accesses. Each logical access may map to
1380 different VPNs (one or many).
1382 o site-vpn-flavor-nni: the site represents an option A NNI.
1384 6.5.1.1. Single VPN attachment : site-vpn-flavor-single
1386 The figure below describes the single VPN attachment. The site
1387 connects to only one VPN.
1389 +--------+
1390 +------------------+ Site / \
1391 | |-----------------------------| |
1392 | |***(site-network-access#1)***| VPN1 |
1393 | New York Office | | |
1394 | |***(site-network-access#2)***| |
1395 | |-----------------------------| |
1396 +------------------+ \ /
1397 +--------+
1399 6.5.1.2. Multi VPN attachment : site-vpn-flavor-multi
1401 The figure below describes a site connected to multiple VPNs.
1403 +---------+
1404 +---/----+ \
1405 +------------------+ Site / | \ |
1406 | |--------------------------------- | |VPN B|
1407 | |***(site-network-access#1)******* | | |
1408 | New York Office | | | | |
1409 | |***(site-network-access#2)******* \ | /
1410 | |-----------------------------| VPN A+-----|---+
1411 +------------------+ \ /
1412 +--------+
1414 In the example above, the New York office is multihomed, both logical
1415 accesses are using the same VPN attachment rules. Both logical
1416 accesses are connected to VPN A and VPN B.
1418 Reaching VPN A or VPN B from New York office will be based on
1419 destination based routing. Having the same destination reachable
1420 from the two VPNs may cause routing troubles. This would be the role
1421 of the customer administration to ensure the appropriate mapping of
1422 its prefixes in each VPN.
1424 6.5.1.3. Sub VPN attachment : site-vpn-flavor-sub
1426 The figure below describes a subVPN attachment. The site connects to
1427 multiple VPNs but each logical access is attached to a particular set
1428 of VPN. A typical use case of subVPN is a customer site used by
1429 multiple affiliates with private resources for each affiliates that
1430 cannot be shared (communication is prevented between the affiliates).
1431 It is similar than having separate sites instead that the customer
1432 wants to share some physical components while keeping a strong
1433 communication isolation between affiliates. In the example, the
1434 access#1 is attached to VPN B while the access#2 is attached to VPNA.
1436 +------------------+ Site +--------+
1437 | |----------------------------------/ \
1438 | |****(site-network-access#1)******| VPN B |
1439 | New York Office | \ /
1440 | | +--------+
1441 | | +--------+
1442 | | / \
1443 | |****(site-network-access#2)******| VPN A |
1444 | | \ /
1445 | | +--------+
1446 | |-----------------------------------
1447 +------------------+
1449 MultiVPN can be implemented in addition to subVPN, as a consequence,
1450 each site-network-access can access to multiple VPNs. In the example
1451 below, access#1 is mapped to VPN B and VPN C, while access#2 is
1452 mapped to VPN A and VPN D.
1454 +------------------+ Site +-----+
1455 | |----------------------------------/ +----+
1456 | |****(site-network-access#1)******| VPN B/ \
1457 | New York Office | \ | VPN C |
1458 | | +----\ /
1459 | | +-----+
1460 | |
1461 | | +------+
1462 | | / +-----+
1463 | |****(site-network-access#2)******| VPN A/ \
1464 | | \ | VPN D |
1465 | | +------\ /
1466 | |----------------------------------- +---+
1467 +------------------+
1469 Multihoming is also possible with subVPN, in this case, site-network-
1470 accesses are grouped, and a particular group will access to the same
1471 set of VPNs. In the example below, access#1 and #2 are part of the
1472 same group (multihomed together) and are mapped to VPN B and C, in
1473 addition access#3 and #4 are part of the same group (multihomed
1474 together) and are mapped to VPN A and D.
1476 +------------------+ Site +-----+
1477 | |----------------------------------/ +----+
1478 | |****(site-network-access#1)******| VPNB / \
1479 | New York Office |****(site-network-access#2)******\ | VPN C |
1480 | | +----\ /
1481 | | +-----+
1482 | |
1483 | | +------+
1484 | | / +-----+
1485 | |****(site-network-access#3)******| VPNA / \
1486 | |****(site-network-access#4)****** \ | VPN D |
1487 | | +------\ /
1488 | |----------------------------------- +---+
1489 +------------------+
1491 In terms of service configuration, subVPN can be achieved by
1492 requesting the site-network-access to use the same bearer (see
1493 Section 6.6.4 and Section 6.6.6.4 for more details).
1495 6.5.1.4. NNI : site-vpn-flavor-nni
1497 Some Network to Network Interface (NNI) scenario may be modeled using
1498 the site container (see Section 6.15.1). Using the site container to
1499 model an NNI is only one possible option for NNI (see Section 6.15).
1500 This option is called option A by reference to the option A NNI
1501 defined in [RFC4364]. It is helpful for the service provider to
1502 identify that the requested VPN connection is not a regular site but
1503 a NNI as specific default device configuration parameters may be
1504 applied in case of NNI (e.g. ACLs, routing policies...).
1506 SP A SP B
1507 --------------------- --------------------
1508 / \ / \
1509 | | | |
1510 | ++++++++ InterAS link ++++++++ |
1511 | + +_____________ + + |
1512 | + (VRF1)--(VPN1)----(VRF1) + |
1513 | + ASBR + + ASBR + |
1514 | + (VRF2)--(VPN2)----(VRF2) + |
1515 | + +______________+ + |
1516 | ++++++++ ++++++++ |
1517 | | | |
1518 | | | |
1519 | | | |
1520 | ++++++++ InterAS link ++++++++ |
1521 | + +_____________ + + |
1522 | + (VRF1)--(VPN1)----(VRF1) + |
1523 | + ASBR + + ASBR + |
1524 | + (VRF2)--(VPN2)----(VRF2) + |
1525 | + +______________+ + |
1526 | ++++++++ ++++++++ |
1527 | | | |
1528 | | | |
1529 \ / \ /
1530 -------------------- -------------------
1532 The figure above describes an option A NNI scenario that can be
1533 modeled using the site container. In order to connect its customer
1534 VPN (VPN1 and VPN2) on the SP B network, SP A may request the
1535 creation of some site-network-accesses to SP B. The site-vpn-flavor-
1536 nni will be used to inform SP B that this is an NNI and not a regular
1537 customer site. The site-vpn-flavor-nni may be multihomed and
1538 multiVPN as well.
1540 6.5.2. Attaching a site to a VPN
1542 Due to the multiple site-vpn flavors, the attachment of a site to an
1543 IPVPN is done at the site-network-access (logical access) level
1544 through the vpn-attachment container. The vpn-attachment container
1545 is mandatory. The model provides two ways of attachment:
1547 o By referencing directly the target VPN.
1549 o By referencing a VPN policy for more complex attachments.
1551 A choice is implemented to allow user to choose the best fitting
1552 flavor.
1554 6.5.2.1. Reference a VPN
1556 Referencing a vpn-id provides an easy way to attach a particular
1557 logical access to a VPN. This is the best way in case of single VPN
1558 attachment or subVPN with single VPN attachment per logical access.
1559 When referencing a vpn-id, the site-role must be added to express the
1560 role of the site in the target VPN service topology.
1562
1563 SITE1
1564
1565
1566 LA1
1567
1568 VPNA
1569 spoke-role
1570
1571
1572 LA2
1573
1574 VPNB
1575 spoke-role
1576
1577
1578
1579
1581 The example above describes a subVPN case where a site SITE1 has two
1582 logical accesses (LA1 and LA2) with LA1 attached to VPNA and LA2
1583 attached to VPNB.
1585 6.5.2.2. VPN policy
1587 The vpn-policy helps to express a multiVPN scenario where a logical
1588 access belongs to multiple VPNs. Multiple VPN policies can be
1589 created to handle the subVPN case where each logical access is part
1590 of a different set of VPNs.
1592 As a site can belong to multiple VPNs, the vpn-policy may be composed
1593 of multiple entries. A filter can be applied to specify that only
1594 some LANs of the site should be part of a particular VPN. Each time
1595 a site (or LAN) is attached to a VPN, the user must precisely
1596 describe its role (site-role) within the target VPN service topology.
1598 +--------------------------------------------------------------+
1599 | Site1 ------ PE7 |
1600 +-------------------------+ [VPN2] |
1601 | |
1602 +-------------------------+ |
1603 | Site2 ------ PE3 PE4 ------ Site3 |
1604 +----------------------------------+ |
1605 | |
1606 +------------------------------------------------------------+ |
1607 | Site4 ------ PE5 | PE6 ------ Site5 | |
1608 | | |
1609 | [VPN3] | |
1610 +------------------------------------------------------------+ |
1611 | |
1612 +---------------------------+
1614 In the example above, Site5 is part of two VPNs: VPN3 and VPN2. It
1615 will play a hub-role in VPN2 and an any-to-any role in VPN3. We can
1616 express such multiVPN scenario as follows:
1618
1619 Site5
1620
1621
1622 POLICY1
1623
1624 ENTRY1
1625
1626 VPN2
1627 hub-role
1628
1629
1630
1631 ENTRY2
1632
1633 VPN3
1634 any-to-any-role
1635
1636
1637
1638
1639
1640
1641 LA1
1642
1643 POLICY1
1644
1645
1646
1647
1649 Now, if a more granular VPN attachment is necessary, filtering can be
1650 used. For example, if LAN1 from Site5 must be attached to VPN2 as
1651 Hub and LAN2 must be attached to VPN3, the following configuration
1652 can be used:
1654
1655 Site5
1656
1657
1658 POLICY1
1659
1660 ENTRY1
1661
1662 LAN1
1663
1664
1665 VPN2
1666 hub-role
1667
1668
1669
1670 ENTRY2
1671
1672 LAN2
1673
1674
1675 VPN3
1676 any-to-any-role
1677
1678
1679
1680
1681
1682
1683 LA1
1684
1685 POLICY1
1686
1687
1688
1689
1691 6.6. Deciding where to connect the site
1693 The management system will have to determine where to connect each
1694 site-network-access of a particular site to the provider network (PE,
1695 aggregation switch ...).
1697 The current model proposes parameters and constraints that can
1698 influence the meshing of the site-network-access.
1700 The management system SHOULD honor the customer constraints, if the
1701 constraint is too strict and can not be filled, the management system
1702 MUST not provision the site and SHOULD provide an information to the
1703 user. How the information is provided is out of scope of the
1704 document. It would then be up to the user to relax the constraint or
1705 not.
1707 Parameters are just hints for the management system for service
1708 placement.
1710 In addition to parameters and constraints, the management system
1711 decision MAY be based on any other internal constraint that are up to
1712 the service provider: least load, distance ...
1714 6.6.1. Constraint: Device
1716 In case of provider-management or co-management, one or more devices
1717 have been ordered by the customer. The customer may force a
1718 particular site-network-access to be connected on a particular device
1719 he ordered.
1721 New York Site
1723 +------------------+ Site
1724 | +--------------+ |-----------------------------------
1725 | | Manhattan | |
1726 | | CE1********* (site-network-access#1) ******
1727 | +--------------+ |
1728 | +--------------+ |
1729 | | Brooklyn CE2********* (site-network-access#2) ******
1730 | +--------------+ |
1731 | |-----------------------------------
1732 +------------------+
1734 In the figure above, the site-network-access#1 is associated to CE1
1735 in the service request. The service provider must ensure the
1736 provisionning of this connection.
1738 6.6.2. Constraint/parameter: Site location
1740 The location information provided in this model MAY be used by a
1741 management system to determine the target PE to mesh the site
1742 (service provider side). A particular location must be associated to
1743 each site network access when configuring it. The service provider
1744 MUST honor the termination of the access on the location associated
1745 with the site network access (customer side). The country-code in
1746 the site-location SHOULD be expressed as an ISO ALPHA-2 code.
1748 The site-network-access location is determined by the "location-
1749 flavor". In case of provider-managed or co-managed site, the user is
1750 expected to configure a "device-reference" (device case) that will
1751 bind the site-network-access to a particular device the customer
1752 ordered. As each device is already associated to a particular
1753 location, in such case the location information is retrieved from the
1754 device location. In case of customer-managed site, the user is
1755 expected to configure a "location-reference" (location case), this
1756 provides a reference to an existing configured location and will help
1757 the placement.
1759 PoP#1 (New York)
1760 +---------+
1761 | PE1 |
1762 Site #1 ---... | PE2 |
1763 (Atlantic City) | PE3 |
1764 +---------+
1766 PoP#2 (Washington)
1767 +---------+
1768 | PE4 |
1769 | PE5 |
1770 | PE6 |
1771 +---------+
1773 PoP#3 (Philadelphia)
1774 +---------+
1775 | PE7 |
1776 Site #2 CE#1---... | PE2 |
1777 (Reston) | PE9 |
1778 +---------+
1780 In the example above, Site#1 is a customer managed site with a
1781 location L1, while Site#2 is a provider-managed site for which a CE#1
1782 was ordered, Site#2 is configured with L2 as location. When
1783 configuring a site-network-access for Site#1, the user will need to
1784 reference the location L1, so the management system will know that
1785 the access will need to terminate on this location. Then this
1786 management system may mesh Site#1 on a PE in the Philadelphia PoP for
1787 distance reason. It may also take into account resources available
1788 on PEs to determine the exact target PE (e.g. least loaded).
1789 Regarding Site#2, the user is expected to configure the site-network-
1790 access with a device-reference to CE#1, so the management system will
1791 know that the access must terminate on the location of CE#1 and must
1792 be connected to CE#1. For placing the service provider side of the
1793 access connection, in case of shortest distance PE used, it may mesh
1794 Site #2 on the Washington PoP.
1796 6.6.3. Constraint/parameter: access type
1798 The management system needs to elect the access media to connect the
1799 site to the customer (for example : xDSL, leased line, Ethernet
1800 backhaul ...). The customer may provide some parameters/constraints
1801 that will provide hints to the management system.
1803 The bearer container information SHOULD be used as first input :
1805 o The "requested-type" provides an information about the media type
1806 the customer would like. If the "strict" leaf is equal to "true",
1807 this MUST be considered as a strict constraint, so the management
1808 system cannot connect the site with another media type. If the
1809 "strict" leaf is equal to "false" (default), if the requested-type
1810 cannot be fulfilled, the management system can select another
1811 type. The supported media types SHOULD be communicated by the
1812 service provider to the customer by a mechanism that is out of
1813 scope of the document.
1815 o The "always-on" leaf defines a strict constraint: if set to
1816 "true", the management system MUST elect a media type which is
1817 always-on (this means no dial access type).
1819 o The "bearer-reference" is used in case the customer has already
1820 ordered a network connection to the service provider apart of the
1821 IPVPN site and wants to reuse this connection. The string used in
1822 an internal reference from the service provider describing the
1823 already available connection. This is also a strict requirement
1824 that cannot be relaxed. How the reference is given to the
1825 customer is out of scope of the document but as a pure example,
1826 when the customer ordered the bearer (through a process out of
1827 this model), the service provider may had provided the bearer
1828 reference that can be used for provisionning services on top.
1830 Any other internal parameters from the service provider can be used
1831 in addition. The management system MAY use other parameters such as
1832 the requested svc-input-bandwidth and svc-output-bandwidth to help to
1833 decide the access type to be used.
1835 6.6.4. Constraint: access diversity
1837 Each site-network-access may have one or more constraints that would
1838 drive the placement of the access. By default, the model assumes no
1839 constraint but is expected allocation of a unique bearer per site-
1840 network-access.
1842 In order to help the different placement scenarios, a site-network-
1843 access may be tagged using one or multiple group identifiers. The
1844 group identifier is a string so it can accommodate both explicit
1845 naming of a group of sites (e.g. "multihomed-set1" or "subVPN") or a
1846 numbered identifier (e.g. 12345678). The meaning of each group-id is
1847 local to each customer administrator. And the management system MUST
1848 ensure that different customers can use the same group-ids. One or
1849 more group-ids can also be defined at the site-level, as a
1850 consequence, all site-network-accesses under the site MUST inherit
1851 the group-ids of the site they are belonging to. When, in addition
1852 to the site group-ids, some group-ids are defined at the site-
1853 network-access level, the management system MUST consider the union
1854 of all groups (site level and site network access level) for this
1855 particular site-network-access.
1857 For an already configured site-network-access, each constraint MUST
1858 be expressed against a targeted set of site-network-accesses, this
1859 site-network-access MUST never be taken into account in the targeted
1860 set: e.g. "My site-network-access S must not be connected on the
1861 same PoP as the site-network-accesses that are part of group 10".
1862 The set of site-network-accesses against which the constraint is
1863 evaluated can be expressed as a list of groups or "all-other-
1864 accesses" or "all-other-groups". The "all-other-accesses" option
1865 means that the current site-network-access constraint MUST be
1866 evaluated against all the other site-network-accesses belonging to
1867 the current site. The "all-other-groups" option means that the
1868 constraint MUST be evaluated against all groups the current site-
1869 network-access is not belonging to.
1871 The current model proposes multiple constraint-types:
1873 pe-diverse: the current site-network-access MUST not be connected
1874 to the same PE as the targeted site-network-accesses.
1876 pop-diverse: the current site-network-access MUST not be connected
1877 to the same PoP as the targeted site-network-accesses.
1879 linecard-diverse: the current site-network-access MUST not be
1880 connected to the same linecard as the targeted site-network-
1881 accesses.
1883 bearer-diverse: the current site-network-access MUST NOT use
1884 common bearer components compared to bearers used by the targeted
1885 site-network-accesses. "bearer-diverse" provides some level of
1886 diversity at the access level. As an example, two "bearer-
1887 diverse" site-network-accesses must not use the same DSLAM or BAS
1888 or layer 2 switch...
1890 same-pe: the current site-network-access MUST be connected to the
1891 same PE as the targeted site-network-accesses.
1893 same-bearer: the current site-network-access MUST be connected
1894 using the same bearer as the targeted site-network-accesses.
1896 These constraint-types can be extended through augmentation.
1898 Each constraint is expressed as "The site-network-access S must be
1899 (e.g. pe-diverse, pop-diverse) from these
1900 site-network-accesses".
1902 The group-id used to target some site-network-accesses may be the
1903 same as the one used by the current site-network-access. This eases
1904 configuration of scenarios where a group of site-network-access has a
1905 constraint between each other. As an example if we want a set of
1906 sites (site#1 up to #5) to be connected on different PEs, we can tag
1907 them with the same group-id and express a pe-diverse constraint for
1908 this group-id.
1910
1911 SITE1
1912
1913
1914 1
1915
1916
1917
1918 10
1919
1920
1921
1922
1923 pe-diverse
1924
1925
1926 10
1927
1928
1929
1930
1931
1932
1933 VPNA
1934 spoke-role
1935
1936
1937
1938
1939
1940 SITE2
1941
1942
1943 1
1944
1945
1946
1947 10
1948
1949
1950
1951
1952 pe-diverse
1953
1954
1955 10
1956
1957
1958
1959
1960
1961
1962 VPNA
1963 spoke-role
1964
1965
1966
1967
1968 ...
1969
1970 SITE5
1971
1972
1973 1
1974
1975
1976
1977 10
1978
1979
1980
1981
1982 pe-diverse
1983
1984
1985 10
1986
1987
1988
1990
1991
1992
1993 VPNA
1994 spoke-role
1995
1996
1997
1998
2000 The group-id used to target some site-network-accesses may be also
2001 different than the one used by the current site-network-access. This
2002 can be used to express that a group of site has some constraints
2003 against another group of sites, but there is no constraint within the
2004 group. As an example, if we consider a set of 6 sites with two sets
2005 and we want to ensure that a site in the first set must be pop-
2006 diverse from a site in the second set.
2008
2009 SITE1
2010
2011
2012 1
2013
2014
2015
2016 10
2017
2018
2019
2020
2021 pop-diverse
2022
2023
2024 20
2025
2026
2027
2028
2029
2030
2031 VPNA
2032 spoke-role
2033
2034
2035
2036
2037
2038 SITE2
2039
2040
2041 1
2042
2043
2044
2045 10
2046
2047
2048
2049
2050 pop-diverse
2051
2052
2053 20
2054
2055
2056
2057
2058
2059
2060 VPNA
2061 spoke-role
2062
2063
2064
2065
2066 ...
2067
2068 SITE5
2069
2070
2071 1
2072
2073
2074
2075 20
2076
2077
2078
2079
2080 pop-diverse
2081
2082
2083 10
2084
2085
2087
2088
2089
2090
2091 VPNA
2092 spoke-role
2093
2094
2095
2096
2097
2098 SITE6
2099
2100
2101 1
2102
2103
2104
2105 20
2106
2107
2108
2109
2110 pop-diverse
2111
2112
2113 10
2114
2115
2116
2117
2118
2119
2120 VPNA
2121 spoke-role
2122
2123
2124
2125
2127 6.6.5. Impossible access placement
2129 Some impossible placement scenarios may be created through the
2130 proposed configuration framework. Impossible scenarios could come
2131 from too restrictive constraints leading to impossible placement in
2132 the network or conflicting constraints that would also lead to
2133 impossible placement. An example of conflicting rules would be to
2134 request a site-network-access#1 to be pe-diverse from a site-network-
2135 access#2 and to request at the same time that site-network-access#2
2136 to be on the same PE as site-network-access#1. When the management
2137 system cannot determine the placement of a site-network-access, it
2138 SHOULD return an error message indicating that placement was not
2139 possible.
2141 6.6.6. Examples of access placement
2143 6.6.6.1. Multihoming
2145 The customer wants to create a multihomed site. The site will be
2146 composed of two site-network-accesses and the customer wants the two
2147 site-network-accesses to be meshed on different PoPs for resiliency
2148 purpose.
2150 PoP#1
2151 +-------+ +---------+
2152 | | | PE1 |
2153 | |---site_network_access#1 ---- | PE2 |
2154 | | | PE3 |
2155 | | +---------+
2156 | Site#1|
2157 | | PoP#2
2158 | | +---------+
2159 | | | PE4 |
2160 | |---site_network_access#2 ---- | PE5 |
2161 | | | PE6 |
2162 | | +---------+
2163 +-------+
2165 This scenario can be expressed in the following way:
2167
2168 SITE1
2169
2170
2171 1
2172
2173
2174
2175 10
2176
2177
2178
2179
2180 pop-diverse
2181
2182
2183 20
2184
2185
2186
2187
2188
2189
2190 VPNA
2191 spoke-role
2192
2193
2194
2195 2
2196
2197
2198
2199 20
2200
2201
2202
2203
2204 pop-diverse
2205
2206
2207 10
2208
2209
2210
2211
2212
2213
2214 VPNA
2215 spoke-role
2216
2217
2218
2219
2221 But it can also be expressed as:
2223
2224 SITE1
2225
2226
2227 1
2228
2229
2230
2231 pop-diverse
2232
2233
2234
2235
2236
2237
2238
2239 VPNA
2240 spoke-role
2241
2242
2243
2244 2
2245
2246
2247
2248 pop-diverse
2249
2250
2251
2252
2253
2254
2255
2256 VPNA
2257 spoke-role
2258
2259
2260
2261
2263 6.6.6.2. Site offload
2265 The customer has six branch offices in a particular region and he
2266 wants to prevent to have all branch offices to be connected on the
2267 same PE.
2269 He wants to express that three branch offices cannot be connected on
2270 the same linecard. And the other branch offices must be connected on
2271 a different PoP. Those other branch offices cannot also be connected
2272 on the same linecard.
2274 PoP#1
2275 +---------+
2276 | PE1 |
2277 Office#1 ---... | PE2 |
2278 Office#2 ---... | PE3 |
2279 Office#3 ---... | PE4 |
2280 +---------+
2282 PoP#2
2283 +---------+
2284 Office#4 ---... | PE4 |
2285 Office#5 ---... | PE5 |
2286 Office#6 ---... | PE6 |
2287 +---------+
2289 This scenario can be expressed in the following way:
2291 o We need to create two sets of sites: set#1 composed of Office#1 up
2292 to 3, set#2 composed of Office#4 up to 6.
2294 o Sites within set#1 must be pop-diverse from sites within set#2 and
2295 vice versa.
2297 o Sites within set#1 must be linecard-diverse from other sites in
2298 set#1 (same for set#2).
2300
2301 SITE1
2302
2303
2304 1
2305
2306
2307
2308 10
2309
2310
2311
2312
2313 pop-diverse
2314
2315
2316 20
2317
2318
2319
2320
2321 linecard-diverse
2322
2323
2324 10
2325
2326
2327
2328
2329
2330
2331 VPNA
2332 spoke-role
2333
2334
2335
2336
2337 SITE2
2338
2339
2340 1
2341
2342
2343
2344 10
2345
2346
2347
2348
2349 pop-diverse
2350
2351
2352 20
2353
2354
2355
2356
2357 linecard-diverse
2358
2359
2360 10
2361
2362
2363
2365
2366
2367
2368 VPNA
2369 spoke-role
2370
2371
2372
2373
2374 SITE3
2375
2376
2377 1
2378
2379
2380
2381 10
2382
2383
2384
2385
2386 pop-diverse
2387
2388
2389 20
2390
2391
2392
2393
2394 linecard-diverse
2395
2396
2397 10
2398
2399
2400
2401
2402
2403
2404 VPNA
2405 spoke-role
2406
2407
2408
2409
2411
2412 SITE4
2413
2414
2415 1
2416
2417
2418
2419 20
2420
2421
2422
2423
2424 pop-diverse
2425
2426
2427 10
2428
2429
2430
2431
2432 linecard-diverse
2433
2434
2435 20
2436
2437
2438
2439
2440
2441
2442 VPNA
2443 spoke-role
2444
2445
2446
2447
2448 SITE5
2449
2450
2451 1
2452
2453
2454
2455 20
2456
2457
2458
2459
2460 pop-diverse
2461
2462
2463 10
2464
2465
2466
2467
2468 linecard-diverse
2469
2470
2471 20
2472
2473
2474
2475
2476
2477
2478 VPNA
2479 spoke-role
2480
2481
2482
2483
2484 SITE6
2485
2486
2487 1
2488
2489
2490
2491 20
2492
2493
2494
2495
2496 pop-diverse
2497
2498
2499 10
2500
2501
2502
2503
2504 linecard-diverse
2505
2506
2507 20
2508
2510
2511
2512
2513
2514
2515 VPNA
2516 spoke-role
2517
2518
2519
2520
2522 6.6.6.3. Parallel links
2524 To increase its site bandwidth at a cheaper cost, a customer wants to
2525 order two parallel site-network-accesses that will be connected to
2526 the same PE.
2528 *******SNA1**********
2529 Site 1 *******SNA2********** PE1
2531 This scenario can be expressed in the following way:
2533
2534 SITE1
2535
2536
2537 1
2538
2539
2540
2541 PE-linkgrp-1
2542
2543
2544
2545
2546 same-pe
2547
2548
2549 PE-linkgrp-1
2550
2551
2552
2553
2554
2555
2556 VPNB
2557 spoke-role
2558
2559
2560
2561 2
2562
2563
2564
2565 PE-linkgrp-1
2566
2567
2568
2569
2570 same-pe
2571
2572
2573 PE-linkgrp-1
2574
2575
2576
2577
2578
2579
2580 VPNB
2581 spoke-role
2582
2583
2584
2585
2587 6.6.6.4. SubVPN with multihoming
2589 A customer has site which is dualhomed. The dualhoming must be done
2590 on two different PEs. The customer wants also to implement two
2591 subVPNs on those multihomed accesses.
2593 +------------------+ Site +-----+
2594 | |----------------------------------/ +----+
2595 | |****(site-network-access#1)******| VPNB / \
2596 | New York Office |****(site-network-access#2)*************| VPN C |
2597 | | +----\ /
2598 | | +-----+
2599 | |
2600 | | +------+
2601 | | / +-----+
2602 | |****(site-network-access#3)******| VPNB / \
2603 | |****(site-network-access#4)**************| VPN C |
2604 | | +------\ /
2605 | |----------------------------------- +---+
2606 +------------------+
2608 This scenario can be expressed in the following way:
2610 o The site will have 4 site network accesses (2 subVPN coupled with
2611 dual homing).
2613 o Site-network-access#1 and #3 will correspond to the multihoming of
2614 the subVPN B. A PE-diverse constraint is required between them.
2616 o Site-network-access#2 and #4 will correspond to the multihoming of
2617 the subVPN C. A PE-diverse constraint is required between them.
2619 o To ensure proper usage of the same bearer for the subVPN, site-
2620 network-access #1 and #2 must share the same bearer as site-
2621 network-access #3 and #4.
2623
2624 SITE1
2625
2626
2627 1
2628
2629
2630
2631 dualhomed-1
2632
2633
2634
2635
2636 pe-diverse
2637
2638
2639 dualhomed-2
2640
2642
2643
2644
2645 same-bearer
2646
2647
2648 dualhomed-1
2649
2650
2651
2652
2653
2654
2655 VPNB
2656 spoke-role
2657
2658
2659
2660 2
2661
2662
2663
2664 dualhomed-1
2665
2666
2667
2668
2669 pe-diverse
2670
2671
2672 dualhomed-2
2673
2674
2675
2676
2677 same-bearer
2678
2679
2680 dualhomed-1
2681
2682
2683
2684
2685
2686
2687 VPNC
2688 spoke-role
2689
2691
2692 3
2693
2694
2695
2696 dualhomed-2
2697
2698
2699
2700
2701 pe-diverse
2702
2703
2704 dualhomed-1
2705
2706
2707
2708
2709 same-bearer
2710
2711
2712 dualhomed-2
2713
2714
2715
2716
2717
2718
2719 VPNB
2720 spoke-role
2721
2722
2723
2724 4
2725
2726
2727
2728 dualhomed-2
2729
2730
2731
2732
2733 pe-diverse
2734
2735
2736 dualhomed-1
2737
2738
2740
2741
2742 same-bearer
2743
2744
2745 dualhomed-2
2746
2747
2748
2749
2750
2751
2752 VPNC
2753 spoke-role
2754
2755
2756
2757
2759 6.6.7. Route Distinguisher and VRF allocation
2761 The route-distinguisher is a critical parameter of PE-based L3VPNs as
2762 described in [RFC4364] that allows to distinguish common addressing
2763 plans in different VPNs. As for route-targets, it is expected that a
2764 management system will allocate a VRF on the target PE and a route-
2765 distinguisher for this VRF.
2767 If a VRF already exists on the target PE, and the VRF fulfils the
2768 connectivity constraints for the site, there is no need to recreate
2769 another VRF and the site MAY be meshed within this existing VRF. How
2770 the management system checks that an existing VRF fulfils the
2771 connectivity constraints for a site is out of scope of this document.
2773 If no such a VRF exists on the target PE, the management system has
2774 to initiate a new VRF creation on the target PE and has to allocate a
2775 new route-distinguisher for this new VRF.
2777 The management system MAY apply a per-VPN or per-VRF allocation
2778 policy for the route-distinguisher depending on the service provider
2779 policy. In a per-VPN allocation policy, all VRFs (dispatched on
2780 multiple PEs) within a VPN will share the same route distinguisher
2781 value. In a per-VRF model, all VRFs should always have a unique
2782 route-distinguisher value. Some other allocation policies are also
2783 possible, and this document does not restrict the allocation policies
2784 to be used.
2786 The allocation of route-distinguishers MAY be done in the same way as
2787 route-targets. The example provided in Section 6.2.1.1 could be
2788 reused.
2790 Note that a service provider MAY configure a target PE for an
2791 automated allocation of route-distinguishers. In this case, there
2792 will be no need for any backend system to allocate a route-
2793 distinguisher value.
2795 6.7. Site network access availability
2797 A site may be multihomed, meaning it has multiple site-network-access
2798 points. Placement constraints defined in previous sections will help
2799 to ensure physical diversity.
2801 When the site-network-accesses are placed on the network, a customer
2802 may want to use a particular routing policy on those accesses.
2804 The "site-network-access/availability" container defines parameters
2805 for the site redundancy. The "access-priority" leaf defines a
2806 preference for a particular access. This preference is used to model
2807 loadbalancing or primary/backup scenarios. The higher the access-
2808 priority the higher the preference will be.
2810 The figure below describes how the access-priority attribute can be
2811 used.
2813 Hub#1 LAN (Primary/backup) Hub#2 LAN (Loadsharing)
2814 | |
2815 | access-priority 1 access-priority 1 |
2816 |--- CE1 ------- PE1 PE3 --------- CE3 --- |
2817 | |
2818 | |
2819 |--- CE2 ------- PE2 PE4 --------- CE4 --- |
2820 | access-priority 2 access-priority 1 |
2822 PE5
2823 |
2824 |
2825 |
2826 CE5
2827 |
2828 Spoke#1 site (Single-homed)
2830 In the figure above, Hub#2 requires loadsharing so all the site-
2831 network-accesses must use the same access-priority value. On the
2832 contrary, as Hub#1 requires primary/backup, an higher access-priority
2833 will be configured on the primary access.
2835 More complex scenarios can be modeled. Let's consider a Hub site
2836 with five accesses to the network (A1,A2,A3,A4,A5). The customer
2837 wants to loadshare its traffic on A1,A2 in the nominal situation. If
2838 A1 and A2 fails, he wants to loadshare its traffic on A3 and A4, and
2839 finally if A1 to A4 are down, he wants to use A5. We can model it
2840 easily by configuring the following access-priorities: A1=100,
2841 A2=100, A3=50, A4=50, A5=10.
2843 The access-priority has some limitation. A scenario like the
2844 previous one with five accesses but with the constraint of having
2845 traffic loadshared between A3 and A4 in case of A1 OR A2 being down
2846 is not achievable. But the authors consider that the access-priority
2847 covers most of the deployment use cases and the model can still be
2848 extended by augmentation to support additional use cases.
2850 6.8. Traffic protection
2852 The service model supports the ability to protect the traffic for a
2853 site. A protection provides a better availability to multihoming by,
2854 for example, using local-repair techniques in case of failures. The
2855 associated level of service guarantee would be based on an agreement
2856 between customer and service provider and is out of scope of this
2857 document.
2859 Site#1 Site#2
2860 CE1 ----- PE1 -- P1 P3 -- PE3 ---- CE3
2861 | | |
2862 | | |
2863 CE2 ----- PE2 -- P2 P4 -- PE4 ---- CE4
2864 /
2865 /
2866 CE5 ----+
2867 Site#3
2869 In the figure above, we consider an IPVPN service with three sites
2870 including two dual homed sites (site#1 and #2). For dual homed
2871 sites, we consider PE1-CE1 and PE3-CE3 as primary, and
2872 PE2-CE2,PE4-CE4 as backup for the example (even if protection also
2873 applies to loadsharing scenarios).
2875 In order to protect Site#2 against a failure, user may set the
2876 "traffic-protection/enabled" leaf to true for site#2. How the
2877 traffic protection will be implemented is out of scope of the
2878 document. But as an example, in such a case, if we consider traffic
2879 coming from a remote site (site#1 or site#3), where the primary path
2880 is to use PE3 as egress PE. PE3 may have preprogrammed a backup
2881 forwarding entry pointing to backup path (through PE4-CE4) for all
2882 prefixes going through PE3-CE3 link. How the backup path is computed
2883 is out of scope of the document. When PE3-CE3 link fails, traffic is
2884 still received by PE3 but PE3 switch automatically traffic to the
2885 backup entry, path will so be PE1-P1-(...)-P3-PE3-PE4-CE4 until
2886 remote PEs reconverge and use PE4 as the egress PE.
2888 6.9. Security
2890 The "security" container defines customer specific security
2891 parameters for the site. The security options supported in the model
2892 are limited but may be extended by augmentation.
2894 6.9.1. Authentication
2896 The current model does not support any authentication parameters for
2897 the site connection, but such parameters may be added in the
2898 "authentication" container through augmentation.
2900 6.9.2. Encryption
2902 A traffic encryption can be requested on the connection. It may be
2903 performed at layer 2 or layer 3 by selecting the appropriate
2904 enumeration in "layer" leaf. For example, a service provider may use
2905 IPSec when a customer is requesting layer 3 encryption. The
2906 encryption profile can be a service provider defined profile or a
2907 customer specific.
2909 When a service provider profile is used and a key (e.g. a preshared
2910 key) is allocated by the provider to be used by a customer, the
2911 service provider should provide a way to communicate the key in a
2912 secured way to the customer.
2914 When a customer profile is used, the model supports only preshared
2915 key for authentication with the preshared key provided through the
2916 NETCONF or RESTCONF request. A secure channel must be used to ensure
2917 that the preshared key cannot be intercepted.
2919 It may be necessary for the customer to change the preshared key on a
2920 regular basis for security reasons. To perform a key change, the
2921 user can request to the service provider by submitting a new
2922 preshared key for the site configuration (as displayed below). This
2923 mechanism may not to be hitless.
2925
2926 SITE1
2927
2928
2929 1
2930
2931
2932 MY_NEW_KEY
2933
2934
2935
2936
2937
2939 An hitless key change mechanism may be added through augmentation.
2941 Other key management methodology may be added through augmentation.
2942 A "pki" empty container has been created to help support of PKI
2943 through augmentation.
2945 6.10. Management
2947 The model proposes three types of common management options:
2949 o provider-managed: the CE router is managed only by the provider.
2950 In this model, the responsibility boundary between SP and customer
2951 is between CE and customer network.
2953 o customer-managed: the CE router is managed only by the customer.
2954 In this model, the responsibility boundary between SP and customer
2955 is between PE and CE.
2957 o co-managed: the CE router is primarly managed by the provider and
2958 in addition SP lets customer accessing the CE for some
2959 configuration/monitoring purpose. In the co-managed mode the
2960 responsibility boundary is the same as the provider-managed model.
2962 Based on the management model, different security options MAY be
2963 derived.
2965 In case of "co-managed", the model proposes some options to define
2966 the management address family (IPv4 or IPv6) and the associated
2967 management address.
2969 6.11. Routing protocols
2971 Routing-protocol defines which routing protocol must be activated
2972 between the provider and the customer router. The current model
2973 supports: bgp, rip, ospf, static, direct, vrrp.
2975 The routing protocol defined applies at the provider to customer
2976 boundary. Depending on the management of the management model, it
2977 may apply to the PE-CE boundary or CE to customer boundary. In case
2978 of a customer managed site, the routing-protocol defined will be
2979 activated between the PE and the CE router managed by the customer.
2980 In case of a provider managed site, the routing-protocol defined will
2981 be activated between the CE managed by the SP and the router or LAN
2982 belonging to the customer. In this case, it is expected that the PE-
2983 CE routing will be configured based on the service provider rules as
2984 both are managed by the same entity.
2986 Rtg protocol
2987 192.0.2.0/24 ----- CE ----------------- PE1
2989 Customer managed site
2991 Rtg protocol
2992 Customer router ----- CE ----------------- PE1
2994 Provider managed site
2996 All the examples below will refer to a customer managed site case.
2998 6.11.1. Dual stack handling
3000 All routing protocol types support dual stack by using address-family
3001 leaf-list.
3003 Example of Dual stack using the same routing protocol:
3005
3006
3007 static
3008
3009 ipv4
3010 ipv6
3011
3012
3013
3014 Example of Dual stack using two different routing protocols:
3016
3017
3018 rip
3019
3020 ipv4
3021
3022
3023
3024 ospf
3025
3026 ipv6
3027
3028
3029
3031 6.11.2. Direct LAN connection onto SP network
3033 Routing-protocol "direct" SHOULD be used when a customer LAN is
3034 directly connected to the provider network and must be advertised in
3035 the IPVPN.
3037 LAN attached directly to provider network:
3039 192.0.2.0/24 ----- PE1
3041 In this case, the customer has a default route to the PE address.
3043 6.11.3. Direct LAN connection onto SP network with redundancy
3045 Routing-protocol "vrrp" SHOULD be used when a customer LAN is
3046 directly connected to the provider network and must be advertised in
3047 the IPVPN and LAN redundancy is expected.
3049 LAN attached directly to provider network with LAN redundancy:
3051 192.0.2.0/24 ------ PE1
3052 |
3053 +--- PE2
3055 In this case, the customer has a default route to the service
3056 provider network.
3058 6.11.4. Static routing
3060 Routing-protocol "static" MAY be used when a customer LAN is
3061 connected to the provider network through a CE router and must be
3062 advertised in the IPVPN.
3064 Static rtg
3065 192.0.2.0/24 ------ CE -------------- PE
3066 | |
3067 | Static route 192.0.2.0/24 nh CE
3068 Static route 0.0.0.0/0 nh PE
3070 In this case, the customer has a default route to the service
3071 provider network.
3073 6.11.5. RIP routing
3075 Routing-protocol "rip" MAY be used when a customer LAN is connected
3076 to the provider network through a CE router and must be advertised in
3077 the IPVPN. For IPv4, the model assumes usage of RIP version 2.
3079 In case of dual stack routing requested through this model, the
3080 management system will be responsible to configure rip (including
3081 right version number) and associated address-families on network
3082 elements.
3084 RIP rtg
3085 192.0.2.0/24 ------ CE -------------- PE
3087 6.11.6. OSPF routing
3089 Routing-protocol "ospf" MAY be used when a customer LAN is connected
3090 to the provider network through a CE router and must be advertised in
3091 the IPVPN.
3093 It can be used to extend an existing OSPF network and interconnect
3094 different areas. See [RFC4577] for more details.
3096 +---------------------+
3097 | |
3098 OSPF | | OSPF
3099 area 1 | | area 2
3100 (OSPF | | (OSPF
3101 area 1) --- CE ---------- PE PE ----- CE --- area 2)
3102 | |
3103 +---------------------+
3105 The model also proposes an option to create an OSPF sham-link between
3106 two sites sharing the same area and having a backdoor link. The
3107 sham-link is created by referencing the target site sharing the same
3108 OSPF area. The management system will be responsible to check if
3109 there is already a shamlink configured for this VPN and area between
3110 the same pair of PEs. If there is no existing shamlink, the
3111 management system will provision it. This shamlink MAY be reused by
3112 other sites.
3114 +------------------------+
3115 | |
3116 | |
3117 | PE (--shamlink--)PE |
3118 | | | |
3119 +----|----------------|--+
3120 | OSPF area1 | OSPF area 1
3121 | |
3122 CE1 CE2
3123 | |
3124 (OSPF area1) (OSPF area1)
3125 | |
3126 +----------------+
3128 Regarding Dual stack support, user MAY specify both IPv4 and IPv6
3129 address families, if both protocols should be routed through OSPF.
3130 As OSPF uses separate protocol instances for IPv4 and IPv6, the
3131 management system will need to configure both ospf version 2 and
3132 version 3 on the PE-CE link.
3134 Example of OSPF routing parameters in service model.
3136
3137
3138 ospf
3139
3140 0.0.0.1
3141 ipv4
3142 ipv6
3143
3144
3145
3146 Example of PE configuration done by management system:
3148 router ospf 10
3149 area 0.0.0.1
3150 interface Ethernet0/0
3151 !
3152 router ospfv3 10
3153 area 0.0.0.1
3154 interface Ethernet0/0
3155 !
3157 6.11.7. BGP routing
3159 Routing-protocol "bgp" MAY be used when a customer LAN is connected
3160 to the provider network through a CE router and must be advertised in
3161 the IPVPN.
3163 BGP rtg
3164 192.0.2.0/24 ------ CE -------------- PE
3166 The session addressing will be derived from connection parameters as
3167 well as internal knowledge of SP.
3169 In case of dual stack access, user MAY request BGP routing for both
3170 IPv4 and IPv6 by specifying both address-families. It will be up to
3171 SP and management system to determine how to decline the
3172 configuration (two BGP sessions, single, multisession ...).
3174 The service configuration below activates BGP on PE-CE link for both
3175 IPv4 and IPv6.
3177 BGP activation requires SP to know the address of the customer peer.
3178 "static-address" allocation type for the IP connection MUST be used.
3180
3181
3182 bgp
3183
3184 65000
3185 ipv4
3186 ipv6
3187
3188
3189
3191 This service configuration can be derived by management system into
3192 multiple flavors depending on SP flavor.
3194 Example #1 of PE configuration done by management system
3195 (single session IPv4 transport session):
3197 router bgp 100
3198 neighbor 203.0.113.2 remote-as 65000
3199 address-family ipv4 vrf Cust1
3200 neighbor 203.0.113.2 activate
3201 address-family ipv6 vrf Cust1
3202 neighbor 203.0.113.2 activate
3203 neighbor 203.0.113.2 route-map SET-NH-IPV6 out
3205 Example #2 of PE configuration done
3206 by management system (two sessions):
3208 router bgp 100
3209 neighbor 203.0.113.2 remote-as 65000
3210 neighbor 2001::2 remote-as 65000
3211 address-family ipv4 vrf Cust1
3212 neighbor 203.0.113.2 activate
3213 address-family ipv6 vrf Cust1
3214 neighbor 2001::2 activate
3216 Example #3 of PE configuration done
3217 by management system (multisession):
3219 router bgp 100
3220 neighbor 203.0.113.2 remote-as 65000
3221 neighbor 203.0.113.2 multisession per-af
3222 address-family ipv4 vrf Cust1
3223 neighbor 203.0.113.2 activate
3224 address-family ipv6 vrf Cust1
3225 neighbor 203.0.113.2 activate
3226 neighbor 203.0.113.2 route-map SET-NH-IPV6 out
3228 6.12. Service
3230 The service defines service parameters associated with the site.
3232 6.12.1. Bandwidth
3234 The service bandwidth refers to the bandwidth requirement between PE
3235 and CE (WAN link bandwidth). The requested bandwidth is expressed as
3236 svc-input-bandwidth and svc-output-bandwidth in bits per seconds.
3237 Input/output direction is using customer site as reference: input
3238 bandwidth means download bandwidth for the site, and output bandwidth
3239 means upload bandwidth for the site.
3241 The service bandwidth is only configurable at site-network-access
3242 level.
3244 Using a different input and output bandwidth will allow service
3245 provider to know if customer allows for asymmetric bandwidth access
3246 like ADSL. It can also be used to set rate-limit in a different way
3247 upload and download on a symmetric bandwidth access.
3249 The bandwidth is a service bandwidth: expressed primarily as IP
3250 bandwidth but if the customer enables MPLS for carrier's carrier,
3251 this becomes MPLS bandwidth.
3253 6.12.2. QoS
3255 The model proposes to define QoS parameters in an abstracted way:
3257 o qos-classification-policy: define a set of ordered rules to
3258 classify customer traffic.
3260 o qos-profile: QoS scheduling profile to be applied.
3262 6.12.2.1. QoS classification
3264 QoS classification rules are handled by qos-classification-policy.
3265 The qos-classification-policy is an ordered list of rules that match
3266 a flow or application and set the appropriate target class of service
3267 (target-class-id). The user can define the match using an
3268 application reference or a more specific flow definition (based layer
3269 3 source and destination address, layer 4 ports, layer 4 protocol).
3270 When a flow definition is used, the user can use a target-sites leaf-
3271 list to identify the destination of a flow rather than using
3272 destination IP addresses. In such a case, an association between the
3273 site abstraction and the IP addresses used by this site must be done
3274 dynamically. How this association is done is out of scope of this
3275 document and an implementation may not support this criterion and
3276 should advertise a deviation in this case. A rule that does not have
3277 a match statement is considered as a match-all rule. A service
3278 provider may implement a default terminal classification rule if the
3279 customer does not provide it. It will be up to the service provider
3280 to determine its default target class. The current model defines
3281 some applications but new application identities may be added through
3282 augmentation. The exact meaning of each application identity is up
3283 to the service provider, so it will be necessary for the service
3284 provider to advise customer on usage of application matching.
3286 Where the classification is done depends on the SP implementation of
3287 the service, but classification concerns the flow coming from the
3288 customer site and entering the network.
3290 Provider network
3291 +-----------------------+
3292 192.0.2.0/24
3293 198.51.100.0/24 ---- CE --------- PE
3295 Traffic flow
3296 ---------->
3298 In the figure above, the management system should implement the
3299 classification rule:
3301 o in the ingress direction on the PE interface, if the CE is
3302 customer managed.
3304 o in the ingress direction on the CE interface connected to customer
3305 LAN, if the CE is provider managed.
3307 The figure below describes a sample service description of qos-
3308 classification for a site :
3310
3311
3312
3313
3314 1
3315
3316 192.0.2.0/24
3317 203.0.113.1/32
3318 80
3319 tcp
3320
3321 DATA2
3322
3323
3324 2
3325
3326 192.0.2.0/24
3327 203.0.113.1/32
3328 21
3329 tcp
3330
3331 DATA2
3332
3333
3334 3
3335 p2p
3336 DATA3
3337
3338
3339 4
3340 DATA1
3341
3342
3343
3344
3346 In the example above:
3348 o HTTP traffic from 192.0.2.0/24 LAN destinated to 203.0.113.1/32
3349 will be classified in DATA2.
3351 o FTP traffic from 192.0.2.0/24 LAN destinated to 203.0.113.1/32
3352 will be classified in DATA2.
3354 o Peer to peer traffic will be classified in DATA3.
3356 o All other traffic will be classified in DATA1.
3358 The order of rules is really important. The management system
3359 responsible for translating those rules in network element
3360 configuration MUST keep the same processing order in network element
3361 configuration. The order of rule is defined by the "id" leaf. The
3362 lowest "id" MUST be processed first.
3364 6.12.2.2. QoS profile
3366 User can choose between standard profile provided by the operator or
3367 custom profile. The qos-profile defines the traffic scheduling
3368 policy to be used by the service provider.
3370 Provider network
3371 +-----------------------+
3372 192.0.2.0/24
3373 198.51.100.0/24 ---- CE --------- PE
3374 \ /
3375 qos-profile
3377 In case of provider managed or co-managed connection, the provider
3378 should ensure scheduling according to the requested policy in both
3379 traffic directions (SP to customer and customer to SP). As example
3380 of implementation, a device scheduling policy may be implemented both
3381 at PE and CE side on the WAN link. In case of customer managed
3382 connection, the provider is only responsible to ensure scheduling
3383 from SP network to the customer site. As example of implementation,
3384 a device scheduling policy may be implemented only at PE side on the
3385 WAN link towards the customer.
3387 A custom qos-profile is defined as a list of class of services and
3388 associated properties. The properties are:
3390 o rate-limit: used to rate-limit the class of service. The value is
3391 expressed as a percentage of the global service bandwidth. When
3392 the qos-profile is implemented at CE side the svc-output-bandwidth
3393 is taken into account as reference. When it is implemented at PE
3394 side, the svc-input-bandwidth is used.
3396 o latency: used to define the latency constraint of the class. The
3397 latency constraint can be expressed as the lowest possible latency
3398 or a latency boundary expressed in milliseconds. How this latency
3399 constraint will be fulfilled is up to the service provider
3400 implementation: a strict priority queueing may be used on the
3401 access and in the core network, and/or a low latency routing may
3402 be created for this traffic class.
3404 o jitter: used to define the jitter constraint of the class. The
3405 jitter constraint can be expressed as the lowest possible jitter
3406 or a jitter boundary expressed in microseconds. How this jitter
3407 constraint will be fulfilled is up to the service provider
3408 implementation: a strict priority queueing may be used on the
3409 access and in the core network, and/or a jitter-aware routing may
3410 be created for this traffic class.
3412 o bandwidth: used to define a guaranteed amount of bandwidth for the
3413 class of service. It is expressed as a percentage. The
3414 guaranteed-bw-percent uses available bandwidth as a reference.
3415 When the qos-profile is implemented at CE side the svc-output-
3416 bandwidth is taken into account as reference. When it is
3417 implemented at PE side, the svc-input-bandwidth is used. By
3418 default, the bandwidth reservation is only guaranteed at the
3419 access level. The user can use the "end-to-end" leaf to request
3420 an end-to-end bandwidth reservation including the MPLS transport
3421 network.
3423 Some constraints may not be offered by a service provider, in this
3424 case a deviation should be advertised. In addition, due to the
3425 network conditions, some constraints may not be completely fulfilled
3426 by the service provider, in this case, the service provider should
3427 advise the customer about the limitations. How this communication is
3428 done is out of scope of this document.
3430 Example of service configuration using a standard qos profile:
3432
3433 1245HRTFGJGJ154654
3434
3435 100000000
3436 100000000
3437
3438
3439 PLATINUM
3440
3441
3442
3443
3444
3445 555555AAAA2344
3446
3447 2000000
3448 2000000
3449
3450
3451 GOLD
3452
3453
3454
3455
3457 Example of service configuration using a custom qos profile:
3459
3460 Site1
3461
3462 100000000
3463 100000000
3464
3465
3466
3467
3468 REAL_TIME
3469 10
3470
3471
3472
3473
3474
3475 DATA1
3476
3477 70
3478
3479
3480
3481 80
3482
3483
3484
3485
3486 DATA2
3487
3488 200
3489
3490
3491
3492 5
3493
3494
3495
3496
3497
3498
3499
3500
3501
3503 The custom qos-profile for site1 defines a REAL_TIME class with a
3504 lowest possible latency constraint. It defines also two data classes
3505 DATA1 and DATA2. The two classes express a latency boundary
3506 constraint as well as a bandwidth reservation. As the REAL_TIME
3507 class is rate-limited to 10% of the service bandwidth (10% of 100Mbps
3508 = 10Mbps). In case of congestion, the REAL_TIME traffic can go up to
3509 10Mbps (let's assume that only 5Mbps are consumed). DATA1 and DATA2
3510 will share the remaining bandwidth (95Mbps) according to their
3511 percentage. So the DATA1 class will be served with at least 76Mbps
3512 of bandwidth while the DATA2 class will be served with at least
3513 4.75Mbps. The latency boundary information of the data class may
3514 help the service provider to define a specific buffer tuning or a
3515 specific routing within the network. The maximum percentage to be
3516 used is not limited by this model but MUST be limited by the
3517 management system according to the policies authorized by the service
3518 provider.
3520 6.12.3. Multicast
3522 The multicast section defines the type of site in the customer
3523 multicast service topology: source, receiver, or both. These
3524 parameters will help management system to optimize the multicast
3525 service. User can also define the type of multicast relation with
3526 the customer: router (requires a protocol like PIM), host (IGMP or
3527 MLD), or both. Address family (IPv4 or IPv6 or both) can also be
3528 defined.
3530 6.13. Enhanced VPN features
3532 6.13.1. Carrier's Carrier
3534 In case of Carrier's Carrier ([RFC4364]), a customer may want to
3535 build MPLS service using an IPVPN to carry its traffic.
3537 LAN customer1
3538 |
3539 |
3540 CE1
3541 |
3542 | -------------
3543 (vrf_cust1)
3544 CE1_ISP1
3545 | ISP1 PoP
3546 | MPLS link
3547 | -------------
3548 |
3549 (vrf ISP1)
3550 PE1
3552 (...) Provider backbone
3554 PE2
3555 (vrf ISP1)
3556 |
3557 | ------------
3558 |
3559 | MPLS link
3560 | ISP1 PoP
3561 CE2_ISP1
3562 (vrf_cust1)
3563 |-------------
3564 |
3565 CE2
3566 |
3567 Lan customer1
3569 In the figure above, ISP1 resells IPVPN service but has no core
3570 network infrastructure between its PoPs. ISP1 uses an IPVPN as core
3571 network infrastructure (belonging to another provider) between its
3572 PoPs.
3574 In order to support CsC, the VPN service must be declared MPLS
3575 support using the "carrierscarrier" leaf set to true in vpn-service.
3576 The link between CE1_ISP1/PE1 and CE2_ISP1/PE2 must also run an MPLS
3577 signalling protocol. This configuration is done at the site level.
3579 In the proposed model, LDP or BGP can be used as the MPLS signalling
3580 protocol. In case of LDP, an IGP routing protocol MUST also be
3581 activated. In case of BGP signalling, BGP MUST also be configured as
3582 routing-protocol.
3584 In case Carrier's Carrier is enabled, the requested svc-mtu will
3585 refer to the MPLS MTU and not to the IP MTU.
3587 6.14. External ID references
3589 The service model sometimes refers to external information through
3590 identifiers. As an example, to order a cloud-access to a particular
3591 Cloud Service Provider (CSP), the model uses an identifier to refer
3592 to the targeted CSP. In case, a customer is using directly this
3593 service model as an API (through REST or NETCONF for example) to
3594 order a particular service, the service provider should provide a
3595 list of authorized identifiers. In case of cloud-access, the service
3596 provider will provide the identifiers associated of each available
3597 CSP. The same applies to other identifiers like std-qos-profile, oam
3598 profile-name, provider-profile for encryption ...
3600 How an SP provides those identifiers meaning to the customer is out
3601 of scope of this document.
3603 6.15. Defining NNIs
3605 An autonomous system is a single network or group of networks that is
3606 controlled by a common system administration group and that uses a
3607 single, clearly defined routing protocol. In some cases, VPNs need
3608 to span across different autonomous systems in different geographic
3609 areas or across different service providers. The connection between
3610 autonomous systems is established by the Service Providers and is
3611 seamless to the customer.
3613 Some examples are: Partnership between service providers (carrier,
3614 cloud ...) to extend their VPN service seamlessly, or internal
3615 administrative boundary within a single service provider (Backhaul vs
3616 Core vs Datacenter ...).
3618 NNIs (Network to Network Interfaces) have to be defined to extend the
3619 VPNs across multiple autonomous systems.
3621 [RFC4364] defines multiple flavors of VPN NNI implementations. Each
3622 implementation has different pros/cons that are outside the scope of
3623 this document. As an example: In an Inter-AS Option A, ASBR peers
3624 are connected by multiple interfaces with at least one interface
3625 which VPN spans the two autonomous systems. These ASBRs associate
3626 each interface with a VPN routing and forwarding (VRF) instance and a
3627 Border Gateway Protocol (BGP) session to signal unlabeled IP
3628 prefixes. As a result, traffic between the back-to-back VRFs is IP.
3630 In this scenario, the VPNs are isolated from each other, and because
3631 the traffic is IP, QoS mechanisms that operate on IP traffic can be
3632 applied to achieve customer Service Level Agreements (SLAs).
3634 -------- -------------- -----
3635 / \ / \ / \
3636 | Cloud | | | | |
3637 | Provider | ----NNI---- | | ---NNI---| DC |
3638 | #1 | | | | |
3639 \ / | | \ /
3640 -------- | | ----
3641 | |
3642 -------- | My network | -----------
3643 / \ | | / \
3644 | Cloud | | | | |
3645 | Provider | ----NNI---- | |---NNI---| L3VPN |
3646 | #2 | | | | Partner |
3647 \ / | | | |
3648 -------- | | | |
3649 \ / | |
3650 -------------- \ /
3651 | ----------
3652 |
3653 NNI
3654 |
3655 |
3656 -------------------
3657 / \
3658 | |
3659 | |
3660 | |
3661 | L3VPN partner |
3662 | |
3663 \ /
3664 ------------------
3666 The figure above describes a service provider network "My network"
3667 that has several NNIs. This network uses NNI to:
3669 o increase its footprint by relying on L3VPN partners.
3671 o connect its own datacenter services to the customer IPVPN.
3673 o enable customer to access to its private resources located in
3674 private cloud owned by some cloud service providers.
3676 6.15.1. Defining NNI with option A flavor
3678 AS A AS B
3679 --------------------- --------------------
3680 / \ / \
3681 | | | |
3682 | ++++++++ InterAS link ++++++++ |
3683 | + +_____________ + + |
3684 | + (VRF1)--(VPN1)----(VRF1) + |
3685 | + ASBR + + ASBR + |
3686 | + (VRF2)--(VPN2)----(VRF2) + |
3687 | + +______________+ + |
3688 | ++++++++ ++++++++ |
3689 | | | |
3690 | | | |
3691 | | | |
3692 | ++++++++ InterAS link ++++++++ |
3693 | + +_____________ + + |
3694 | + (VRF1)--(VPN1)----(VRF1) + |
3695 | + ASBR + + ASBR + |
3696 | + (VRF2)--(VPN2)----(VRF2) + |
3697 | + +______________+ + |
3698 | ++++++++ ++++++++ |
3699 | | | |
3700 | | | |
3701 \ / \ /
3702 -------------------- -------------------
3704 In option A, the two ASes are connected between each other with
3705 physical links on Autonomous System Border Routers (ASBR). There may
3706 be multiple physical connections between the ASes for a resiliency
3707 purpose. A VPN connection, physical or logical (on top of physical),
3708 is created for each VPN that needs to cross the AS boundary. A back-
3709 to-back VRF model is so created.
3711 This VPN connection can be seen as a site from a service model
3712 perspective. Let's say that AS B wants to extend some VPN connection
3713 for VPN C on AS A. Administrator of AS B can use this service model
3714 to order a site on AS A. All connection scenarios could be realized
3715 using the current model features. As an example, the figure above,
3716 where two physical connections are involved with logical connections
3717 per VPN on top, could be seen as a dualhomed subVPN scenario. And
3718 for example, administrator from AS B will be able to choose the
3719 appropriate routing protocol (e.g. ebgp) to dynamically exchange
3720 routes between ASes.
3722 This document assumes that option A NNI flavor SHOULD reuse the
3723 existing VPN site modeling.
3725 Example: a customer wants from its cloud service provider A to attach
3726 its virtual network N to an existing IPVPN (VPN1) he has from a L3VPN
3727 service provider B.
3729 CSP A L3VPN SP B
3731 ----------------- --------------------
3732 / \ / \
3733 | | | | |
3734 | VM --| ++++++++ NNI ++++++++ |---- VPN1
3735 | | + +_________+ + | Site#1
3736 | |--------(VRF1)---(VPN1)--(VRF1)+ |
3737 | | + ASBR + + ASBR + |
3738 | | + +_________+ + |
3739 | | ++++++++ ++++++++ |
3740 | VM --| | | |---- VPN1
3741 | |Virtual | | | Site#2
3742 | |Network | | |
3743 | VM --| | | |---- VPN1
3744 | | | | | Site#3
3745 \ / \ /
3746 ---------------- -------------------
3747 |
3748 |
3749 VPN1
3750 Site#4
3752 The cloud service provider or the customer may use our L3VPN service
3753 model exposed by service provider B to create the VPN connectivity.
3754 We could consider that, as the NNI is shared, the physical connection
3755 (bearer) between CSP A and SP B already exists. CSP A may request
3756 through a service model a new site creation with a single site-
3757 network-access (single homing used in the diagram). As placement
3758 constraint, CSP A may use the existing bearer reference it has from
3759 SP A to force the placement of the VPN NNI on the existing link. The
3760 XML below describes what could be the configuration request to SP B:
3762
3763 CSP_A_attachment
3764
3765 NY
3766 US
3767
3768 site-vpn-flavor-nni
3769
3770
3771 bgp
3772
3773 500
3774 ipv4
3775
3776
3777
3778
3779
3780 CSP_A_VN1
3781
3782
3783
3784 static-address
3785
3786
3787 203.0.113.1
3788 203.0.113.2
3789 30
3790
3791
3792
3793
3794 450000000
3795 450000000
3796
3797
3798 VPN1
3799 any-to-any-role
3800
3801
3802
3803
3804 customer-managed
3805
3806
3808 The case described above is different from the cloud-access container
3809 usage as the cloud-access provides a public cloud access while this
3810 example enables access to private resources located in a cloud
3811 service provider network.
3813 6.15.2. Defining NNI with option B flavor
3815 AS A AS B
3816 --------------------- --------------------
3817 / \ / \
3818 | | | |
3819 | ++++++++ InterAS link ++++++++ |
3820 | + +_____________ + + |
3821 | + + + + |
3822 | + ASBR +<---mpebgp--->+ ASBR + |
3823 | + + + + |
3824 | + +______________+ + |
3825 | ++++++++ ++++++++ |
3826 | | | |
3827 | | | |
3828 | | | |
3829 | ++++++++ InterAS link ++++++++ |
3830 | + +_____________ + + |
3831 | + + + + |
3832 | + ASBR +<---mpebgp--->+ ASBR + |
3833 | + + + + |
3834 | + +______________+ + |
3835 | ++++++++ ++++++++ |
3836 | | | |
3837 | | | |
3838 \ / \ /
3839 -------------------- -------------------
3841 In option B, the two ASes are connected between each other with
3842 physical links on Autonomous System Border Routers (ASBR). There may
3843 be multiple physical connections between the ASes for a resiliency
3844 purpose. The VPN "connection" between ASes is done by exchanging VPN
3845 routes through MP-BGP.
3847 There are multiple flavors of implementations of such NNI, for
3848 example:
3850 1. The NNI is a provider internal NNI between a backbone and a DC.
3851 There is enough trust between the domains to not filter the VPN
3852 routes. So all the VPN routes are exchanged. Route target
3853 filtering may be implemented to save some unnecessary route
3854 states.
3856 2. The NNI is used between providers that agreed to exchange VPN
3857 routes for specific route-targets only. Each provider is
3858 authorized to use the route-target values from the other
3859 provider.
3861 3. The NNI is used between providers that agreed to exchange VPN
3862 routes for specific route-targets only. Each provider has its
3863 own route-target scheme. So a customer spanning the two networks
3864 will have different route-target in each network for a particular
3865 VPN.
3867 Case 1 does not require any service modeling, as the protocol enables
3868 dynamic exchange of necessary VPN routes.
3870 Case 2 requires to maintain some route-target filtering policy on
3871 ASBRs. From a service modeling point of view, it is necessary to
3872 agree on the list of route target to authorize.
3874 In case 3, both ASes need to agree on the VPN route-target to
3875 exchange and in addition how to map a VPN route-target from AS A to
3876 the corresponding route-target in AS B (and vice-versa).
3878 Those modelings are currently out of scope of this document.
3880 Cloud SP L3VPN SP B
3881 A
3882 ----------------- --------------------
3883 / \ / \
3884 | | | | |
3885 | VM --| ++++++++ NNI ++++++++ |---- VPN1
3886 | | + +_________+ + | Site#1
3887 | |-------+ + + + |
3888 | | + ASBR +<-mpebgp->+ ASBR + |
3889 | | + +_________+ + |
3890 | | ++++++++ ++++++++ |
3891 | VM --| | | |---- VPN1
3892 | |Virtual | | | Site#2
3893 | |Network | | |
3894 | VM --| | | |---- VPN1
3895 | | | | | Site#3
3896 \ / | |
3897 ---------------- | |
3898 \ /
3899 -------------------
3900 |
3901 |
3902 VPN1
3903 Site#4
3905 The example above describes an NNI connection between the service
3906 provider network B and a cloud service provider A. Both service
3907 providers do not trust themselves and use a different route-target
3908 allocation policy. So, in term of implementation, the customer VPN
3909 has a different route-target in each network (RT A in CSP A and RT B
3910 is CSP B). In order to connect the customer virtual network in CSP A
3911 to the customer IPVPN (VPN1) in SP B network, CSP A should request SP
3912 B to open the customer VPN on the NNI (accept the appropriate RT).
3913 Who does the RT translation is up to an agreement between the two
3914 service providers: SP B may permit CSP A to request VPN (RT)
3915 translation.
3917 6.15.3. Defining NNI with option C flavor
3918 AS A AS B
3919 --------------------- --------------------
3920 / \ / \
3921 | | | |
3922 | | | |
3923 | | | |
3924 | ++++++++ Multihop ebgp++++++++ |
3925 | + + + + |
3926 | + + + + |
3927 | + RGW +<---mpebgp--->+ RGW + |
3928 | + + + + |
3929 | + + + + |
3930 | ++++++++ ++++++++ |
3931 | | | |
3932 | | | |
3933 | | | |
3934 | | | |
3935 | | | |
3936 | ++++++++ InterAS link ++++++++ |
3937 | + +_____________ + + |
3938 | + + + + |
3939 | + ASBR + + ASBR + |
3940 | + + + + |
3941 | + +______________+ + |
3942 | ++++++++ ++++++++ |
3943 | | | |
3944 | | | |
3945 | | | |
3946 | ++++++++ InterAS link ++++++++ |
3947 | + +_____________ + + |
3948 | + + + + |
3949 | + ASBR + + ASBR + |
3950 | + + + + |
3951 | + +______________+ + |
3952 | ++++++++ ++++++++ |
3953 | | | |
3954 | | | |
3955 \ / \ /
3956 -------------------- -------------------
3958 From a VPN service perspective, option C NNI is very similar to
3959 option B as an MP-BGP session is used to exchange VPN routes between
3960 the ASes. The difference is that the forwarding and control plane
3961 are on different nodes, so the MP-BGP is multihop between routing
3962 gateway (RGW) nodes.
3964 Modeling option B and C will be identical from a VPN service point of
3965 view.
3967 7. Service model usage example
3969 As explained in Section 5, this service model is intended to be
3970 instantiated at a management layer and is not intended to be used
3971 directly on network elements. The management system serves as a
3972 central point of configuration of the overall service.
3974 This section provides an example on how a management system can use
3975 this model to configure an IPVPN service on network elements.
3977 The example wants to achieve the provisionning of a VPN service for 3
3978 sites using Hub and Spoke VPN service topology. One of the sites
3979 will be dual homed and loadsharing is expected.
3981 +-------------------------------------------------------------+
3982 | Hub_Site ------ PE1 PE2 ------ Spoke_Site1 |
3983 | | +----------------------------------+
3984 | | |
3985 | | +----------------------------------+
3986 | Hub_Site ------ PE3 PE4 ------ Spoke_Site2 |
3987 +-------------------------------------------------------------+
3989 The following XML describes the overall simplified service
3990 configuration of this VPN.
3992
3993 12456487
3994 hub-spoke
3995
3997 When receiving the request for provisioning the VPN service, the
3998 management system will internally (or through communication with
3999 another OSS component) allocates VPN route-targets. In this specific
4000 case two RTs will be allocated (100:1 for Hub and 100:2 for Spoke).
4001 The output below describes the configuration of Spoke1.
4003
4004 Spoke_Site1
4005
4006 NY
4007 US
4008
4009
4010
4011 bgp
4012
4013 500
4014 ipv4
4015 ipv6
4016
4017
4018
4019
4020
4021 Spoke_Site1
4022
4023
4024
4025 20
4026
4027
4028
4029
4030 pe-diverse
4031
4032
4033 10
4034
4035
4036
4037
4038
4039
4040
4041
4042 static-address
4043
4044
4045 203.0.113.254
4046 203.0.113.2
4047 24
4048
4049
4050
4051
4052 static-address
4053
4054
4055 2001:db8::1
4056 2001:db8::2
4057 64
4058
4059
4061
4062
4063 450000000
4064 450000000
4065
4066
4067 12456487
4068 spoke-role
4069
4070
4071
4072
4073 provider-managed
4074
4075
4077 When receiving the request for provisioning Spoke1 site, the
4078 management system MUST allocate network resources for this site. It
4079 MUST first determine the target network elements to provision the
4080 access, and especially the PE router (and may be an aggregation
4081 switch). As described in Section 6.6, the management system SHOULD
4082 use the location information and SHOULD use the access-diversity
4083 constraint to find the appropriate PE. In this case, we consider
4084 Spoke1 requires PE diversity with Hub and that management system
4085 allocate PEs based on lowest distance. Based on the location
4086 information, the management system finds the available PEs in the
4087 nearest area of the customer and picks one that fits the access-
4088 diversity constraint.
4090 When the PE is chosen, the management system needs to allocate
4091 interface resources on the node. One interface is selected from the
4092 PE available pool. The management system can start provisioning the
4093 PE node by using any mean (Netconf, CLI, ...). The management system
4094 will check if a VRF is already present that fits the needs. If not,
4095 it will provision the VRF: Route distinguisher will come from
4096 internal allocation policy model, route-targets are coming from the
4097 vpn-policy configuration of the site (management system allocated
4098 some RTs for the VPN). As the site is a Spoke site (site-role), the
4099 management system knows which RT must be imported and exported. As
4100 the site is provider managed, some management route-targets may also
4101 be added (100:5000). Standard provider VPN policies MAY also be
4102 added in the configuration.
4104 Example of generated PE configuration:
4106 ip vrf Customer1
4107 export-map STD-CUSTOMER-EXPORT <---- Standard SP configuration
4108 route-distinguisher 100:3123234324
4109 route-target import 100:1
4110 route-target import 100:5000 <---- Standard SP configuration
4111 route-target export 100:2 for provider managed
4112 !
4114 When the VRF has been provisioned, the management system can start
4115 configuring the access on the PE using the allocated interface
4116 information. IP addressing is chosen by the management system. One
4117 address will be picked from an allocated subnet for the PE, another
4118 will be used for the CE configuration. Routing protocols will also
4119 be configured between PE and CE and due to provider managed model,
4120 the choice is up to service provider: BGP was chosen for the example.
4121 This choice is independant of the routing protocol chosen by
4122 customer. For the CE - LAN part, BGP will be used as requested in
4123 the service model. Peering addresses will be derived from those of
4124 the connection. As CE is provider managed, CE AS number can be
4125 automatically allocated by the management system. Some provider
4126 standard configuration templates may also be added.
4128 Example of generated PE configuration:
4130 interface Ethernet1/1/0.10
4131 encapsulation dot1q 10
4132 ip vrf forwarding Customer1
4133 ip address 198.51.100.1 255.255.255.252 <---- Comes from
4134 automated allocation
4135 ipv6 address 2001:db8::10:1/64
4136 ip access-group STD-PROTECT-IN <---- Standard SP config
4137 !
4138 router bgp 100
4139 address-family ipv4 vrf Customer1
4140 neighbor 198.51.100.2 remote-as 65000 <---- Comes from
4141 automated allocation
4142 neighbor 198.51.100.2 route-map STD in <---- Standard SP config
4143 neighbor 198.51.100.2 filter-list 10 in <---- Standard SP config
4144 !
4145 address-family ipv6 vrf Customer1
4146 neighbor 2001:db8::0A10:2 remote-as 65000 <---- Comes from
4147 automated allocation
4148 neighbor 2001:db8::0A10:2 route-map STD in <---- Standard SP config
4149 neighbor 2001:db8::0A10:2 filter-list 10 in <---- Standard SP config
4150 !
4151 ip route vrf Customer1 192.0.2.1 255.255.255.255 198.51.100.2
4152 ! Static route for provider administration of CE
4153 !
4155 As the CE router is not reachable at this stage, the management
4156 system can produce a complete CE configuration that can be uploaded
4157 to the node by manual operation before sending the CE to customer
4158 premise. The CE configuration will be built as for the PE. Based on
4159 the CE type (vendor/model) allocated to the customer and bearer
4160 information, the management system knows which interface must be
4161 configured on the CE. PE-CE link configuration is expected to be
4162 handled automatically using the service provider OSS as both
4163 resources are managed internally. CE to LAN interface parameters
4164 like IP addressing are derived from ip-connection taking into account
4165 how management system distributes addresses between PE and CE within
4166 the subnet. This will allow to produce a plug'n'play configuration
4167 for the CE.
4169 Example of generated CE configuration:
4171 interface Loopback10
4172 description "Administration"
4173 ip address 192.0.2.1 255.255.255.255
4174 !
4175 interface FastEthernet10
4176 description "WAN"
4177 ip address 198.51.100.2 255.255.255.252 <---- Comes from
4178 automated allocation
4179 ipv6 address 2001:db8::0A10:2/64
4180 !
4181 interface FastEthernet11
4182 description "LAN"
4183 ip address 203.0.113.254 255.255.255.0 <---- Comes from
4184 ip-connection
4185 ipv6 address 2001:db8::1/64
4186 !
4187 router bgp 65000
4188 address-family ipv4
4189 redistribute static route-map STATIC2BGP <---- Standard SP
4190 configuration
4191 neighbor 198.51.100.1 remote-as 100 <---- Comes from
4192 automated allocation
4193 neighbor 203.0.113.2 remote-as 500 <---- Comes from
4194 ip-connection
4195 address-family ipv6
4196 redistribute static route-map STATIC2BGP <---- Standard SP
4197 configuration
4198 neighbor 2001:db8::0A10:1 remote-as 100 <---- Comes from
4199 automated allocation
4200 neighbor 2001:db8::2 remote-as 500 <---- Comes from
4201 ip-connection
4202 !
4203 route-map STATIC2BGP permit 10
4204 match tag 10
4205 !
4207 8. Interaction with Other YANG Modules
4209 As expressed in Section 5, this service module is intended to be
4210 instantiated in management system and not directly on network
4211 elements.
4213 It will be the role of the management system to configure the network
4214 elements. The management system may be modular, so the component
4215 instantiating the service model (let's call it service component) and
4216 the component responsible for network element configuration (let's
4217 call it configuration component) may be different.
4219 L3VPN-SVC |
4220 service model |
4221 |
4222 +----------------------+
4223 | Service component | service datastore
4224 +----------------------+
4225 |
4226 |
4227 +----------------------+
4228 +----| Config component |-------+
4229 / +----------------------+ \ Network
4230 / / \ \ Configuration
4231 / / \ \ models
4232 / / \ \
4233 +++++++ ++++++++ ++++++++ +++++++
4234 + CEA + ------- + PE A + + PE B + ----- + CEB + Config
4235 +++++++ ++++++++ ++++++++ +++++++ datastore
4237 Site A Site B
4239 In the previous sections, we provided some example of translation of
4240 service provisioning request to router configuration lines as an
4241 illustration. In the NETCONF/YANG ecosystem, it will be expected
4242 NETCONF/YANG to be used between configuration component and network
4243 elements to configure the requested service on these elements.
4245 In this framework, it is expected from standardization to also work
4246 on specific configuration YANG modelization of service components on
4247 network elements. There will be a strong relation between the
4248 abstracted view provided by this service model and the detailed
4249 configuration view that will be provided by specific configuration
4250 models for network elements.
4252 Authors of this document are expecting definition of YANG models for
4253 network elements on this non exhaustive list of items:
4255 o VRF definition including VPN policy expression.
4257 o Physical interface.
4259 o IP layer (IPv4, IPv6).
4261 o QoS: classification, profiles...
4263 o Routing protocols: support of configuration of all protocols
4264 listed in the document, as well as routing policies associated
4265 with these protocols.
4267 o Multicast VPN.
4269 o Network Address Translation.
4271 o ...
4273 Example of VPN site request at service level using this model:
4275
4276 Site A
4277
4278
4279
4280
4281
4282 static-address
4283
4284
4285 203.0.113.254
4286 203.0.113.2
4287 24
4288
4289
4290
4291
4292 VPNPOL1
4293
4294
4295
4296
4297
4298 static
4299
4300
4301
4302 198.51.100.0/30
4303 203.0.113.2
4304
4305
4306
4307
4308
4309
4310 customer-managed
4312
4313
4314
4315 VPNPOL1
4316
4317 1
4318
4319 VPN1
4320 any-to-any-role
4321
4322
4323
4324
4325
4327 In the service example above, it is expected that the service
4328 component requests to the configuration component of the management
4329 system the configuration of the service elements. If we consider
4330 that service component selected a PE (PE A) as target PE for the
4331 site, the configuration component will need to push the configuration
4332 to PE A. The configuration component will use several YANG data
4333 models to define the configuration to be applied to PE A. The XML
4334 configuration of PE-A may look like this:
4336
4337
4338 eth0
4339 ianaift:ethernetCsmacd
4340
4341 Link to CEA.
4342
4343
4344
4345 203.0.113.254
4346 24
4347
4348 true
4349
4350
4351
4352
4353
4354 VRF_CustA
4355 l3vpn:vrf
4356 VRF for CustomerA
4357
4358 100:1546542343
4359
4360 100:1
4361 100:1
4362
4363
4364 eth0
4365
4366
4367
4368
4369 rt:static
4370 st0
4371
4372
4373
4374
4375 198.51.100.0/30
4376
4377
4378
4379 203.0.113.2
4380
4381
4382
4383
4384
4385
4386
4387
4388
4390 9. YANG Module
4392 file "ietf-l3vpn-svc@2016-11-04.yang"
4394 module ietf-l3vpn-svc {
4395 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
4397 prefix l3vpn-svc;
4399 import ietf-inet-types {
4400 prefix inet;
4401 }
4403 import ietf-yang-types {
4404 prefix yang;
4405 }
4406 organization
4407 "IETF L3SM Working Group";
4409 contact
4410 "WG List: <mailto:l3sm@ietf.org>
4412 Editor:
4413 L3SM WG
4415 Chairs:
4416 Adrian Farrel, Qin Wu
4417 ";
4419 description
4420 "The YANG module defines a generic service configuration
4421 model for Layer 3 VPN common across all of the vendor
4422 implementations.";
4424 revision 2016-11-03 {
4425 description
4426 "Initial document";
4427 reference
4428 "RFC XXXX";
4429 }
4431 /* Features */
4433 feature cloud-access {
4434 description
4435 "Allow VPN to connect to a Cloud Service
4436 provider.";
4437 }
4438 feature multicast {
4439 description
4440 "Enables multicast capabilities in a VPN";
4441 }
4442 feature ipv4 {
4443 description
4444 "Enables IPv4 support in a VPN";
4445 }
4446 feature ipv6 {
4447 description
4448 "Enables IPv6 support in a VPN";
4449 }
4450 feature carrierscarrier {
4451 description
4452 "Enables support of carrier's carrier";
4454 }
4455 feature extranet-vpn {
4456 description
4457 "Enables support of extranet VPNs";
4458 }
4459 feature site-diversity {
4460 description
4461 "Enables support of site diversity constraints";
4462 }
4463 feature encryption {
4464 description
4465 "Enables support of encryption";
4466 }
4467 feature qos {
4468 description
4469 "Enables support of Class of Services";
4470 }
4471 feature qos-custom {
4472 description
4473 "Enables support of custom qos profile";
4474 }
4475 feature rtg-bgp {
4476 description
4477 "Enables support of BGP routing protocol.";
4478 }
4479 feature rtg-rip {
4480 description
4481 "Enables support of RIP routing protocol.";
4482 }
4483 feature rtg-ospf {
4484 description
4485 "Enables support of OSPF routing protocol.";
4486 }
4487 feature rtg-ospf-sham-link {
4488 description
4489 "Enables support of OSPF sham-links.";
4490 }
4491 feature rtg-vrrp {
4492 description
4493 "Enables support of VRRP routing protocol.";
4494 }
4495 feature fast-reroute {
4496 description
4497 "Enables support of Fast Reroute.";
4498 }
4499 feature bfd {
4500 description
4501 "Enables support of BFD.";
4503 }
4504 feature always-on {
4505 description
4506 "Enables support for always-on access
4507 constraint.";
4508 }
4509 feature requested-type {
4510 description
4511 "Enables support for requested-type access
4512 constraint.";
4513 }
4514 feature bearer-reference {
4515 description
4516 "Enables support for bearer-reference access
4517 constraint.";
4518 }
4520 /* Typedefs */
4522 typedef svc-id {
4523 type string;
4524 description
4525 "Defining a type of service component
4526 identificators.";
4527 }
4529 typedef template-id {
4530 type string;
4531 description
4532 "Defining a type of service template
4533 identificators.";
4534 }
4536 typedef address-family {
4537 type enumeration {
4538 enum ipv4 {
4539 description
4540 "IPv4 address family";
4541 }
4542 enum ipv6 {
4543 description
4544 "IPv6 address family";
4545 }
4546 }
4547 description
4548 "Defining a type for address-family.";
4549 }
4550 /* Identities */
4552 identity site-network-access-type {
4553 description
4554 "Base identity for site-network-access type";
4555 }
4556 identity point-to-point {
4557 base site-network-access-type;
4558 description
4559 "Identity for point-to-point connection";
4560 }
4561 identity multipoint {
4562 base site-network-access-type;
4563 description
4564 "Identity for multipoint connection
4565 Example : ethernet broadcast segment";
4566 }
4568 identity placement-diversity {
4569 description
4570 "Base identity for site placement
4571 constraints";
4572 }
4573 identity bearer-diverse {
4574 base placement-diversity;
4575 description
4576 "Identity for bearer diversity.
4577 The bearers should not use common elements.";
4578 }
4579 identity pe-diverse {
4580 base placement-diversity;
4581 description
4582 "Identity for PE diversity";
4583 }
4584 identity pop-diverse {
4585 base placement-diversity;
4586 description
4587 "Identity for POP diversity";
4588 }
4589 identity linecard-diverse {
4590 base placement-diversity;
4591 description
4592 "Identity for linecard diversity";
4593 }
4594 identity same-pe {
4595 base placement-diversity;
4596 description
4597 "Identity for having sites connected
4598 on the same PE";
4599 }
4600 identity same-bearer {
4601 base placement-diversity;
4602 description
4603 "Identity for having sites connected
4604 using the same bearer";
4605 }
4607 identity customer-application {
4608 description
4609 "Base identity for customer application";
4610 }
4611 identity web {
4612 base customer-application;
4613 description
4614 "Identity for web application (e.g. HTTP,HTTPS)";
4615 }
4616 identity mail {
4617 base customer-application;
4618 description
4619 "Identity for mail applications";
4620 }
4621 identity file-transfer {
4622 base customer-application;
4623 description
4624 "Identity for file transfer applications (
4625 e.g. FTP, SFTP, ...)";
4626 }
4627 identity database {
4628 base customer-application;
4629 description
4630 "Identity for database applications";
4631 }
4632 identity social {
4633 base customer-application;
4634 description
4635 "Identity for social network applications";
4636 }
4637 identity games {
4638 base customer-application;
4639 description
4640 "Identity for gaming applications";
4641 }
4642 identity p2p {
4643 base customer-application;
4644 description
4645 "Identity for peer to peer applications";
4647 }
4648 identity network-management {
4649 base customer-application;
4650 description
4651 "Identity for management applications (e.g. telnet
4652 syslog, snmp ...)";
4653 }
4654 identity voice {
4655 base customer-application;
4656 description
4657 "Identity for voice applications";
4658 }
4659 identity video {
4660 base customer-application;
4661 description
4662 "Identity for video conference applications";
4663 }
4665 identity site-vpn-flavor {
4666 description
4667 "Base identity for the site VPN service flavor.";
4668 }
4669 identity site-vpn-flavor-single {
4670 base site-vpn-flavor;
4671 description
4672 "Base identity for the site VPN service flavor.
4673 Used when the site belongs to only one VPN.";
4674 }
4675 identity site-vpn-flavor-multi {
4676 base site-vpn-flavor;
4677 description
4678 "Base identity for the site VPN service flavor.
4679 Used when a logical connection of a site
4680 belongs to multiple VPNs.";
4681 }
4683 identity site-vpn-flavor-sub {
4684 base site-vpn-flavor;
4685 description
4686 "Base identity for the site VPN service flavor.
4687 Used when a site has multiple logical connections.
4688 Each of the connection may belong to different
4689 multiple VPNs.";
4690 }
4691 identity site-vpn-flavor-nni {
4692 base site-vpn-flavor;
4693 description
4694 "Base identity for the site VPN service flavor.
4695 Used to describe a NNI option A connection.";
4696 }
4697 identity management {
4698 description
4699 "Base identity for site management scheme.";
4700 }
4701 identity co-managed {
4702 base management;
4703 description
4704 "Base identity for comanaged site.";
4705 }
4706 identity customer-managed {
4707 base management;
4708 description
4709 "Base identity for customer managed site.";
4710 }
4711 identity provider-managed {
4712 base management;
4713 description
4714 "Base identity for provider managed site.";
4715 }
4717 identity address-allocation-type {
4718 description
4719 "Base identity for address-allocation-type
4720 for PE-CE link.";
4721 }
4722 identity provider-dhcp {
4723 base address-allocation-type;
4724 description
4725 "Provider network provides DHCP service to customer.";
4726 }
4727 identity provider-dhcp-relay {
4728 base address-allocation-type;
4729 description
4730 "Provider network provides DHCP relay service to customer.";
4731 }
4732 identity provider-dhcp-slaac {
4733 base address-allocation-type;
4734 description
4735 "Provider network provides DHCP service to customer
4736 as well as SLAAC.";
4737 }
4738 identity static-address {
4739 base address-allocation-type;
4740 description
4741 "Provider to customer addressing is static.";
4743 }
4744 identity slaac {
4745 base address-allocation-type;
4746 description
4747 "Use IPv6 SLAAC.";
4748 }
4750 identity site-role {
4751 description
4752 "Base identity for site type.";
4753 }
4754 identity any-to-any-role {
4755 base site-role;
4756 description
4757 "Site in a any to any IPVPN.";
4758 }
4759 identity spoke-role {
4760 base site-role;
4761 description
4762 "Spoke Site in a Hub & Spoke IPVPN.";
4763 }
4764 identity hub-role {
4765 base site-role;
4766 description
4767 "Hub Site in a Hub & Spoke IPVPN.";
4768 }
4770 identity vpn-topology {
4771 description
4772 "Base identity for VPN topology.";
4773 }
4774 identity any-to-any {
4775 base vpn-topology;
4776 description
4777 "Identity for any to any VPN topology.";
4778 }
4779 identity hub-spoke {
4780 base vpn-topology;
4781 description
4782 "Identity for Hub'n'Spoke VPN topology.";
4783 }
4784 identity hub-spoke-disjoint {
4785 base vpn-topology;
4786 description
4787 "Identity for Hub'n'Spoke VPN topology
4788 where Hubs cannot talk between each other.";
4790 }
4792 identity multicast-tree-type {
4793 description
4794 "Base identity for multicast tree type.";
4795 }
4797 identity ssm-tree-type {
4798 base multicast-tree-type;
4799 description
4800 "Identity for SSM tree type.";
4801 }
4802 identity asm-tree-type {
4803 base multicast-tree-type;
4804 description
4805 "Identity for ASM tree type.";
4806 }
4807 identity bidir-tree-type {
4808 base multicast-tree-type;
4809 description
4810 "Identity for BiDir tree type.";
4811 }
4813 identity multicast-rp-discovery-type {
4814 description
4815 "Base identity for rp discovery type.";
4816 }
4817 identity auto-rp {
4818 base multicast-rp-discovery-type;
4819 description
4820 "Base identity for auto-rp discovery type.";
4821 }
4822 identity static-rp {
4823 base multicast-rp-discovery-type;
4824 description
4825 "Base identity for static type.";
4826 }
4827 identity bsr-rp {
4828 base multicast-rp-discovery-type;
4829 description
4830 "Base identity for BDR discovery type.";
4831 }
4833 identity routing-protocol-type {
4834 description
4835 "Base identity for routing-protocol type.";
4836 }
4837 identity ospf {
4838 base routing-protocol-type;
4839 description
4840 "Identity for OSPF protocol type.";
4841 }
4843 identity bgp {
4844 base routing-protocol-type;
4845 description
4846 "Identity for BGP protocol type.";
4847 }
4849 identity static {
4850 base routing-protocol-type;
4851 description
4852 "Identity for static routing protocol type.";
4853 }
4855 identity rip {
4856 base routing-protocol-type;
4857 description
4858 "Identity for RIP protocol type.";
4859 }
4861 identity vrrp {
4862 base routing-protocol-type;
4863 description
4864 "Identity for VRRP protocol type.
4865 This is to be used when LAn are directly connected
4866 to provider Edge routers.";
4867 }
4869 identity direct {
4870 base routing-protocol-type;
4871 description
4872 "Identity for direct protocol type.
4873 .";
4874 }
4876 identity protocol-type {
4877 description
4878 "Base identity for protocol field type.";
4879 }
4881 identity tcp {
4882 base protocol-type;
4883 description
4884 "TCP protocol type.";
4886 }
4887 identity udp {
4888 base protocol-type;
4889 description
4890 "UDP protocol type.";
4891 }
4892 identity icmp {
4893 base protocol-type;
4894 description
4895 "icmp protocol type.";
4896 }
4897 identity icmp6 {
4898 base protocol-type;
4899 description
4900 "icmp v6 protocol type.";
4901 }
4902 identity gre {
4903 base protocol-type;
4904 description
4905 "GRE protocol type.";
4906 }
4907 identity ipip {
4908 base protocol-type;
4909 description
4910 "IPinIP protocol type.";
4911 }
4912 identity hop-by-hop {
4913 base protocol-type;
4914 description
4915 "Hop by Hop IPv6 header type.";
4916 }
4917 identity routing {
4918 base protocol-type;
4919 description
4920 "Routing IPv6 header type.";
4921 }
4922 identity esp {
4923 base protocol-type;
4924 description
4925 "ESP header type.";
4926 }
4927 identity ah {
4928 base protocol-type;
4929 description
4930 "AH header type.";
4931 }
4932 /* Groupings */
4934 grouping vpn-service-cloud-access {
4935 container cloud-accesses {
4936 if-feature cloud-access;
4937 list cloud-access {
4939 key cloud-identifier;
4941 leaf cloud-identifier {
4942 type string;
4943 description
4944 "Identification of cloud service. Local
4945 admin meaning.";
4946 }
4947 choice list-flavor {
4948 case permit-any {
4949 leaf permit-any {
4950 type empty;
4951 description
4952 "Allow all sites.";
4953 }
4954 }
4955 case deny-any-except {
4956 leaf-list permit-site {
4957 type leafref {
4958 path "/l3vpn-svc/sites/site/site-id";
4959 }
4960 description
4961 "Site ID to be authorized.";
4962 }
4963 }
4964 case permit-any-except {
4965 leaf-list deny-site {
4966 type leafref {
4967 path "/l3vpn-svc/sites/site/site-id";
4968 }
4969 description
4970 "Site ID to be denied.";
4971 }
4972 }
4973 description
4974 "Choice for cloud access policy.";
4975 }
4976 container authorized-sites {
4977 list authorized-site {
4978 key site-id;
4980 leaf site-id {
4981 type leafref {
4982 path "/l3vpn-svc/sites/site/site-id";
4983 }
4984 description
4985 "Site ID.";
4986 }
4987 description
4988 "List of authorized sites.";
4989 }
4990 description
4991 "Configuration of authorized sites";
4992 }
4993 container denied-sites {
4994 list denied-site {
4995 key site-id;
4997 leaf site-id {
4998 type leafref {
4999 path "/l3vpn-svc/sites/site/site-id";
5000 }
5001 description
5002 "Site ID.";
5003 }
5004 description
5005 "List of denied sites.";
5006 }
5007 description
5008 "Configuration of denied sites";
5009 }
5010 container address-translation {
5011 container nat44 {
5012 leaf enabled {
5013 type boolean;
5014 default false;
5015 description
5016 "Control if
5017 address translation is required or not.";
5018 }
5019 leaf nat44-customer-address {
5020 type inet:ipv4-address;
5021 must "../enabled = 'true'" {
5022 description
5023 "Applicable only if
5024 address translation is enabled.";
5025 }
5026 description
5027 "Address to be used for translation.
5028 This is to be used in case customer is providing
5029 the address.";
5030 }
5031 description
5032 "IPv4 to IPv4 translation.";
5033 }
5034 description
5035 "Container for NAT";
5036 }
5037 description
5038 "Cloud access configuration.";
5039 }
5040 description
5041 "Container for cloud access configurations";
5042 }
5043 description
5044 "grouping for vpn cloud definition";
5045 }
5047 grouping multicast-rp-group-cfg {
5048 choice group-format {
5049 case startend {
5050 leaf group-start {
5051 type inet:ip-address;
5052 description
5053 "First group address.";
5054 }
5055 leaf group-end {
5056 type inet:ip-address;
5057 description
5058 "Last group address.";
5059 }
5060 }
5061 case singleaddress {
5062 leaf group-address {
5063 type inet:ip-address;
5064 description
5065 "Group address";
5066 }
5067 }
5068 description
5069 "Choice for group format.";
5070 }
5071 description
5072 "Definition of groups for
5073 RP to group mapping.";
5074 }
5076 grouping vpn-service-multicast {
5077 container multicast {
5078 if-feature multicast;
5079 leaf enabled {
5080 type boolean;
5081 default false;
5082 description
5083 "Enable multicast.";
5084 }
5085 container customer-tree-flavors {
5086 leaf-list tree-flavor {
5087 type identityref {
5088 base multicast-tree-type;
5089 }
5090 description
5091 "Type of tree to be used.";
5092 }
5093 description
5094 "Type of trees used by customer.";
5095 }
5096 container rp {
5097 container rp-group-mappings {
5098 list rp-group-mapping {
5099 key "id";
5101 leaf id {
5102 type uint16;
5103 description
5104 "Unique identifier for the mapping.";
5105 }
5106 container provider-managed {
5107 leaf enabled {
5108 type boolean;
5109 default false;
5110 description
5111 "Set to true, if the RP must be a
5112 provider
5113 managed node.
5114 Set to false, if it is a customer
5115 managed node.";
5116 }
5117 leaf rp-redundancy {
5118 when "../enabled = 'true'" {
5119 description
5120 "Relevant when RP
5121 is provider managed.";
5122 }
5123 type boolean;
5124 default false;
5125 description
5126 "If true, redundancy
5127 mechanism for RP is required.";
5128 }
5129 leaf optimal-traffic-delivery {
5130 when "../enabled = 'true'" {
5131 description
5132 "Relevant when RP
5133 is provider managed.";
5134 }
5135 type boolean;
5136 default false;
5137 description
5138 "If true, SP must ensure
5139 that traffic uses an optimal path.";
5140 }
5141 description
5142 "Parameters for provider managed RP.";
5143 }
5145 leaf rp-address {
5146 when "../provider-managed/enabled = 'false'" {
5147 description
5148 "Relevant when RP
5149 is provider managed.";
5150 }
5151 type inet:ip-address;
5152 description
5153 "Defines the address of the
5154 RendezvousPoint.
5155 Used if RP is customer managed.";
5156 }
5158 container groups {
5159 list group {
5160 key id;
5162 leaf id {
5163 type uint16;
5164 description
5165 "Identifier for the group.";
5166 }
5167 uses multicast-rp-group-cfg;
5168 description
5169 "List of groups.";
5170 }
5171 description
5172 "Multicast groups associated with RP.";
5173 }
5175 description
5176 "List of RP to group mappings.";
5177 }
5178 description
5179 "RP to group mappings.";
5180 }
5181 container rp-discovery {
5182 leaf rp-discovery-type {
5183 type identityref {
5184 base multicast-rp-discovery-type;
5185 }
5186 default static-rp;
5187 description
5188 "Type of RP discovery used.";
5189 }
5190 container bsr-candidates {
5191 when "../rp-discovery-type = 'bsr-rp'" {
5192 description
5193 "Only applicable if discovery type
5194 is BSR-RP";
5195 }
5196 leaf-list bsr-candidate-address {
5197 type inet:ip-address;
5198 description
5199 "Address of BSR candidate";
5200 }
5201 description
5202 "Customer BSR candidates address";
5203 }
5204 description
5205 "RP discovery parameters";
5206 }
5208 description
5209 "RendezvousPoint parameters.";
5210 }
5211 description
5212 "Multicast global parameters for the VPN service.";
5213 }
5214 description
5215 "grouping for multicast vpn definition";
5217 }
5219 grouping vpn-service-mpls {
5220 leaf carrierscarrier {
5221 if-feature carrierscarrier;
5222 type boolean;
5223 default false;
5224 description
5225 "The VPN is using Carrier's Carrier,
5226 and so MPLS is required.";
5227 }
5228 description
5229 "grouping for mpls CsC definition";
5230 }
5232 grouping customer-location-info {
5233 container locations {
5234 list location {
5235 key location-id;
5237 leaf location-id {
5238 type svc-id;
5239 description
5240 "Identifier for a particular location";
5241 }
5242 leaf address {
5243 type string;
5244 description
5245 "Address (number and street)
5246 of the site.";
5248 }
5249 leaf postal-code {
5250 type string;
5251 description
5252 "Postal code of the site.";
5253 }
5254 leaf state {
5255 type string;
5256 description
5257 "State of the site.
5258 This leaf can also be used
5259 to describe a region
5260 for country who does not have
5261 states.
5262 ";
5263 }
5264 leaf city {
5265 type string;
5266 description
5267 "City of the site.";
5268 }
5269 leaf country-code {
5270 type string {
5271 pattern '[A-Z]{2}';
5272 }
5273 description
5274 "Country of the site.
5275 Expressed as ISO
5276 ALPHA-2 code.";
5277 }
5278 description
5279 "Location of the site.";
5280 }
5281 description
5282 "List of locations for the site";
5283 }
5284 description
5285 "This grouping defines customer location
5286 parameters";
5287 }
5289 grouping site-group {
5290 container groups {
5291 list group {
5292 key group-id;
5294 leaf group-id {
5295 type string;
5296 description
5297 "Group-id the site
5298 is belonging to";
5299 }
5300 description
5301 "List of group-id";
5302 }
5303 description
5304 "Groups the site or site-network-access
5305 is belonging to.";
5306 }
5307 description
5308 "Grouping definition to assign
5309 group-ids to site or site-network-access";
5310 }
5311 grouping site-diversity {
5312 container site-diversity {
5313 if-feature site-diversity;
5315 uses site-group;
5317 description
5318 "Diversity constraint type.
5319 Group values defined here will be inherited
5320 to all site-network-accesses.";
5321 }
5322 description
5323 "This grouping defines site diversity
5324 parameters";
5325 }
5326 grouping access-diversity {
5327 container access-diversity {
5328 if-feature site-diversity;
5329 uses site-group;
5331 container constraints {
5332 list constraint {
5333 key constraint-type;
5335 leaf constraint-type {
5336 type identityref {
5337 base placement-diversity;
5338 }
5339 description
5340 "Diversity constraint type.";
5341 }
5342 container target {
5343 choice target-flavor {
5344 case id {
5345 list group {
5346 key group-id;
5348 leaf group-id {
5349 type string;
5350 description
5351 "The constraint will apply
5352 against this particular
5353 group-id";
5354 }
5355 description
5356 "List of groups";
5357 }
5358 }
5359 case all-accesses {
5360 leaf all-other-accesses {
5361 type empty;
5362 description
5363 "The constraint will apply
5364 against all other site network
5365 access
5366 of this site";
5367 }
5368 }
5369 case all-groups {
5370 leaf all-other-groups {
5371 type empty;
5372 description
5373 "The constraint will apply
5374 against all other groups the
5375 customer
5376 is managing";
5377 }
5378 }
5379 description
5380 "Choice for the group definition";
5381 }
5382 description
5383 "The constraint will apply against
5384 this list of groups";
5385 }
5386 description
5387 "List of constraints";
5388 }
5389 description
5390 "Constraints for placing this site
5391 network access";
5392 }
5394 description
5395 "Diversity parameters.";
5396 }
5397 description
5398 "This grouping defines access diversity
5399 parameters";
5400 }
5402 grouping operational-requirements {
5403 leaf requested-site-start {
5404 type yang:date-and-time;
5405 description
5406 "Optional leaf indicating requested date
5407 and time
5408 when the service at a particular site is
5409 expected
5410 to start";
5411 }
5413 leaf requested-site-stop {
5414 type yang:date-and-time;
5415 description
5416 "Optional leaf indicating requested date
5417 and time
5418 when the service at a particular site is
5419 expected
5420 to stop";
5421 }
5422 description
5423 "This grouping defines some operational parameters
5424 parameters";
5425 }
5426 grouping operational-requirements-ops {
5427 leaf actual-site-start {
5428 type yang:date-and-time;
5429 config false;
5430 description
5431 "Optional leaf indicating actual date
5432 and time
5433 when the service at a particular site
5434 actually
5435 started";
5436 }
5437 leaf actual-site-stop {
5438 type yang:date-and-time;
5439 config false;
5440 description
5441 "Optional leaf indicating actual date
5442 and time
5443 when the service at a particular site
5444 actually
5445 stopped";
5446 }
5447 description
5448 "This grouping defines some operational parameters
5449 parameters";
5450 }
5452 grouping flow-definition {
5453 container match-flow {
5454 leaf dscp {
5455 type inet:dscp;
5456 description
5457 "DSCP value.";
5458 }
5459 leaf dot1p {
5460 type uint8 {
5461 range "0 .. 7";
5462 }
5463 description
5464 "802.1p matching.";
5465 }
5466 leaf ipv4-src-prefix {
5467 type inet:ipv4-prefix;
5468 description
5469 "Match on IPv4 src address.";
5470 }
5471 leaf ipv6-src-prefix {
5472 type inet:ipv6-prefix;
5473 description
5474 "Match on IPv6 src address.";
5475 }
5476 leaf ipv4-dst-prefix {
5477 type inet:ipv4-prefix;
5478 description
5479 "Match on IPv4 dst address.";
5480 }
5481 leaf ipv6-dst-prefix {
5482 type inet:ipv6-prefix;
5483 description
5484 "Match on IPv6 dst address.";
5485 }
5486 leaf l4-src-port {
5487 type inet:port-number;
5488 description
5489 "Match on layer 4 src port.";
5490 }
5491 leaf-list target-sites {
5492 type svc-id;
5493 description
5494 "Identify a site as traffic destination.";
5495 }
5496 container l4-src-port-range {
5497 leaf lower-port {
5498 type inet:port-number;
5499 description
5500 "Lower boundary for port.";
5501 }
5502 leaf upper-port {
5503 type inet:port-number;
5504 must ". >= ../lower-port" {
5505 description
5506 "Upper boundary must be higher
5507 than lower boundary";
5508 }
5509 description
5510 "Upper boundary for port.";
5511 }
5512 description
5513 "Match on layer 4 src port range.";
5514 }
5515 leaf l4-dst-port {
5516 type inet:port-number;
5517 description
5518 "Match on layer 4 dst port.";
5519 }
5520 container l4-dst-port-range {
5521 leaf lower-port {
5522 type inet:port-number;
5523 description
5524 "Lower boundary for port.";
5525 }
5526 leaf upper-port {
5527 type inet:port-number;
5528 must ". >= ../lower-port" {
5529 description
5530 "Upper boundary must be higher
5531 than lower boundary";
5532 }
5533 description
5534 "Upper boundary for port.";
5535 }
5536 description
5537 "Match on layer 4 dst port range.";
5538 }
5539 leaf protocol-field {
5540 type union {
5541 type uint8;
5542 type identityref {
5543 base protocol-type;
5544 }
5545 }
5546 description
5547 "Match on IPv4 protocol or
5548 Ipv6 Next Header
5549 field.";
5550 }
5551 description
5552 "Describe flow matching
5553 criterions.";
5554 }
5555 description
5556 "Flow definition based on criteria.";
5557 }
5558 grouping site-service-basic {
5559 leaf svc-input-bandwidth {
5560 type uint32;
5561 units bps;
5562 description
5563 "From the PE perspective, the service input
5564 bandwidth of the connection.";
5565 }
5566 leaf svc-output-bandwidth {
5567 type uint32;
5568 units bps;
5569 description
5570 "From the PE perspective, the service output
5571 bandwidth of the connection.";
5572 }
5573 leaf svc-mtu {
5574 type uint16;
5575 units bytes;
5576 description
5577 "MTU at service level.
5578 If the service is IP,
5579 it refers to the IP MTU.";
5580 }
5581 description
5582 "Defines basic service parameters for a site.";
5583 }
5584 grouping site-protection {
5585 container traffic-protection {
5586 if-feature fast-reroute;
5587 leaf enabled {
5588 type boolean;
5589 default false;
5590 description
5591 "Enables
5592 traffic protection of access link.";
5593 }
5594 description
5595 "Fast reroute service parameters
5596 for the site.";
5597 }
5598 description
5599 "Defines protection service parameters for a site.";
5600 }
5601 grouping site-service-mpls {
5602 container carrierscarrier {
5603 if-feature carrierscarrier;
5604 leaf signalling-type {
5605 type enumeration {
5606 enum "ldp" {
5607 description
5608 "Use LDP as signalling
5609 protocol between PE and CE.";
5610 }
5611 enum "bgp" {
5612 description
5613 "Use BGP 3107 as signalling
5614 protocol between PE and CE.
5615 In this case, bgp must be also
5616 configured
5617 as routing-protocol.
5618 ";
5619 }
5620 }
5621 description
5622 "MPLS signalling type.";
5623 }
5624 description
5625 "This container is used when customer provides
5626 MPLS based services.
5627 This is used in case of Carrier's
5628 Carrier.";
5629 }
5630 description
5631 "Defines MPLS service parameters for a site.";
5632 }
5633 grouping site-service-qos-profile {
5634 container qos {
5635 if-feature qos;
5636 container qos-classification-policy {
5637 list rule {
5638 key id;
5639 ordered-by user;
5641 leaf id {
5642 type uint16;
5643 description
5644 "ID of the rule.";
5645 }
5646 choice match-type {
5647 case match-flow {
5648 uses flow-definition;
5649 }
5650 case match-application {
5651 leaf match-application {
5652 type identityref {
5653 base customer-application;
5654 }
5655 description
5656 "Defines the application
5657 to match.";
5658 }
5659 }
5660 description
5661 "Choice for classification";
5662 }
5664 leaf target-class-id {
5665 type string;
5666 description
5667 "Identification of the
5668 class of service.
5669 This identifier is internal to
5670 the administration.";
5671 }
5673 description
5674 "List of marking rules.";
5675 }
5676 description
5677 "Need to express marking rules ...";
5678 }
5679 container qos-profile {
5681 choice qos-profile {
5682 description
5683 "Choice for QoS profile.
5684 Can be standard profile or custom.";
5685 case standard {
5686 leaf profile {
5687 type string;
5688 description
5689 "QoS profile to be used";
5690 }
5691 }
5692 case custom {
5693 container classes {
5694 if-feature qos-custom;
5695 list class {
5696 key class-id;
5698 leaf class-id {
5699 type string;
5700 description
5701 "Identification of the
5702 class of service.
5703 This identifier is internal to
5704 the administration.";
5705 }
5706 leaf rate-limit {
5707 type uint8;
5708 units percent;
5709 description
5710 "To be used if class must
5711 be rate
5712 limited. Expressed as
5713 percentage of the svc-bw.";
5714 }
5715 container latency {
5716 choice flavor {
5717 case lowest {
5718 leaf use-lowest-latency {
5719 type empty;
5720 description
5721 "The traffic class should use
5722 the lowest latency path";
5723 }
5724 }
5725 case boundary {
5726 leaf latency-boundary {
5727 type uint16;
5728 units msec;
5729 description
5730 "The traffic class should use
5731 a path with a defined maximum
5732 latency.";
5733 }
5734 }
5735 description
5736 "Latency constraint on the traffic
5737 class";
5738 }
5739 description
5740 "Latency constraint on the traffic
5741 class";
5743 }
5744 container jitter {
5745 choice flavor {
5746 case lowest {
5747 leaf use-lowest-jitter {
5748 type empty;
5749 description
5750 "The traffic class should use
5751 the lowest jitter path";
5752 }
5753 }
5754 case boundary {
5755 leaf latency-boundary {
5756 type uint32;
5757 units usec;
5758 description
5759 "The traffic class should use
5760 a path with a defined maximum
5761 jitter.";
5762 }
5763 }
5764 description
5765 "Jitter constraint on the traffic
5766 class";
5767 }
5768 description
5769 "Jitter constraint on the traffic
5770 class";
5771 }
5772 container bandwidth {
5773 leaf guaranteed-bw-percent {
5774 type uint8;
5775 units percent;
5776 description
5777 "To be used to define the
5778 guaranteed
5779 BW in percent of the svc-bw
5780 available.";
5781 }
5782 leaf end-to-end {
5783 type empty;
5784 description
5785 "Used if the bandwidth reservation
5786 must be done on the MPLS network too";
5787 }
5788 description
5789 "Bandwidth constraint on the traffic
5790 class";
5792 }
5793 description
5794 "List of class of services.";
5795 }
5796 description
5797 "Container for
5798 list of class of services.";
5799 }
5801 }
5803 }
5804 description
5805 "Qos profile configuration.";
5806 }
5807 description
5808 "QoS configuration.";
5809 }
5810 description
5811 "This grouping defines QoS parameters
5812 for a site";
5814 }
5816 grouping site-security-authentication {
5817 container authentication {
5818 description
5819 "Authentication parameters";
5820 }
5821 description
5822 "This grouping defines authentication
5823 parameters
5824 for a site";
5826 }
5827 grouping site-security-encryption {
5828 container encryption {
5829 if-feature encryption;
5830 leaf enabled {
5831 type boolean;
5832 default false;
5833 description
5834 "If true, access encryption is required.";
5835 }
5836 leaf layer {
5837 type enumeration {
5838 enum layer2 {
5839 description
5840 "Encryption will occur at layer 2.";
5841 }
5842 enum layer3 {
5843 description
5844 "Encryption will occur at layer 3.
5845 IPSec may be used as example.";
5846 }
5847 }
5848 mandatory true;
5849 description
5850 "Layer on which encryption is applied.";
5851 }
5852 container encryption-profile {
5853 choice profile {
5854 case provider-profile {
5855 leaf profile-name {
5856 type string;
5857 description
5858 "Name of the SP profile
5859 to be applied.";
5860 }
5861 }
5862 case customer-profile {
5863 leaf algorithm {
5864 type string;
5865 description
5866 "Encryption algorithm to
5867 be used.";
5868 }
5869 choice key-type {
5870 case psk {
5871 leaf preshared-key {
5872 type string;
5873 description
5874 "Key coming from
5875 customer.";
5876 }
5877 }
5878 case pki {
5880 }
5881 description
5882 "Type of keys to be used.";
5883 }
5884 }
5885 description
5886 "Choice of profile.";
5887 }
5888 description
5889 "Profile of encryption to be applied.";
5890 }
5891 description
5892 "Encryption parameters.";
5893 }
5894 description
5895 "This grouping defines encryption parameters
5896 for a site";
5897 }
5899 grouping site-attachment-bearer {
5900 container bearer {
5901 container requested-type {
5902 if-feature requested-type;
5903 leaf requested-type {
5904 type string;
5905 description
5906 "Type of requested bearer Ethernet, DSL,
5907 Wireless ...
5908 Operator specific.";
5909 }
5910 leaf strict {
5911 type boolean;
5912 default false;
5913 description
5914 "define if the requested-type is a preference
5915 or a strict requirement.";
5916 }
5917 description
5918 "Container for requested type.";
5919 }
5920 leaf always-on {
5921 if-feature always-on;
5922 type boolean;
5923 default true;
5924 description
5925 "Request for an always on access type.
5926 This means no Dial access type for
5927 example.";
5928 }
5929 leaf bearer-reference {
5930 if-feature bearer-reference;
5931 type string;
5932 description
5933 "This is an internal reference for the
5934 service provider.
5936 Used ";
5937 }
5938 description
5939 "Bearer specific parameters.
5940 To be augmented.";
5941 }
5942 description
5943 "Defines physical properties of
5944 a site attachment.";
5945 }
5947 grouping site-routing {
5948 container routing-protocols {
5949 list routing-protocol {
5950 key type;
5952 leaf type {
5953 type identityref {
5954 base routing-protocol-type;
5955 }
5956 description
5957 "Type of routing protocol.";
5958 }
5960 container ospf {
5961 when "../type = 'ospf'" {
5962 description
5963 "Only applies
5964 when protocol is OSPF.";
5965 }
5966 if-feature rtg-ospf;
5967 leaf-list address-family {
5968 type address-family;
5970 description
5971 "Address family to be activated.";
5972 }
5973 leaf area-address {
5974 type yang:dotted-quad;
5975 description
5976 "Area address.";
5977 }
5978 leaf metric {
5979 type uint16;
5980 description
5981 "Metric of PE-CE link.";
5982 }
5983 container sham-links {
5984 if-feature rtg-ospf-sham-link;
5985 list sham-link {
5986 key target-site;
5988 leaf target-site {
5989 type svc-id;
5990 description
5991 "Target site for the sham link
5992 connection.
5993 The site is referred through it's ID.";
5994 }
5995 leaf metric {
5996 type uint16;
5997 description
5998 "Metric of the sham link.";
5999 }
6000 description
6001 "Creates a shamlink with another
6002 site";
6003 }
6004 description
6005 "List of Sham links";
6006 }
6007 description
6008 "OSPF specific configuration.";
6009 }
6011 container bgp {
6013 when "../type = 'bgp'" {
6014 description
6015 "Only applies when
6016 protocol is BGP.";
6017 }
6018 if-feature rtg-bgp;
6019 leaf autonomous-system {
6020 type uint32;
6021 description
6022 "AS number.";
6023 }
6024 leaf-list address-family {
6025 type address-family;
6027 description
6028 "Address family to be activated.";
6029 }
6030 description
6031 "BGP specific configuration.";
6032 }
6033 container static {
6034 when "../type = 'static'" {
6035 description
6036 "Only applies when protocol
6037 is static.";
6038 }
6040 container cascaded-lan-prefixes {
6041 list ipv4-lan-prefixes {
6042 if-feature ipv4;
6043 key "lan next-hop";
6045 leaf lan {
6046 type inet:ipv4-prefix;
6047 description
6048 "Lan prefixes.";
6049 }
6050 leaf lan-tag {
6051 type string;
6052 description
6053 "Internal tag to be used in vpn
6054 policies.";
6055 }
6056 leaf next-hop {
6057 type inet:ipv4-address;
6058 description
6059 "Nexthop address to use at customer
6060 side.";
6061 }
6062 description "
6063 List of LAN prefixes for
6064 the site.
6065 ";
6066 }
6067 list ipv6-lan-prefixes {
6068 if-feature ipv6;
6069 key "lan next-hop";
6071 leaf lan {
6072 type inet:ipv6-prefix;
6073 description
6074 "Lan prefixes.";
6075 }
6076 leaf lan-tag {
6077 type string;
6078 description
6079 "Internal tag to be used
6080 in vpn policies.";
6081 }
6082 leaf next-hop {
6083 type inet:ipv6-address;
6084 description
6085 "Nexthop address to use at
6086 customer side.";
6087 }
6088 description "
6089 List of LAN prefixes for the site.
6090 ";
6091 }
6092 description
6093 "LAN prefixes from the customer.";
6094 }
6095 description
6096 "Static routing
6097 specific configuration.";
6098 }
6099 container rip {
6101 when "../type = 'rip'" {
6102 description
6103 "Only applies when
6104 protocol is RIP.";
6105 }
6106 if-feature rtg-rip;
6107 leaf-list address-family {
6108 type address-family;
6110 description
6111 "Address family to be
6112 activated.";
6113 }
6115 description
6116 "RIP routing specific
6117 configuration.";
6118 }
6120 container vrrp {
6122 when "../type = 'vrrp'" {
6123 description
6124 "Only applies when
6125 protocol is VRRP.";
6127 }
6128 if-feature rtg-vrrp;
6129 leaf-list address-family {
6130 type address-family;
6132 description
6133 "Address family to be activated.";
6134 }
6135 description
6136 "VRRP routing specific configuration.";
6137 }
6139 description
6140 "List of routing protocols used
6141 on the site.
6142 Need to be augmented.";
6143 }
6144 description
6145 "Defines routing protocols.";
6146 }
6147 description
6148 "Grouping for routing protocols.";
6149 }
6151 grouping site-attachment-ip-connection {
6152 container ip-connection {
6153 container ipv4 {
6154 if-feature ipv4;
6155 leaf address-allocation-type {
6156 type identityref {
6157 base address-allocation-type;
6158 }
6159 default "static-address";
6160 description
6161 "Defines how addresses are allocated.
6162 ";
6163 }
6165 leaf number-of-dynamic-address {
6166 when
6167 "../address-allocation-type = 'provider-dhcp'"
6168 {
6169 description
6170 "Only applies when
6171 addresses are dhcp allocated";
6172 }
6173 type uint8;
6174 default 1;
6175 description
6176 "Describes the number of IP addresses the
6177 customer requires";
6178 }
6179 container dhcp-relay {
6180 when
6181 "../address-allocation-type = 'provider-dhcp-relay'"
6182 {
6183 description
6184 "Only applies when
6185 provider is required to implementations
6186 DHCP relay function";
6187 }
6188 container customer-dhcp-servers {
6189 leaf-list server-ip-address {
6190 type inet:ipv4-address;
6191 description
6192 "IP address of customer DHCP server";
6193 }
6194 description
6195 "Container for list of customer DHCP server";
6196 }
6197 description
6198 "DHCP relay provided by operator.";
6199 }
6200 container addresses {
6201 when
6202 "../address-allocation-type = 'static-address'" {
6203 description
6204 "Only applies when
6205 protocol allocation type is static";
6206 }
6207 leaf provider-address {
6208 type inet:ipv4-address;
6209 description
6210 "Provider side address.";
6211 }
6212 leaf customer-address {
6213 type inet:ipv4-address;
6214 description
6215 "Customer side address.";
6216 }
6217 leaf mask {
6218 type uint8 {
6219 range "0..31";
6220 }
6221 description
6222 "Subnet mask expressed
6223 in bits";
6224 }
6225 description
6226 "Describes IP addresses used";
6227 }
6229 description
6230 "IPv4 specific parameters";
6232 }
6233 container ipv6 {
6234 if-feature ipv6;
6235 leaf address-allocation-type {
6236 type identityref {
6237 base address-allocation-type;
6238 }
6239 default "static-address";
6240 description
6241 "Defines how addresses are allocated.
6242 ";
6243 }
6244 leaf number-of-dynamic-address {
6245 when
6246 "../address-allocation-type = 'provider-dhcp' "+
6247 "or ../address-allocation-type "+
6248 "= 'provider-dhcp-slaac'" {
6249 description
6250 "Only applies when
6251 addresses are dhcp allocated";
6252 }
6253 type uint8;
6254 default 1;
6255 description
6256 "Describes the number of IP addresses the
6257 customer requires";
6258 }
6259 container dhcp-relay {
6260 when
6261 "../address-allocation-type = 'provider-dhcp-relay'"
6262 {
6263 description
6264 "Only applies when
6265 provider is required to implementations
6266 DHCP relay function";
6267 }
6268 container customer-dhcp-servers {
6269 leaf-list server-ip-address {
6270 type inet:ipv6-address;
6271 description
6272 "IP address of customer DHCP server";
6273 }
6274 description
6275 "Container for list of customer DHCP server";
6276 }
6277 description
6278 "DHCP relay provided by operator.";
6279 }
6280 container addresses {
6281 when
6282 "../address-allocation-type = 'static-address'" {
6283 description
6284 "Only applies when
6285 protocol allocation type is static";
6286 }
6287 leaf provider-address {
6288 type inet:ipv6-address;
6289 description
6290 "Provider side address.";
6291 }
6292 leaf customer-address {
6293 type inet:ipv6-address;
6294 description
6295 "Customer side address.";
6296 }
6297 leaf mask {
6298 type uint8 {
6299 range "0..127";
6300 }
6301 description
6302 "Subnet mask expressed
6303 in bits";
6304 }
6305 description
6306 "Describes IP addresses used";
6307 }
6309 description
6310 "IPv6 specific parameters";
6312 }
6313 container oam {
6314 container bfd {
6315 if-feature bfd;
6316 leaf enabled {
6317 type boolean;
6318 default false;
6319 description
6320 "BFD activation";
6321 }
6323 choice holdtime {
6324 case profile {
6325 leaf profile-name {
6326 type string;
6327 description
6328 "Service provider well
6329 known profile.";
6330 }
6331 description
6332 "Service provider well
6333 known profile.";
6334 }
6335 case fixed {
6336 leaf fixed-value {
6337 type uint32;
6338 units msec;
6339 description
6340 "Expected holdtime
6341 expressed
6342 in msec.";
6343 }
6344 }
6345 description
6346 "Choice for holdtime flavor.";
6347 }
6348 description
6349 "Container for BFD.";
6350 }
6351 description
6352 "Define the OAM used on the connection.";
6353 }
6354 description
6355 "Defines connection parameters.";
6356 }
6357 description
6358 "This grouping defines IP connection parameters.";
6359 }
6361 grouping site-service-multicast {
6362 container multicast {
6363 if-feature multicast;
6364 leaf multicast-site-type {
6365 type enumeration {
6366 enum receiver-only {
6367 description
6368 "The site has only receivers.";
6369 }
6370 enum source-only {
6371 description
6372 "The site has only sources.";
6373 }
6374 enum source-receiver {
6375 description
6376 "The site has both
6377 sources & receivers.";
6378 }
6379 }
6380 default "source-receiver";
6381 description
6382 "Type of multicast site.";
6383 }
6384 container multicast-address-family {
6385 leaf ipv4 {
6386 if-feature ipv4;
6387 type boolean;
6388 default true;
6389 description
6390 "Enables ipv4 multicast";
6391 }
6392 leaf ipv6 {
6393 if-feature ipv6;
6394 type boolean;
6395 default false;
6396 description
6397 "Enables ipv6 multicast";
6398 }
6399 description
6400 "Defines protocol to carry multicast.";
6401 }
6402 leaf protocol-type {
6403 type enumeration {
6404 enum host {
6405 description
6406 "
6407 Hosts are directly connected
6408 to the provider network.
6409 Host protocols like IGMP, MLD
6410 are required.
6411 ";
6412 }
6413 enum router {
6414 description
6415 "
6416 Hosts are behind a customer router.
6417 PIM will be implemented.
6418 ";
6419 }
6420 enum both {
6421 description
6422 "Some Hosts are behind a customer
6423 router and some others are directly
6424 connected to the provider network.
6425 Both host and routing protocols must be
6426 used. Typically IGMP and PIM will be
6427 implemented.
6428 ";
6429 }
6430 }
6431 default "both";
6432 description
6433 "Multicast protocol type to be used
6434 with the customer site.";
6435 }
6437 description
6438 "Multicast parameters for the site.";
6439 }
6440 description
6441 "Multicast parameters for the site.";
6442 }
6444 grouping site-management {
6445 container management {
6446 leaf type {
6447 type identityref {
6448 base management;
6449 }
6450 description
6451 "Management type of the connection.";
6452 }
6453 description
6454 "Management configuration";
6455 }
6456 description
6457 "Management parameters for the site.";
6458 }
6460 grouping site-devices {
6461 container devices {
6462 must "/l3vpn-svc/sites/site/management/type = "+
6463 "'provider-managed' or "+
6464 "/l3vpn-svc/sites/site/management/type ="+
6465 "'co-managed'" {
6466 description
6467 "Applicable only for provider-managed or
6468 co-managed device";
6469 }
6470 list device {
6471 key device-id;
6473 leaf device-id {
6474 type svc-id;
6475 description
6476 "identifier for the device";
6477 }
6478 leaf location {
6479 type leafref {
6480 path "/l3vpn-svc/sites/site/locations/"+
6481 "location/location-id";
6482 }
6483 description
6484 "Location of the device";
6485 }
6486 container management {
6487 must "/l3vpn-svc/sites/site/management/type"+
6488 "= 'co-managed'" {
6489 description
6490 "Applicable only for
6491 co-managed device";
6492 }
6493 leaf address-family {
6494 type address-family;
6496 description
6497 "Address family used for management.";
6498 }
6499 leaf address {
6500 type inet:ip-address;
6501 description
6502 "Management address";
6503 }
6504 description
6505 "Management configuration. Only for
6506 co-managed case.";
6507 }
6508 description
6509 "Device configuration";
6510 }
6511 description
6512 "List of devices requested by customer";
6513 }
6514 description
6515 "Grouping for device allocation";
6516 }
6517 grouping site-vpn-flavor {
6518 leaf site-vpn-flavor {
6519 type identityref {
6520 base site-vpn-flavor;
6521 }
6522 default site-vpn-flavor-single;
6523 description
6524 "Defines if the site
6525 is a single VPN site, or multiVPN or ...";
6526 }
6527 description
6528 "Grouping for site-vpn-flavor.";
6529 }
6531 grouping site-vpn-policy {
6532 container vpn-policies {
6533 list vpn-policy {
6534 key vpn-policy-id;
6536 leaf vpn-policy-id {
6537 type svc-id;
6538 description
6539 "Unique identifier for
6540 the VPN policy.";
6541 }
6543 list entries {
6544 key id;
6546 leaf id {
6547 type svc-id;
6548 description
6549 "Unique identifier for
6550 the policy entry.";
6551 }
6552 container filter {
6553 choice lan {
6554 case prefixes {
6555 leaf-list ipv4-lan-prefix {
6556 if-feature ipv4;
6557 type inet:ipv4-prefix;
6558 description
6559 "List of IPv4 prefixes to be
6560 matched.";
6561 }
6562 leaf-list ipv6-lan-prefix {
6563 if-feature ipv6;
6564 type inet:ipv6-prefix;
6565 description
6566 "List of IPv6 prefixes to be
6567 matched.";
6568 }
6569 }
6570 case lan-tag {
6571 leaf-list lan-tag {
6572 type string;
6573 description
6574 "List of lan-tags to be matched.";
6575 }
6576 }
6577 description
6578 "Choice for LAN matching type";
6579 }
6580 description
6581 "If used, it permit to split site LANs
6582 among multiple VPNs.
6583 If no filter used, all the LANs will be
6584 part of the same VPNs with the same
6585 role.";
6586 }
6587 container vpn {
6588 leaf vpn-id {
6589 type leafref {
6590 path "/l3vpn-svc/vpn-services/"
6591 +"vpn-service/vpn-id";
6592 }
6593 mandatory true;
6594 description
6595 "Reference to an IPVPN.";
6596 }
6597 leaf site-role {
6598 type identityref {
6599 base site-role;
6600 }
6601 default any-to-any-role;
6602 description
6603 "Role of the site in the IPVPN.";
6604 }
6605 description
6606 "List of VPNs the LAN is associated to.";
6607 }
6608 description
6609 "List of entries for export policy.";
6610 }
6611 description
6612 "List of VPN policies.";
6613 }
6614 description
6615 "VPN policy.";
6616 }
6617 description
6618 "VPN policy parameters for the site.";
6619 }
6621 grouping site-maximum-routes {
6622 container maximum-routes {
6623 list address-family {
6624 key af;
6626 leaf af {
6627 type address-family;
6629 description
6630 "Address-family.";
6631 }
6632 leaf maximum-routes {
6633 type uint32;
6634 description
6635 "Maximum prefixes the VRF can
6636 accept for this
6637 address-family.";
6638 }
6639 description
6640 "List of address families.";
6641 }
6643 description
6644 "Define maximum-routes for the VRF.";
6645 }
6646 description
6647 "Define maximum-routes for the site.";
6648 }
6650 grouping site-security {
6651 container security {
6652 uses site-security-authentication;
6653 uses site-security-encryption;
6655 description
6656 "Site specific security parameters.";
6657 }
6658 description
6659 "Grouping for security parameters.";
6660 }
6662 grouping site-service {
6663 container service {
6664 uses site-service-qos-profile;
6665 uses site-service-mpls;
6666 uses site-service-multicast;
6668 description
6669 "Service parameters on the attachement.";
6670 }
6671 description
6672 "Grouping for service parameters.";
6673 }
6675 grouping site-network-access-service {
6676 container service {
6677 uses site-service-basic;
6678 uses site-service-qos-profile;
6679 uses site-service-mpls;
6680 uses site-service-multicast;
6682 description
6683 "Service parameters on the attachement.";
6684 }
6685 description
6686 "Grouping for service parameters.";
6687 }
6689 grouping vpn-extranet {
6690 container extranet-vpns {
6691 if-feature extranet-vpn;
6692 list extranet-vpn {
6693 key vpn-id;
6695 leaf vpn-id {
6696 type svc-id;
6697 description
6698 "Identifies the target VPN";
6700 }
6701 leaf local-sites-role {
6702 type identityref {
6703 base site-role;
6705 }
6706 default any-to-any-role;
6707 description
6708 "This describes the role of the
6709 local sites in the target VPN topology.";
6710 }
6711 description
6712 "List of extranet VPNs the local
6713 VPN is attached to.";
6714 }
6715 description
6716 "Container for extranet vpn cfg.";
6717 }
6718 description
6719 "grouping for extranet VPN configuration.
6720 Extranet provides a way to interconnect all sites
6721 from two VPNs in a easy way.";
6723 }
6725 grouping site-attachment-availability {
6726 container availability {
6727 leaf access-priority {
6728 type uint32;
6729 default 1;
6730 description
6731 "Defines the priority for the access.
6732 The highest the priority value is,
6733 the highest the
6734 preference of the access is.";
6735 }
6736 description
6737 "Availability parameters
6738 (used for multihoming)";
6739 }
6740 description
6741 "Defines site availability parameters.";
6742 }
6744 grouping access-vpn-policy {
6745 container vpn-attachment {
6747 choice attachment-flavor {
6748 case vpn-policy-id {
6749 leaf vpn-policy-id {
6750 type leafref {
6751 path "/l3vpn-svc/sites/site/"+
6752 "vpn-policies/vpn-policy/"+
6753 "vpn-policy-id";
6754 }
6755 description
6756 "Reference to a VPN policy.";
6757 }
6758 }
6759 case vpn-id {
6760 leaf vpn-id {
6761 type leafref {
6762 path "/l3vpn-svc/vpn-services"+
6763 "/vpn-service/vpn-id";
6764 }
6765 description
6766 "Reference to a VPN.";
6767 }
6768 leaf site-role {
6769 type identityref {
6770 base site-role;
6771 }
6772 default any-to-any-role;
6773 description
6774 "Role of the site in the IPVPN.";
6775 }
6776 }
6777 mandatory true;
6778 description
6779 "Choice for VPN attachment flavor.";
6780 }
6781 description
6782 "Defines VPN attachment of a site.";
6783 }
6784 description
6785 "Defines the VPN attachment rules
6786 for a site logical access.";
6787 }
6789 grouping vpn-svc-cfg {
6790 leaf vpn-id {
6791 type svc-id;
6792 description
6793 "VPN identifier. Local administration meaning.";
6794 }
6795 leaf customer-name {
6796 type string;
6797 description
6798 "Name of the customer.";
6799 }
6800 leaf vpn-service-topology {
6801 type identityref {
6802 base vpn-topology;
6803 }
6804 default "any-to-any";
6805 description
6806 "VPN service topology.";
6807 }
6809 uses vpn-service-cloud-access;
6810 uses vpn-service-multicast;
6811 uses vpn-service-mpls;
6812 uses vpn-extranet;
6814 description
6815 "grouping for vpn-svc configuration.";
6816 }
6818 grouping site-top-level-cfg {
6819 uses operational-requirements;
6820 uses customer-location-info;
6821 uses site-devices;
6822 uses site-diversity;
6823 uses site-management;
6824 uses site-vpn-policy;
6825 uses site-vpn-flavor;
6826 uses site-maximum-routes;
6827 uses site-security;
6828 uses site-service;
6829 uses site-protection;
6830 uses site-routing;
6832 description
6833 "Grouping for site top level cfg.";
6834 }
6835 grouping site-network-access-top-level-cfg {
6836 leaf site-network-access-type {
6837 type identityref {
6838 base site-network-access-type;
6839 }
6840 default "point-to-point";
6841 description
6842 "Describes the type of connection, e.g. :
6843 point-to-point or multipoint";
6845 }
6847 choice location-flavor {
6848 case location {
6849 when "/l3vpn-svc/sites/site/management/type = "+
6850 "'customer-managed'" {
6851 description
6852 "Applicable only for customer-managed";
6853 }
6854 leaf location-reference {
6855 type leafref {
6856 path "/l3vpn-svc/sites/site/locations/"+
6857 "location/location-id";
6858 }
6859 description
6860 "Location of the site-network-access";
6861 }
6862 }
6863 case device {
6864 when "/l3vpn-svc/sites/site/management/type = "+
6865 "'provider-managed' or "+
6866 "/l3vpn-svc/sites/site/management/type = "+
6867 "'co-managed'" {
6868 description
6869 "Applicable only for provider-managed or
6870 co-managed device";
6871 }
6872 leaf device-reference {
6873 type leafref {
6874 path "/l3vpn-svc/sites/site/devices/"+
6875 "device/device-id";
6876 }
6877 description
6878 "Identifier of CE to use";
6879 }
6880 }
6881 mandatory true;
6882 description
6883 "Choice on how to describe the site location";
6884 }
6886 uses access-diversity;
6887 uses site-attachment-bearer;
6888 uses site-attachment-ip-connection;
6889 uses site-security;
6890 uses site-network-access-service;
6891 uses site-routing;
6892 uses site-attachment-availability;
6893 uses access-vpn-policy;
6895 description
6896 "Grouping for site network access
6897 top level cfg.";
6898 }
6900 /* Main blocks */
6902 container l3vpn-svc {
6903 container vpn-services {
6904 list vpn-service {
6905 key vpn-id;
6907 uses vpn-svc-cfg;
6909 description "
6910 List of VPN services.
6911 ";
6912 }
6913 description
6914 "top level container
6915 for the VPN services.";
6916 }
6918 container sites {
6919 list site {
6920 key site-id;
6922 leaf site-id {
6923 type svc-id;
6924 description
6925 "Identifier of the site.";
6926 }
6928 uses site-top-level-cfg;
6929 uses operational-requirements-ops;
6931 container site-network-accesses {
6932 list site-network-access {
6933 key site-network-access-id;
6935 leaf site-network-access-id {
6936 type svc-id;
6937 description
6938 "Identifier for the access";
6939 }
6940 uses site-network-access-top-level-cfg;
6941 description
6942 "List of accesses for a site.";
6943 }
6944 description
6945 "List of accesses for a site.";
6946 }
6948 description "List of sites.";
6949 }
6950 description
6951 "Container for sites";
6952 }
6954 description
6955 "Main container for L3VPN service configuration.";
6956 }
6958 }
6959
6961 10. Security Considerations
6963 The YANG modules defined in this document MAY be accessed via the
6964 RESTCONF protocol [I-D.ietf-netconf-restconf] or NETCONF protocol
6965 ([RFC6241]. The lowest RESTCONF or NETCONF layer requires that the
6966 transport-layer protocol provides both data integrity and
6967 confidentiality, see Section 2 in [I-D.ietf-netconf-restconf] and
6968 [RFC6241]. The client MUST carefully examine the certificate
6969 presented by the server to determine if it meets the client's
6970 expectations, and the server MUST authenticate client access to any
6971 protected resource. The client identity derived from the
6972 authentication mechanism used is subject to the NETCONF Access
6973 Control Module (NACM) ([RFC6536]). Other protocols to access this
6974 YANG module are also required to support the similar mechanism.
6976 The data nodes defined in the "ietf-l3vpn-svc" YANG module MUST be
6977 carefully created/read/updated/deleted. The entries in the lists
6978 below include customer proprietary or confidential information,
6979 therefore only authorized clients MUST access the information and the
6980 other clients MUST NOT be able to access the information.
6982 o /l3vpn-svc/vpn-services/vpn-service
6984 o /l3vpn-svc/sites/site
6985 The data model proposes some security parameters than can be extended
6986 by augmentation as part of the customer service request: those
6987 parameters are described in Section 6.9.
6989 11. Contribution
6991 Authors would like to thank Rob Shakir for his major contribution on
6992 the initial modeling and use cases.
6994 12. Acknowledgements
6996 Thanks to Qin Wu, Maxim Klyus, Luis Miguel Contreras, Gregory Mirsky,
6997 Zitao Wang, Jing Zhao, Kireeti Kompella, Eric Rosen, Aijun Wang,
6998 Michael Scharf, Xufeng Liu, David Ball, Lucy Yong, Jean-Philippe
6999 Landry and Andrew Leu for the contributions to the document.
7001 13. IANA Considerations
7003 IANA is requested to assign a new URI from the IETF XML registry
7004 ([RFC3688]). Authors are suggesting the following URI:
7006 ID: yang:ietf-l3vpn-svc
7007 URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
7008 Filename: [ TBD-at-registration ]
7009 Reference: [ RFC-to-be ]
7010 Registrant Contact: L3SM WG
7011 XML: N/A, the requested URI is an XML namespace
7013 This document also requests a new YANG module name in the YANG Module
7014 Names registry ([RFC7950]) with the following suggestion:
7016 Name: ietf-l3vpn-svc
7017 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
7018 Prefix: l3vpn-svc
7019 Module:
7020 Reference: [ RFC-to-be ]
7022 14. Change Log
7024 14.1. Changes between versions -18 and-19
7026 o Country code string pattern enforced to ISO ALPHA-2 code.
7028 o zip-code renamed to postal-code.
7030 o Added new address-allocation-type: provider-dhcp-slaac.
7032 o Removed transport-constraints and include transport constraints
7033 (jitter,latency, bandwidth) in the qos-profile.
7035 o qos-profile simplified with more abstraction.
7037 o added target-sites in flow-definition.
7039 14.2. Changes between versions -17 and-18
7041 o Removed TOS from flow matching.
7043 14.3. Changes between versions -16 and-17
7045 o Renamed "vpn-svc" list to "vpn-service".
7047 o Renamed "vpn-policy-list" to "vpn-policies".
7049 o Renamed "management-transport" to "address-family".
7051 o Renamed "multicast-transport" to "address-family".
7053 o Modified cloud access policy using a choice.
7055 o any-to-any-role as default site-role.
7057 o "address-family" is now an enumeration instead of identity.
7059 o cloud-access feature moved to container level.
7061 o Added "address-translation" container for cloud-access.
7063 o Renamed "customer-nat-address" to "customer-address".
7065 o New type ip:address for "customer-address".
7067 o "tree-flavor" moved to leaf-list.
7069 o "bsr-candidate" list moved to "bsr-candidate-address" leaf-list.
7071 o layer becomes mandatory in security-encryption.
7073 o ip-subnet mask range modified.
7075 o multicast transport constraint destination moved to leaf-list.
7077 o lan-prefixes in vpn-policy moved to leaf-list ang tag has been
7078 renamed "prefixes".
7080 o Added source and destination port range in QoS classification.
7082 o QoS classification uses more existing inet:types.
7084 o Grouping defined for site group list.
7086 14.4. Changes between versions -15 and-16
7088 o Rename "topology" leaf to "vpn-service-topology".
7090 14.5. Changes between versions -13 and-14
7092 o Choice between device reference and location reference.
7094 14.6. Changes between versions -12 and-13
7096 o Removed rip-ng identity (rip container has AF information)
7098 o renamed pe-dhcp to provider-dhcp
7100 o add provider-dhcp-relay identity and container
7102 o BW/MTU is now only under site-network-access
7104 o Add list of location and location ID
7106 o Site-network-access mapped to location Identifier
7108 o Add list of devices (provided by operator) requested by customer
7110 o Some management parameters moved under device list
7112 o Site-network-access mapped to device identifier
7114 14.7. Changes between versions -11 and-12
7116 o Fixing some 'when' statements that prevented compilation.
7118 14.8. Changes between versions -09 and-10
7120 o Removed templates.
7122 o Add site-network-access-type.
7124 o Add a leaf number-of-dynamic-address in case of pe-dhcp
7125 addressing.
7127 14.9. Changes between versions -08 and-09
7129 o Add site-vpn-flavor NNI.
7131 14.10. Changes between versions -07 and-08
7133 o Traffic protection moved to site level.
7135 o Decouple operational-requirements in two containers.
7137 14.11. Changes between versions -06 and-07
7139 o Set config false to actual-site-start and stop.
7141 o Add a container before cloud-access list.
7143 o Add a container before authorized-sites list.
7145 o Add a container before denied-sites list.
7147 o Modified access-diversity modeling.
7149 o Replacing type placement diversity by an identity.
7151 14.12. Changes between versions -05 and-06
7153 o Added linecard diverse for site diversity
7155 o Added a new diversity enum in placement-diversity: none
7157 o Added state to site location
7159 o remove reference to core routing model: created new address family
7160 identities
7162 o added features
7164 o Modified bearer parameters
7166 o Modified union for ipv4/ipv6 addresses to ip-address type
7168 o Add BSR parameters for multicast
7170 o Add applications matching for QoS classification
7172 14.13. Changes between versions -04 and-05
7174 o Modify VPN policy and creating a vpn-policy-list
7176 o Add VPN policy reference and VPN ID reference under site-network-
7177 access
7179 14.14. Changes between versions -02 and-03
7181 o Add extranet-vpn container in vpn-svc
7183 o Creating top level containers
7185 o Refine groupings
7187 o Added site-vpn-flavor
7189 o qos-profile moved to choice
7191 o vpn leaf moved to vpn-id in vpn-policy
7193 o added ordered-by user to qos classification list
7195 o moved traffic protection to access availability
7197 o creating a choice in matching filter for VPN policy
7199 o added dot1p matching field in flow-definition
7201 14.15. Changes between versions -01 and-02
7203 o A site is now a collection of site-accesses. This was introduced
7204 to support M to N availability.
7206 o Site-availability has been removed, replaced by availability
7207 parameters under site-accesses
7209 o Added transport-constraints within vpn-svc
7211 o Add ToS support in match-flow
7213 o nexthop in cascaded lan as mandatory
7215 o customer-specific-info deleted and moved to routing protocols
7217 o customer-lan-connection modified: need prefix and CE address
7219 o add choice in managing PE-CE addressing
7220 o Simplifying traffic protection
7222 o Refine groupings for vpn-svc
7224 o Removed name in vpn-svc
7226 o id in vpn-svc moved to string
7228 o Rename id in vpn-svc to vpn-id
7230 o Changed key of vpn-svc list to vpn-id
7232 o Add DSCP support in flow definition
7234 o Removed ACL from security
7236 o Add FW for site and cloud access
7238 14.16. Changes between versions -00 and-01
7240 o Creating multiple reusable groupings
7242 o Added mpls leaf in vpn-svc for carrier's carrier case
7244 o Modify identity single to single-site
7246 o Modify site-type to site-role and also child identities.
7248 o Creating OAM container under site and moved BFD in.
7250 o Creating flow-definition grouping to be reused in ACL, QoS ...
7252 o Simplified VPN policy.
7254 o Adding multicast static group to RP mappings.
7256 o Removed native-vpn and site-role from global site cfg, now managed
7257 within the VPN policy.
7259 o Creating a separate list for site templates.
7261 15. References
7263 15.1. Normative References
7265 [I-D.ietf-netconf-restconf]
7266 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
7267 Protocol", draft-ietf-netconf-restconf-18 (work in
7268 progress), October 2016.
7270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
7271 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
7272 RFC2119, March 1997,
7273 .
7275 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
7276 DOI 10.17487/RFC3688, January 2004,
7277 .
7279 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
7280 Private Network (VPN) Terminology", RFC 4026, DOI
7281 10.17487/RFC4026, March 2005,
7282 .
7284 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
7285 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
7286 2006, .
7288 [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the
7289 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
7290 Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577,
7291 June 2006, .
7293 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
7294 Address Autoconfiguration", RFC 4862, DOI 10.17487/
7295 RFC4862, September 2007,
7296 .
7298 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
7299 and A. Bierman, Ed., "Network Configuration Protocol
7300 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
7301 .
7303 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
7304 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
7305 2012, .
7307 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
7308 Protocol (NETCONF) Access Control Model", RFC 6536, DOI
7309 10.17487/RFC6536, March 2012,
7310 .
7312 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
7313 RFC 7950, DOI 10.17487/RFC7950, August 2016,
7314 .
7316 15.2. Informative References
7318 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
7319 Provider-Provisioned Virtual Private Networks (PPVPNs)",
7320 RFC 4110, DOI 10.17487/RFC4110, July 2005,
7321 .
7323 Authors' Addresses
7325 Stephane Litkowski
7326 Orange Business Services
7328 Email: stephane.litkowski@orange.com
7330 Luis Tomotaki
7331 Verizon
7333 Email: luis.tomotaki@verizon.com
7335 Kenichi Ogaki
7336 KDDI
7338 Email: ke-oogaki@kddi.com