idnits 2.17.1
draft-ietf-l3sm-l3vpn-service-model-16.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 :
----------------------------------------------------------------------------
** There are 17 instances of too long lines in the document, the longest
one being 13 characters in excess of 72.
** 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 333 has weird spacing: '...site-id lea...'
== Line 336 has weird spacing: '...site-id lea...'
== Line 343 has weird spacing: '...rw type ide...'
== Line 366 has weird spacing: '...address ine...'
== Line 412 has weird spacing: '...roup-id str...'
== (12 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 (September 27, 2016) is 2767 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)
** Downref: Normative reference to an Informational RFC: RFC 4026
== Outdated reference: A later version (-18) exists of
draft-ietf-netconf-restconf-16
-- Obsolete informational reference (is this intentional?): RFC 6536
(Obsoleted by RFC 8341)
Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--).
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: March 31, 2017 Verizon
6 K. Ogaki
7 KDDI
8 September 27, 2016
10 YANG Data Model for L3VPN service delivery
11 draft-ietf-l3sm-l3vpn-service-model-16
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 March 31, 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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
72 3. Layer 3 IP VPN service model . . . . . . . . . . . . . . . . 6
73 4. Service data model usage . . . . . . . . . . . . . . . . . . 6
74 5. Design of the Data Model . . . . . . . . . . . . . . . . . . 7
75 5.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 15
76 5.2. VPN service overview . . . . . . . . . . . . . . . . . . 15
77 5.2.1. VPN service topology . . . . . . . . . . . . . . . . 15
78 5.2.1.1. Route Target allocation . . . . . . . . . . . . . 15
79 5.2.1.2. Any to any . . . . . . . . . . . . . . . . . . . 16
80 5.2.1.3. Hub and Spoke . . . . . . . . . . . . . . . . . . 17
81 5.2.1.4. Hub and Spoke disjoint . . . . . . . . . . . . . 18
82 5.2.2. Cloud access . . . . . . . . . . . . . . . . . . . . 18
83 5.2.3. Multicast service . . . . . . . . . . . . . . . . . . 21
84 5.2.4. Extranet VPNs . . . . . . . . . . . . . . . . . . . . 22
85 5.3. Site overview . . . . . . . . . . . . . . . . . . . . . . 23
86 5.3.1. Devices and locations . . . . . . . . . . . . . . . . 25
87 5.3.2. Site network accesses . . . . . . . . . . . . . . . . 26
88 5.3.2.1. Bearer . . . . . . . . . . . . . . . . . . . . . 26
89 5.3.2.2. Connection . . . . . . . . . . . . . . . . . . . 27
90 5.3.2.3. Inheritance of parameters between site and site-
91 network-access . . . . . . . . . . . . . . . . . 28
92 5.4. Site role . . . . . . . . . . . . . . . . . . . . . . . . 28
93 5.5. Site belonging to multiple VPNs . . . . . . . . . . . . . 28
94 5.5.1. Site vpn flavor . . . . . . . . . . . . . . . . . . . 28
95 5.5.1.1. Single VPN attachment : site-vpn-flavor-single . 29
96 5.5.1.2. Multi VPN attachment : site-vpn-flavor-multi . . 29
97 5.5.1.3. Sub VPN attachment : site-vpn-flavor-sub . . . . 30
98 5.5.1.4. NNI : site-vpn-flavor-nni . . . . . . . . . . . . 31
99 5.5.2. Attaching a site to a VPN . . . . . . . . . . . . . . 32
100 5.5.2.1. Reference a VPN . . . . . . . . . . . . . . . . . 33
101 5.5.2.2. VPN policy . . . . . . . . . . . . . . . . . . . 33
102 5.6. Deciding where to connect the site . . . . . . . . . . . 36
103 5.6.1. Constraint : Device . . . . . . . . . . . . . . . . . 37
104 5.6.2. Constraint/parameter : Site location . . . . . . . . 37
105 5.6.3. Constraint/parameter : access type . . . . . . . . . 39
106 5.6.4. Constraint : access diversity . . . . . . . . . . . . 39
107 5.6.5. Impossible access placement . . . . . . . . . . . . . 45
108 5.6.6. Examples of access placement . . . . . . . . . . . . 46
109 5.6.6.1. Multihoming . . . . . . . . . . . . . . . . . . . 46
110 5.6.6.2. Site offload . . . . . . . . . . . . . . . . . . 48
111 5.6.6.3. Parallel links . . . . . . . . . . . . . . . . . 54
112 5.6.6.4. SubVPN with multihoming . . . . . . . . . . . . . 55
113 5.6.7. Route Distinguisher and VRF allocation . . . . . . . 59
114 5.7. Site network access availability . . . . . . . . . . . . 60
115 5.8. Traffic protection . . . . . . . . . . . . . . . . . . . 61
116 5.9. Security . . . . . . . . . . . . . . . . . . . . . . . . 62
117 5.9.1. Authentication . . . . . . . . . . . . . . . . . . . 62
118 5.9.2. Encryption . . . . . . . . . . . . . . . . . . . . . 62
119 5.10. Management . . . . . . . . . . . . . . . . . . . . . . . 62
120 5.11. Routing protocols . . . . . . . . . . . . . . . . . . . . 63
121 5.11.1. Dual stack handling . . . . . . . . . . . . . . . . 63
122 5.11.2. Direct LAN connection onto SP network . . . . . . . 64
123 5.11.3. Direct LAN connection onto SP network with
124 redundancy . . . . . . . . . . . . . . . . . . . . . 64
125 5.11.4. Static routing . . . . . . . . . . . . . . . . . . . 65
126 5.11.5. RIP routing . . . . . . . . . . . . . . . . . . . . 65
127 5.11.6. OSPF routing . . . . . . . . . . . . . . . . . . . . 65
128 5.11.7. BGP routing . . . . . . . . . . . . . . . . . . . . 67
129 5.12. Service . . . . . . . . . . . . . . . . . . . . . . . . . 69
130 5.12.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . 69
131 5.12.2. QoS . . . . . . . . . . . . . . . . . . . . . . . . 69
132 5.12.2.1. QoS classification . . . . . . . . . . . . . . . 69
133 5.12.2.2. QoS profile . . . . . . . . . . . . . . . . . . 72
134 5.12.3. Multicast . . . . . . . . . . . . . . . . . . . . . 75
135 5.13. Enhanced VPN features . . . . . . . . . . . . . . . . . . 75
136 5.13.1. Carrier's Carrier . . . . . . . . . . . . . . . . . 75
137 5.13.2. Transport constraints . . . . . . . . . . . . . . . 77
138 5.14. External ID references . . . . . . . . . . . . . . . . . 78
139 5.15. Defining NNIs . . . . . . . . . . . . . . . . . . . . . . 78
140 5.15.1. Defining NNI with option A flavor . . . . . . . . . 79
141 5.15.2. Defining NNI with option B flavor . . . . . . . . . 83
142 5.15.3. Defining NNI with option C flavor . . . . . . . . . 85
143 6. Service model usage example . . . . . . . . . . . . . . . . . 87
144 7. Interaction with Other YANG Modules . . . . . . . . . . . . . 92
145 8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 97
146 9. Security Considerations . . . . . . . . . . . . . . . . . . . 151
147 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 152
148 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 152
149 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 152
150 12.1. Changes between versions -15 and-16 . . . . . . . . . . 152
151 12.2. Changes between versions -13 and-14 . . . . . . . . . . 153
152 12.3. Changes between versions -12 and-13 . . . . . . . . . . 153
153 12.4. Changes between versions -11 and-12 . . . . . . . . . . 153
154 12.5. Changes between versions -09 and-10 . . . . . . . . . . 153
155 12.6. Changes between versions -08 and-09 . . . . . . . . . . 153
156 12.7. Changes between versions -07 and-08 . . . . . . . . . . 153
157 12.8. Changes between versions -06 and-07 . . . . . . . . . . 154
158 12.9. Changes between versions -05 and-06 . . . . . . . . . . 154
159 12.10. Changes between versions -04 and-05 . . . . . . . . . . 154
160 12.11. Changes between versions -02 and-03 . . . . . . . . . . 154
161 12.12. Changes between versions -01 and-02 . . . . . . . . . . 155
162 12.13. Changes between versions -00 and-01 . . . . . . . . . . 156
163 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 156
164 13.1. Normative References . . . . . . . . . . . . . . . . . . 156
165 13.2. Informative References . . . . . . . . . . . . . . . . . 157
166 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 158
168 1. Introduction
170 This document defines a YANG data model for communication between
171 customers and network operators, and to provide input to automated
172 control and configuration applications.
174 1.1. Terminology
176 The following terms are defined in [RFC6241] and are not redefined
177 here:
179 o client
181 o configuration data
183 o server
185 o state data
187 The following terms are defined in [RFC7950] and are not redefined
188 here:
190 o augment
192 o data model
193 o data node
195 The terminology for describing YANG data models is found in
196 [RFC7950].
198 1.2. Tree diagram
200 A simplified graphical representation of the data model is presented
201 in Section 5.
203 The meaning of the symbols in these diagrams is as follows:
205 o Brackets "[" and "]" enclose list keys.
207 o Curly braces "{" and "}" contain names of optional features that
208 make the corresponding node conditional.
210 o Abbreviations before data node names: "rw" means configuration
211 (read-write), and "ro" state data (read-only).
213 o Symbols after data node names: "?" means an optional node and "*"
214 denotes a "list" or "leaf-list".
216 o Parentheses enclose choice and case nodes, and case nodes are also
217 marked with a colon (":").
219 o Ellipsis ("...") stands for contents of subtrees that are not
220 shown.
222 2. Definitions
224 Customer Edge (CE) Device: Equipment that is dedicated to a
225 particular customer and is directly connected (at layer 3) to one or
226 more PE devices via attachment circuits. A CE is usually located at
227 the customer premises, and is usually dedicated to a single VPN,
228 although it may support multiple VPNs if each one has separate
229 attachment circuits.
231 Provider Edge (PE) Device: Equipment managed by the SP that can
232 support multiple VPNs for different customers, and is directly
233 connected (at layer 3) to one or more CE devices via attachment
234 circuits. A PE is usually located at an SP point of presence (PoP)
235 and is managed by the SP.
237 PE-Based VPNs: The PE devices know that certain traffic is VPN
238 traffic. They forward the traffic (through tunnels) based on the
239 destination IP address of the packet, and optionally on based on
240 other information in the IP header of the packet. The PE devices are
241 themselves the tunnel endpoints. The tunnels may make use of various
242 encapsulations to send traffic over the SP network (such as, but not
243 restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels).
245 3. Layer 3 IP VPN service model
247 A Layer 3 IPVPN service is a collection of sites that are authorized
248 to exchange traffic between each other over a shared IP
249 infrastructure. This layer 3 VPN service model aims at providing a
250 common understanding on how the corresponding IP VPN service is to be
251 deployed over the shared infrastructure. This service model is
252 limited to BGP PE-Based VPNs as described in [RFC4110] and [RFC4364].
254 4. Service data model usage
256 L3VPN-SVC |
257 MODEL |
258 |
259 +------------------+ +-----+
260 | Orchestration | < --- > | OSS |
261 +------------------+ +-----+
262 | |
263 +----------------+ |
264 | Config manager | |
265 +----------------+ |
266 | |
267 | Netconf/CLI ...
268 | |
269 +------------------------------------------------+
270 Network
272 +++++++
273 + AAA +
274 +++++++
276 +++++++ Bearer ++++++++ ++++++++ +++++++
277 + CEA + ------- + PE A + + PE B + ----- + CEB +
278 +++++++ Cnct ++++++++ ++++++++ +++++++
280 Site A Site B
282 The idea of the L3 IPVPN service model is to propose an abstracted
283 interface between customers and network operators to manage
284 configuration of components of a L3VPN service. A typical usage is
285 to use this model as an input for an orchestration layer who will be
286 responsible to translate it to orchestrated configuration of network
287 elements who will be part of the service. The network elements can
288 be routers, but also servers (like AAA), and not limited to these
289 examples. The configuration of network elements MAY be done by CLI,
290 or by NETCONF ([RFC6241])/RESTCONF ([I-D.ietf-netconf-restconf])
291 coupled with specific configuration YANG data models (BGP, VRF, BFD
292 ...) or any other way.
294 The usage of this service model is not limited to this example, it
295 can be used by any component of the management system but not
296 directly by network elements.
298 5. Design of the Data Model
300 The YANG module is divided in two main containers : vpn-services,
301 sites.
303 The vpn-svc under vpn-services defines global parameters for the VPN
304 service for a specific customer.
306 A site is composed of at least one site-network-access and may have
307 multiple site-network-access in case of multihoming. The site-
308 network-access attachment is done through a bearer with a connection
309 (transport protocol) on top. The bearer refers to properties of the
310 attachment that are below layer 3 while the connection refers to
311 layer 3 protocol oriented properties. The bearer may be allocated
312 dynamically by the service provider and the customer may provide some
313 constraints or parameters to drive the placement.
315 Authorization of traffic exchange is done through what we call a VPN
316 policy or VPN service topology defining routing exchange rules
317 between sites.
319 The figure below describe the overall structure of the YANG module:
321 module: ietf-l3vpn-svc
322 +--rw l3vpn-svc
323 +--rw vpn-services
324 | +--rw vpn-svc* [vpn-id]
325 | +--rw vpn-id svc-id
326 | +--rw customer-name? string
327 | +--rw vpn-service-topology? identityref
328 | +--rw cloud-accesses
329 | | +--rw cloud-access* [cloud-identifier] {cloud-access}?
330 | | +--rw cloud-identifier string
331 | | +--rw authorized-sites
332 | | | +--rw authorized-site* [site-id]
333 | | | +--rw site-id leafref
334 | | +--rw denied-sites
335 | | | +--rw denied-site* [site-id]
336 | | | +--rw site-id leafref
337 | | +--rw nat-enabled? boolean
338 | | +--rw customer-nat-address? inet:ipv4-address
339 | +--rw multicast {multicast}?
340 | | +--rw enabled? boolean
341 | | +--rw customer-tree-flavors
342 | | | +--rw tree-flavor* [type]
343 | | | +--rw type identityref
344 | | +--rw rp
345 | | +--rw rp-group-mappings
346 | | | +--rw rp-group-mapping* [id]
347 | | | +--rw id uint16
348 | | | +--rw provider-managed
349 | | | | +--rw enabled? boolean
350 | | | | +--rw rp-redundancy? boolean
351 | | | | +--rw optimal-traffic-delivery? boolean
352 | | | +--rw rp-address? inet:ip-address
353 | | | +--rw groups
354 | | | +--rw group* [id]
355 | | | +--rw id uint16
356 | | | +--rw (group-format)?
357 | | | +--:(startend)
358 | | | | +--rw group-start? inet:ip-address
359 | | | | +--rw group-end? inet:ip-address
360 | | | +--:(singleaddress)
361 | | | +--rw group-address? inet:ip-address
362 | | +--rw rp-discovery
363 | | +--rw rp-discovery-type? identityref
364 | | +--rw bsr-candidates
365 | | +--rw bsr-candidate* [address]
366 | | +--rw address inet:ip-address
367 | +--rw carrierscarrier? boolean {carrierscarrier}?
368 | +--rw transport-constraints {traffic-engineering}?
369 | | +--rw unicast-transport-constraints
370 | | | +--rw constraint* [constraint-id]
371 | | | +--rw constraint-id svc-id
372 | | | +--rw site1? svc-id
373 | | | +--rw site2? svc-id
374 | | | +--rw constraint-list* [constraint-type]
375 | | | +--rw constraint-type identityref
376 | | | +--rw constraint-opaque-value? string
377 | | +--rw multicast-transport-constraints {traffic-engineering-multicast}?
378 | | +--rw constraint* [constraint-id]
379 | | +--rw constraint-id svc-id
380 | | +--rw src-site? svc-id
381 | | +--rw dst-site? svc-id
382 | | +--rw constraint-list* [constraint-type]
383 | | +--rw constraint-type identityref
384 | | +--rw constraint-opaque-value? string
385 | +--rw extranet-vpns {extranet-vpn}?
386 | +--rw extranet-vpn* [vpn-id]
387 | +--rw vpn-id svc-id
388 | +--rw local-sites-role? identityref
389 +--rw sites
390 +--rw site* [site-id]
391 +--rw site-id svc-id
392 +--rw requested-site-start? yang:date-and-time
393 +--rw requested-site-stop? yang:date-and-time
394 +--rw locations
395 | +--rw location* [location-id]
396 | +--rw location-id svc-id
397 | +--rw address? string
398 | +--rw zip-code? string
399 | +--rw state? string
400 | +--rw city? string
401 | +--rw country-code? string
402 +--rw devices
403 | +--rw device* [device-id]
404 | +--rw device-id svc-id
405 | +--rw location? leafref
406 | +--rw management
407 | +--rw management-transport? identityref
408 | +--rw address? inet:ip-address
409 +--rw site-diversity {site-diversity}?
410 | +--rw groups
411 | +--rw group* [group-id]
412 | +--rw group-id string
413 +--rw management
414 | +--rw type? identityref
415 +--rw vpn-policy-list
416 | +--rw vpn-policy* [vpn-policy-id]
417 | +--rw vpn-policy-id svc-id
418 | +--rw entries* [id]
419 | +--rw id svc-id
420 | +--rw filter
421 | | +--rw (lan)?
422 | | +--:(lan-prefix)
423 | | | +--rw lan-prefixes
424 | | | +--rw ipv4-lan-prefixes* [lan] {ipv4}?
425 | | | | +--rw lan inet:ipv4-prefix
426 | | | +--rw ipv6-lan-prefixes* [lan] {ipv6}?
427 | | | +--rw lan inet:ipv6-prefix
428 | | +--:(lan-tag)
429 | | +--rw lan-tag* string
430 | +--rw vpn
431 | +--rw vpn-id leafref
432 | +--rw site-role identityref
433 +--rw site-vpn-flavor? identityref
434 +--rw maximum-routes
435 | +--rw address-family* [af]
436 | +--rw af identityref
437 | +--rw maximum-routes? uint32
438 +--rw security
439 | +--rw authentication
440 | +--rw encryption {encryption}?
441 | +--rw enabled? boolean
442 | +--rw layer? enumeration
443 | +--rw encryption-profile
444 | +--rw (profile)?
445 | +--:(provider-profile)
446 | | +--rw profile-name? string
447 | +--:(customer-profile)
448 | +--rw algorithm? string
449 | +--rw (key-type)?
450 | +--:(psk)
451 | | +--rw preshared-key? string
452 | +--:(pki)
453 +--rw service
454 | +--rw qos {qos}?
455 | | +--rw qos-classification-policy
456 | | | +--rw rule* [id]
457 | | | +--rw id uint16
458 | | | +--rw (match-type)?
459 | | | | +--:(match-flow)
460 | | | | | +--rw match-flow
461 | | | | | +--rw dscp? uint8
462 | | | | | +--rw tos? uint8
463 | | | | | +--rw dot1p? uint8
464 | | | | | +--rw ipv4-src-prefix? inet:ipv4-prefix
465 | | | | | +--rw ipv6-src-prefix? inet:ipv6-prefix
466 | | | | | +--rw ipv4-dst-prefix? inet:ipv4-prefix
467 | | | | | +--rw ipv6-dst-prefix? inet:ipv6-prefix
468 | | | | | +--rw l4-src-port? uint16
469 | | | | | +--rw l4-dst-port? uint16
470 | | | | | +--rw protocol-field? union
471 | | | | +--:(match-application)
472 | | | | +--rw match-application? identityref
473 | | | +--rw target-class-id? string
474 | | +--rw qos-profile
475 | | +--rw (qos-profile)?
476 | | +--:(standard)
477 | | | +--rw profile? string
478 | | +--:(custom)
479 | | +--rw classes {qos-custom}?
480 | | +--rw class* [class-id]
481 | | +--rw class-id string
482 | | +--rw rate-limit? uint8
483 | | +--rw priority-level? uint8
484 | | +--rw guaranteed-bw-percent? uint8
485 | +--rw carrierscarrier {carrierscarrier}?
486 | | +--rw signalling-type? enumeration
487 | +--rw multicast {multicast}?
488 | +--rw multicast-site-type? enumeration
489 | +--rw multicast-transport-protocol
490 | | +--rw ipv4? boolean {ipv4}?
491 | | +--rw ipv6? boolean {ipv6}?
492 | +--rw protocol-type? enumeration
493 +--rw traffic-protection {fast-reroute}?
494 | +--rw enabled? boolean
495 +--rw routing-protocols
496 | +--rw routing-protocol* [type]
497 | +--rw type identityref
498 | +--rw ospf {rtg-ospf}?
499 | | +--rw address-family* identityref
500 | | +--rw area-address? yang:dotted-quad
501 | | +--rw metric? uint16
502 | | +--rw sham-links {rtg-ospf-sham-link}?
503 | | +--rw sham-link* [target-site]
504 | | +--rw target-site svc-id
505 | | +--rw metric? uint16
506 | +--rw bgp {rtg-bgp}?
507 | | +--rw autonomous-system? uint32
508 | | +--rw address-family* identityref
509 | +--rw static
510 | | +--rw cascaded-lan-prefixes
511 | | +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}?
512 | | | +--rw lan inet:ipv4-prefix
513 | | | +--rw lan-tag? string
514 | | | +--rw next-hop inet:ipv4-address
515 | | +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}?
516 | | +--rw lan inet:ipv6-prefix
517 | | +--rw lan-tag? string
518 | | +--rw next-hop inet:ipv6-address
519 | +--rw rip {rtg-rip}?
520 | | +--rw address-family* identityref
521 | +--rw vrrp {rtg-vrrp}?
522 | +--rw address-family* identityref
523 +--ro actual-site-start? yang:date-and-time
524 +--ro actual-site-stop? yang:date-and-time
525 +--rw site-network-accesses
526 +--rw site-network-access* [site-network-access-id]
527 +--rw site-network-access-id svc-id
528 +--rw site-network-access-type? identityref
529 +--rw (location-flavor)
530 | +--:(location)
531 | | +--rw location-reference? leafref
532 | +--:(device)
533 | +--rw device-reference? leafref
534 +--rw access-diversity {site-diversity}?
535 | +--rw groups
536 | | +--rw group* [group-id]
537 | | +--rw group-id string
538 | +--rw constraints
539 | +--rw constraint* [constraint-type]
540 | +--rw constraint-type identityref
541 | +--rw target
542 | +--rw (target-flavor)?
543 | +--:(id)
544 | | +--rw group* [group-id]
545 | | ...
546 | +--:(all-accesses)
547 | | +--rw all-other-accesses? empty
548 | +--:(all-groups)
549 | +--rw all-other-groups? empty
550 +--rw bearer
551 | +--rw requested-type {requested-type}?
552 | | +--rw requested-type? string
553 | | +--rw strict? boolean
554 | +--rw always-on? boolean {always-on}?
555 | +--rw bearer-reference? string {bearer-reference}?
556 +--rw ip-connection
557 | +--rw ipv4 {ipv4}?
558 | | +--rw address-allocation-type? identityref
559 | | +--rw number-of-dynamic-address? uint8
560 | | +--rw dhcp-relay
561 | | | +--rw customer-dhcp-servers
562 | | | +--rw server-ip-address* inet:ipv4-address
563 | | +--rw addresses
564 | | +--rw provider-address? inet:ipv4-address
565 | | +--rw customer-address? inet:ipv4-address
566 | | +--rw mask? uint8
567 | +--rw ipv6 {ipv6}?
568 | | +--rw address-allocation-type? identityref
569 | | +--rw number-of-dynamic-address? uint8
570 | | +--rw dhcp-relay
571 | | | +--rw customer-dhcp-servers
572 | | | +--rw server-ip-address* inet:ipv6-address
573 | | +--rw addresses
574 | | +--rw provider-address? inet:ipv6-address
575 | | +--rw customer-address? inet:ipv6-address
576 | | +--rw mask? uint8
577 | +--rw oam
578 | +--rw bfd {bfd}?
579 | +--rw bfd-enabled? boolean
580 | +--rw (holdtime)?
581 | +--:(profile)
582 | | +--rw profile-name? string
583 | +--:(fixed)
584 | +--rw fixed-value? uint32
585 +--rw security
586 | +--rw authentication
587 | +--rw encryption {encryption}?
588 | +--rw enabled? boolean
589 | +--rw layer? enumeration
590 | +--rw encryption-profile
591 | +--rw (profile)?
592 | +--:(provider-profile)
593 | | +--rw profile-name? string
594 | +--:(customer-profile)
595 | +--rw algorithm? string
596 | +--rw (key-type)?
597 | +--:(psk)
598 | | ...
599 | +--:(pki)
600 +--rw service
601 | +--rw svc-input-bandwidth? uint32
602 | +--rw svc-output-bandwidth? uint32
603 | +--rw svc-mtu? uint16
604 | +--rw qos {qos}?
605 | | +--rw qos-classification-policy
606 | | | +--rw rule* [id]
607 | | | +--rw id uint16
608 | | | +--rw (match-type)?
609 | | | | +--:(match-flow)
610 | | | | | +--rw match-flow
611 | | | | | ...
612 | | | | +--:(match-application)
613 | | | | +--rw match-application? identityref
614 | | | +--rw target-class-id? string
615 | | +--rw qos-profile
616 | | +--rw (qos-profile)?
617 | | +--:(standard)
618 | | | +--rw profile? string
619 | | +--:(custom)
620 | | +--rw classes {qos-custom}?
621 | | +--rw class* [class-id]
622 | | ...
624 | +--rw carrierscarrier {carrierscarrier}?
625 | | +--rw signalling-type? enumeration
626 | +--rw multicast {multicast}?
627 | +--rw multicast-site-type? enumeration
628 | +--rw multicast-transport-protocol
629 | | +--rw ipv4? boolean {ipv4}?
630 | | +--rw ipv6? boolean {ipv6}?
631 | +--rw protocol-type? enumeration
632 +--rw routing-protocols
633 | +--rw routing-protocol* [type]
634 | +--rw type identityref
635 | +--rw ospf {rtg-ospf}?
636 | | +--rw address-family* identityref
637 | | +--rw area-address? yang:dotted-quad
638 | | +--rw metric? uint16
639 | | +--rw sham-links {rtg-ospf-sham-link}?
640 | | +--rw sham-link* [target-site]
641 | | +--rw target-site svc-id
642 | | +--rw metric? uint16
643 | +--rw bgp {rtg-bgp}?
644 | | +--rw autonomous-system? uint32
645 | | +--rw address-family* identityref
646 | +--rw static
647 | | +--rw cascaded-lan-prefixes
648 | | +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}?
649 | | | +--rw lan inet:ipv4-prefix
650 | | | +--rw lan-tag? string
651 | | | +--rw next-hop inet:ipv4-address
652 | | +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}?
653 | | +--rw lan inet:ipv6-prefix
654 | | +--rw lan-tag? string
655 | | +--rw next-hop inet:ipv6-address
656 | +--rw rip {rtg-rip}?
657 | | +--rw address-family* identityref
658 | +--rw vrrp {rtg-vrrp}?
659 | +--rw address-family* identityref
660 +--rw availability
661 | +--rw access-priority? uint32
662 +--rw vpn-attachment
663 +--rw (attachment-flavor)
664 +--:(vpn-policy-id)
665 | +--rw vpn-policy-id? leafref
666 +--:(vpn-id)
667 +--rw vpn-id? leafref
668 +--rw site-role identityref
670 5.1. Features
672 The model implements a lot of features allowing implementations to be
673 modular. As example, an implementation may support only IPv4 VPNs
674 (ipv4 feature), IPv6 (ipv6 feature), or both (by advertising both
675 features). The routing protocols proposed to the customer may also
676 be enabled through features. This model proposes also some features
677 for more advanced options like : extranet-vpn support
678 (Section 5.2.4), site diversity (Section 5.6), qos (Section 5.12.2),
679 ...
681 5.2. VPN service overview
683 The vpn-svc container contains generic information about the VPN
684 service. The vpn-id of the vpn-svc refers to an internal reference
685 for this VPN service, while customer name refers to a more explicit
686 reference to the customer. This identifier is purely internal to the
687 organization responsible for the VPN service. The vpn-id MUST be
688 unique.
690 5.2.1. VPN service topology
692 The type of VPN service topology is required for configuration.
693 Current proposal supports : any-to-any, hub and spoke (where hubs can
694 exchange traffic), and hub and spoke disjoint (where hubs cannot
695 exchange traffic). New topologies could be added by augmentation.
696 By default, any-to-any VPN service topology is used.
698 5.2.1.1. Route Target allocation
700 Layer 3 PE-based VPN is built using route-targets as described in
701 [RFC4364]. It is expected the management system to allocate
702 automatically a set of route-targets upon a VPN service creation
703 request. How the management system allocates route-targets is out of
704 scope of the document but multiple ways could be envisaged as
705 described below.
707 Management system
708 <------------------------------------------------->
709 Request RT
710 +-----------------------+ Topo a2a +----------+
711 RESTCONF | | -----> | |
712 User ------------- | Service Orchestration | |NetworkOSS|
713 l3vpn-svc | | <----- | |
714 model +-----------------------+ Response +----------+
715 RT1,RT2
717 In the example above, a service orchestration, owning the
718 instantiation of this service model, request route-targets to the
719 network OSS. Based on the requested VPN service topology, the
720 network OSS replies with one or multiple route-targets. The
721 interface between this service orchestration and network OSS is out
722 of scope of this document.
724 +---------------------------+
725 RESTCONF | |
726 User ------------- | Service Orchestration |
727 l3vpn-svc | |
728 model | |
729 | RT pool : 10:1->10:10000 |
730 | RT pool : 20:50->20:5000 |
731 +---------------------------+
733 In the example above, a service orchestration, owning the
734 instantiation of this service model, owns one or more pools of route-
735 target (filled by service provider) that can be allocated. Based on
736 the requested VPN service topology, it will allocate one or multiple
737 route-targets from the pool.
739 The mechanism displayed above are just examples and SHOULD NOT be
740 considered as exhaustive list of solutions.
742 5.2.1.2. Any to any
744 +------------------------------------------------------------+
745 | VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 |
746 | |
747 | VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 |
748 +------------------------------------------------------------+
750 Figure - Any to any VPN service topology
752 In the any to any VPN service topology, all VPN sites can discuss
753 between each other without any restriction. It is expected that the
754 management system that receives a any to any IPVPN service request
755 through this model, needs to assign and then configure the VRF and
756 route-targets on the appropriate PEs. In case of any to any, in
757 general a single route-target is required and every VRF imports and
758 exports this route-target.
760 5.2.1.3. Hub and Spoke
762 +-------------------------------------------------------------+
763 | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
764 | +----------------------------------+
765 | |
766 | +----------------------------------+
767 | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
768 +-------------------------------------------------------------+
770 Figure - Hub and Spoke VPN service topology
772 In the hub and spoke VPN service topology, all spoke sites can
773 discuss only with Hub sites but not between each other, and hubs can
774 discuss also between each other. It is expected that the management
775 system that owns a any to any IPVPN service request through this
776 model, needs to assign and then configure the VRF and route-targets
777 on the appropriate PEs. In case of hub and spoke, in general a two
778 route-targets are required (one route-target for Hub routes, one
779 route-target for spoke routes). A Hub VRF, connecting Hub sites,
780 will export Hub routes with Hub route-target, and will import Spoke
781 routes through Spoke route-target. It will also import the Hub
782 route-target to allow Hub to Hub communication. A Spoke VRF,
783 connecting Spoke sites, will export Spoke routes with Spoke route-
784 target, and will import Hub routes through Hub route-target.
786 The management system MUST take into account Hub and Spoke
787 connections constraints. For example, if management system decides
788 to mesh a spoke site and a hub site on the same PE, it needs to mesh
789 connections in different VRFs as displayed in the figure below.
791 Hub_Site ------- (VRF_Hub) PE1
792 (VRF_Spoke)
793 / |
794 Spoke_Site1 -------------------+ |
795 |
796 Spoke_Site2 -----------------------+
798 5.2.1.4. Hub and Spoke disjoint
800 +-------------------------------------------------------------+
801 | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
802 +--------------------------+ +-------------------------------+
803 | |
804 +--------------------------+ +-------------------------------+
805 | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
806 +-------------------------------------------------------------+
808 Figure - Hub and Spoke disjoint VPN service topology
810 In the hub and spoke disjoint VPN service topology, all spoke sites
811 can discuss only with Hub sites but not between each other and hubs
812 cannot discuss between each other. It is expected that the
813 management system that owns a any to any IPVPN service request
814 through this model, needs to assign and then configure the VRF and
815 route-targets on the appropriate PEs. In case of hub and spoke, in
816 general a two route-targets are required (one route-target for Hub
817 routes, one route-target for spoke routes). A Hub VRF, connecting
818 Hub sites, will export Hub routes with Hub route-target, and will
819 import Spoke routes through Spoke route-target. A Spoke VRF,
820 connecting Spoke sites, will export Spoke routes with Spoke route-
821 target, and will import Hub routes through Hub route-target.
823 The management system MUST take into account Hub and Spoke
824 connections constraints as in the previous case.
826 Hub and spoke disjoint can also be seen as two hub and spoke VPNs
827 sharing with a common set of spoke sites.
829 5.2.2. Cloud access
831 The proposed model provides cloud access configuration through the
832 cloud-access container. The usage of cloud-access is targeted for
833 public cloud. Internet access can also be considered as a public
834 cloud access service. The cloud-access container provides parameters
835 for network address translation and authorization rules.
837 Private cloud access may be addressed through NNIs as described in
838 Section 5.15.
840 A cloud identifier is used to reference the target service. This
841 identifier is local to each administration.
843 If NAT is required to access to the cloud, the nat-enabled leaf MUST
844 be set to true. A NAT address may be provided in customer-nat-
845 address, in case the customer is providing the public IP address for
846 the cloud access. If service provider is providing the NAT address,
847 customer-nat-address is not necessary as it can be picked from a
848 service provider pool.
850 By default, all sites in the IPVPN MUST be authorized to access to
851 the cloud. In case restrictions are required, a user MAY configure
852 the authorized-sites and denied-sites list. The authorization-sites
853 defines the list of sites authorized for cloud access. The denied-
854 sites defines the list of sites denied for cloud access. The model
855 supports both "deny all except" and "accept all except"
856 authorization.
858 The "deny all except" behavior is obtained by filling only the
859 authorized-sites. All the sites listed will be authorized, all
860 others will be denied.
862 The "accept all except" behavior is obtained by filling only the
863 denied-sites. All the sites listed will be denied, all others will
864 be authorized.
866 Defining both denied-sites and authorized-sites MUST be processed as
867 "deny all except", so the denied-sites will have no effect.
869 How the restrictions will be configured on network elements is out of
870 scope of this document and will be specific to each deployment.
872 IPVPN
873 ++++++++++++++++++++++++++++++++ +++++++++++
874 + Site 3 + --- + Cloud1 +
875 + Site 1 + +++++++++++
876 + +
877 + Site 2 + --- ++++++++++++
878 + + + Internet +
879 + Site 4 + ++++++++++++
880 ++++++++++++++++++++++++++++++++
881 |
882 ++++++++++
883 + Cloud2 +
884 ++++++++++
886 In the example above, we may configure the global VPN to access
887 Internet by creating a cloud-access pointing to the cloud identifier
888 for Internet service. No authorized-sites will be configured as all
889 sites are required to access to Internet. NAT-enabled will be set to
890 true and a nat-address will be configured.
892
893 ZKITYHJ054687
894 CUSTOMER_1
895 any-to-any
896
897
898 51
899 true
900
901
902
904 If Site1 and Site2 requires access to Cloud1, a new cloud-access will
905 be created pointing to the cloud identifier of Cloud1. Authorized
906 sites will be filled with reference to Site1 and Site2.
908
909 12456487
910 CUSTOMER_1
911 any-to-any
912
913
914 1111111
915
916
917 site1
918 site2
919
920
921
922
923
925 If all sites except Site1 requires access to Cloud2, a new cloud-
926 access will be created pointing to the cloud identifier of Cloud2.
927 denied-sites will be filled with reference to Site1.
929
930 12456487
931 CUSTOMER_1
932 any-to-any
933
934
935 22222222
936
937
938 site1
939
940
941
942
943
945 5.2.3. Multicast service
947 Multicast in IP VPN is described in [RFC6513].
949 If IPVPN supports multicast service, it is expected to provide inputs
950 on global multicast parameters.
952 The user of this model will need to fill the flavor of trees that
953 will be used by customer within the IPVPN (Customer tree). The
954 proposed model supports ASM, SSM and BiDirectional trees (and can be
955 augmented). Multiple flavors of tree can be supported
956 simultaneously.
958 (SSM tree)
959 Recv (IGMPv3) -- Site2 ------- PE2
960 PE1 --- Site1 --- Source1
961 \
962 -- Source2
964 (ASM tree)
965 Recv (IGMPv2) -- Site3 ------- PE3
967 (SSM tree)
968 Recv (IGMPv3) -- Site4 ------- PE4
969 /
970 Recv (IGMPv2) -- Site5 --------
971 (ASM tree)
973 In case of ASM flavor requested, this model requires to fill the rp
974 and rp-discovery parameters. Multiple RP to group mappings can be
975 created using the rp-group-mappings container. For each mapping, the
976 RP service can be managed by the service provider using the leaf
977 provider-managed/enabled set to true. In case of provider managed
978 RP, user can request for rendez-vous point redundancy and/or optimal
979 traffic delivery. Those parameters will help the service provider to
980 select the appropriate technology to fulfill the customer service
981 requirement : for instance, in case of request of optimal traffic
982 delivery, service provider may decide to use Anycast-RP or RP-tree to
983 SPT switchover.
985 In case of customer managed RP, the RP address must be filled in the
986 RP to group mappings using the "rp-address" leaf. This leaf is not
987 needed for provider managed RP.
989 User can define a specific rp-discovery mechanism like : auto-rp,
990 static-rp, bsr-rp modes. By default, the model considers static-rp
991 if ASM is requested. A single rp-discovery mechanism is allowed for
992 the VPN. "rp-discovery" can be used for provider and customer
993 managed RPs. In case of provider managed RP, if the user wants to
994 use bsr-rp as discovery protocol, service provider will consider the
995 provider managed rp-group-mappings for bsr-rp. The service provider
996 will so configure its selected RPs to be bsr-rp-candidates. In case
997 of customer managed RP and bsr-rp discovery mechanism, the rp-address
998 provided will be considered as bsr-rp candidate.
1000 5.2.4. Extranet VPNs
1002 There are some cases where a particular VPN needs to access to
1003 resources that are external. The resources may be located in another
1004 VPN.
1006 +-----------+ +-----------+
1007 / \ / \
1008 SiteA -- | VPN A | --- | VPN B | --- SiteB
1009 \ / \ / (Shared
1010 +-----------+ +-----------+ resources)
1012 In the figure above, VPN B has some resources on Site B that need to
1013 be available to some customers/partners. VPN A must be able to
1014 access those VPN B resources.
1016 Such VPN connection scenario can be achieved by the VPN policy
1017 defined in Section 5.5.2.2. But there are some simple cases, where a
1018 particular VPN (VPN A) needs to access to all resources in a VPN B.
1019 The model provides an easy way to setup this connection using the
1020 extranet-vpns container.
1022 The extranet-vpns container defines a list of VPNs, a particular VPN
1023 wants to access. The extranet-vpns must be used on "customer" VPNs
1024 accessing extranet resources in another VPN. In the figure above, in
1025 order to give access for VPN A to VPN B, extranet-vpns container will
1026 be configured under VPN A with an entry corresponding to VPN B and
1027 there is no service configuration requirement on VPN B.
1029 Readers should note that even if there is no configuration
1030 requirement on VPN B, if VPN A lists VPN B as extranet, all sites in
1031 VPN B will gain access to all sites in VPN A.
1033 The site-role leaf defines the role of the local VPN sites in the
1034 target extranet VPN service topology. Site roles are defined in
1035 Section 5.4. Based on this, the requirements described in
1036 Section 5.4 regarding the site-role leaf are also applicable here.
1038 In the example below, VPN A accesses to VPN B resources through
1039 extranet connection, a spoke role is required for VPN A sites, so
1040 sites from VPN A must not be able to communicate between each other
1041 through the extranet VPN connection.
1043
1044 VPNB
1045 hub-spoke
1046
1047
1048 VPNA
1049 any-to-any
1050
1051
1052 VPNB
1053 spoke-role
1054
1055
1056
1058 This model does not define how the extranet configuration will be
1059 achieved.
1061 Any more complex VPN connection service topology (e.g. only part of
1062 sites of VPN A accessing only part of sites of VPN B) needs to be
1063 achieved using the vpn attachment defined in Section 5.5.2.
1065 5.3. Site overview
1067 A site represents a connection of a customer location to one or more
1068 VPN services.
1070 +-------------+
1071 / \
1072 +------------------+ +-----| VPN1 |
1073 | | | \ /
1074 | New York Office | ----- (site) -----+ +-------------+
1075 | | | +-------------+
1076 +------------------+ | / \
1077 +-----| VPN2 |
1078 \ /
1079 +-------------+
1081 A site is composed of some characteristics :
1083 o Unique identifier (site-id) : to uniquely identify the site within
1084 the overall network infrastructure. The identifier is a string
1085 allowing to any encoding for the local administration of the VPN
1086 service.
1088 o Locations (locations) : site location information to allow easy
1089 retrieval on nearest available resources. A site may be composed
1090 of multiple locations.
1092 o Devices : the customer can request one or more customer premise
1093 equipments from the service provider for a particular site.
1095 o Management (management) : defines the model of management of the
1096 site, for example : co-managed, customer managed or provider
1097 managed.
1099 o Site network accesses (site-network-accesses) : defines the list
1100 of network accesses associated to the sites and their properties :
1101 especially bearer, connection and service parameters.
1103 A site-network-access represents an IP logical connection of a site.
1104 A site may have multiple site-network-accesses.
1106 +------------------+ Site
1107 | |-----------------------------------
1108 | |****** (site-network-access#1) ******
1109 | New York Office |
1110 | |****** (site-network-access#2) ******
1111 | |-----------------------------------
1112 +------------------+
1114 Multiple site-network-accesses are used for instance in case of
1115 multihoming. Some other connection cases may also involve multiple
1116 site-network-accesses.
1118 The site configuration is viewed as a global entity, we assume that
1119 it is mostly the role of the management to split the parameters
1120 between the different elements within the network. For example, in
1121 the case of the site-network-access configuration, the management
1122 system needs to split the overall parameters between PE configuration
1123 and CE configuration.
1125 5.3.1. Devices and locations
1127 A site may be composed of multiple locations. All the locations will
1128 need to be configured as part of the locations container and list. A
1129 typical example of multi-location site is a headquarter in a city
1130 composed of multiple building. Those building may be located in
1131 different parts of the city and may be linked by intra-city fibers
1132 (customer metro network). In such case, when connecting to a VPN
1133 service, the customer may want to implement multihoming based on its
1134 distributed locations.
1136 New York Site
1138 +------------------+ Site
1139 | +--------------+ |-----------------------------------
1140 | | Manhattan | |****** (site-network-access#1) ******
1141 | +--------------+ |
1142 | +--------------+ |
1143 | | Brooklyn | |****** (site-network-access#2) ******
1144 | +--------------+ |
1145 | |-----------------------------------
1146 +------------------+
1148 A customer may also requests some premise equipments (CEs) to the
1149 service provider through the "devices" container. Requesting a CE
1150 implies a provider-managed or co-managed model. A particular device
1151 must be ordered to a particular already configured location. This
1152 would help the service provider to send the device to the appropriate
1153 installation address. In a multilocation site, a customer may for
1154 example request a CE for each location on the site where multihoming
1155 must be implemented. In the figure above, one device may be
1156 requested for Manhattan location and one other for Brooklyn location.
1158 By using devices and locations, the user will be to influence the
1159 multihoming scenario he wants to implement : single CE, dual CE ...
1161 5.3.2. Site network accesses
1163 As mentioned, a site may be multihomed. Each IP network access for a
1164 site is defined in the site-network-accesses list. The site-network-
1165 access defines how the site is connected on the network and is split
1166 into three main classes of parameters :
1168 o bearer : defines requirements of the attachment (below Layer 3).
1170 o connection : defines Layer 3 protocol parameters of the
1171 attachment.
1173 o availability : defines the site availability policy. Availability
1174 is defined in Section 5.7
1176 Some parameters from the site can be configured also at the site-
1177 network-access level like : routing, services, security ... Defining
1178 parameters only at site level will provide inheritance. If a
1179 parameter is configured at both site and access level, the access
1180 level parameter MUST override the site level parameter. Those
1181 parameters will be described later in the document.
1183 The site-network-access has a specific type (site-network-access-
1184 type). This documents defines two types :
1186 o point-to-point: describes a point to point connection between the
1187 service provider and the customer.
1189 o multipoint: describes a multipoint connection between the service
1190 provider and the customer.
1192 The type of site-network-access may have an impact on the parameters
1193 offered to the customer, e.g. : a service provider may not offer
1194 encryption for multipoint accesses. Deciding what parameter is
1195 supported for point-to-point and/or multipoint accesses is up to the
1196 provider and is out of scope of this document. Some containers
1197 proposed in the model may require extension in order to work properly
1198 for multipoint accesses.
1200 5.3.2.1. Bearer
1202 Bearer defines the requirements for the site attachment to the
1203 provider network that are below Layer 3.
1205 The bearer parameters will help to decide the access media to be
1206 used. This is further described in Section 5.6.3.
1208 5.3.2.2. Connection
1210 The connection defines the protocol parameters of the attachment
1211 (IPv4 and IPv6). Depending of the management mode, it refers to the
1212 PE-CE addressing or CE to customer LAN addressing. In any case, it
1213 describes the provider to customer responsibility boundary. For a
1214 customer managed site, it refers to the PE-CE connection. For a
1215 provider managed site, it refers to the CE to LAN connection.
1217 5.3.2.2.1. IP addressing
1219 IP subnet can be configured for either transport protocols. For a
1220 dual stack connection, two subnets will be provided, one for each
1221 transport layer.
1223 The address-allocation-type will help in defining how the address
1224 allocation MUST be done. The current model proposes three ways of IP
1225 address allocation :
1227 o provider-dhcp : the provider will provide DHCP service for
1228 customer equipments, this is applicable to both IPv4 and IPv6
1229 addressing.
1231 o provider-dhcp-relay : the provider will provide DHCP relay service
1232 for customer equipments, this is applicable to both IPv4 and IPv6
1233 addressing. The customer needs to fill DHCP server list to be
1234 used.
1236 o static-address : Addresses will be assigned manually, this is
1237 applicable to both IPv4 and IPv6 addressing.
1239 o slaac : enables stateless address autoconfiguration ([RFC4862]).
1240 This is applicable only for IPv6.
1242 In the dynamic addressing mechanism, it is expected from service
1243 provider to provide at least the IP address, mask and default gateway
1244 information.
1246 5.3.2.2.2. OAM
1248 A customer may require a specific IP connectivity fault detection
1249 mechanism on the IP connection. As BFD is a popular implementation,
1250 the model supports its modeling as mechanism proposed to the
1251 customer. This can be extended with other mechanisms by
1252 augmentation. The provider can propose some profiles to the customer
1253 depending of the service level the customer wants to achieve.
1254 Profile names must be communicated to the customer. This
1255 communication is out of scope of this document. Some fixed values
1256 for the holdtime period may also be imposed by the customer if the
1257 provider enables it.
1259 The OAM container can easily be augmented by other mechanisms,
1260 especially work from LIME Working Group may be reused.
1262 5.3.2.3. Inheritance of parameters between site and site-network-access
1264 Some parameters are available both at site level and site-network-
1265 access level. Defining a parameter at site level will provide
1266 inheritance to all site-network-accesses under the site. If a site-
1267 network-access has a parameter configured that is already defined at
1268 site level, the site-network-access parameter value will replace the
1269 site parameter value.
1271 In term of provisionning impact, it will be up to the implementation
1272 to decide of the appropriate behavior when modifying existing
1273 configurations. But the service provider will need to communicate to
1274 user about the impact of using inheritance. For example, if we
1275 consider that a site has 3 already provisionned site-network-
1276 accesses. What will happen if customer is changing a service
1277 parameter at site level ? An implementation of this model may update
1278 the service parameters of all already provisionned site-network-
1279 accesses (with potential impact on live traffic) or it may decide to
1280 take into account this new parameter for only the new sites.
1282 5.4. Site role
1284 A VPN has a particular service topology as described in
1285 Section 5.2.1. As a consequence, each site belonging to a VPN is
1286 assigned with a particular role in this topology. The site-role
1287 defines the role of the site in a particular VPN topology.
1289 In the any-to-any VPN service topology, all sites MUST have the same
1290 role which is any-to-any-role.
1292 In the hub-spoke or hub-spoke-disjoint VPN service topology, sites
1293 MUST have a hub-role or a spoke-role.
1295 5.5. Site belonging to multiple VPNs
1297 5.5.1. Site vpn flavor
1299 A site may be part of one or multiple VPNs. The site flavor defines
1300 the way the VPN multiplexing is done. The current version of the
1301 model supports four flavors:
1303 o site-vpn-flavor-single: the site belongs to only one VPN.
1305 o site-vpn-flavor-multi: the site belongs to multiple VPNs and all
1306 the logical accesses of the sites belongs to the same set of VPNs.
1308 o site-vpn-flavor-sub: the site belongs to multiple VPNs with
1309 multiple logical accesses. Each logical access may map to
1310 different VPNs (one or many).
1312 o site-vpn-flavor-nni: the site represents an option A NNI.
1314 5.5.1.1. Single VPN attachment : site-vpn-flavor-single
1316 The figure below describes the single VPN attachment. The site
1317 connects to only one VPN.
1319 +--------+
1320 +------------------+ Site / \
1321 | |-----------------------------| |
1322 | |***(site-network-access#1)***| VPN1 |
1323 | New York Office | | |
1324 | |***(site-network-access#2)***| |
1325 | |-----------------------------| |
1326 +------------------+ \ /
1327 +--------+
1329 5.5.1.2. Multi VPN attachment : site-vpn-flavor-multi
1331 The figure below describes the multi VPN attachment. The site
1332 connects to multiple VPNs.
1334 +---------+
1335 +---/----+ \
1336 +------------------+ Site / | \ |
1337 | |--------------------------------- | |VPNB |
1338 | |***(site-network-access#1)******* | | |
1339 | New York Office | | | | |
1340 | |***(site-network-access#2)******* \ | /
1341 | |-----------------------------| VPNA +-----|---+
1342 +------------------+ \ /
1343 +--------+
1345 In the example above, the New York office is multihomed, both logical
1346 accesses are using the same VPN attachment rules. Both logical
1347 accesses are so connected to VPNA and VPNB.
1349 Reaching VPN A or VPN B from New York office will be based on
1350 destination based routing. Having the same destination reachable
1351 from the two VPNs may cause routing troubles. This would be the role
1352 of the customer administration to ensure the appropriate mapping of
1353 its prefixes in each VPN.
1355 5.5.1.3. Sub VPN attachment : site-vpn-flavor-sub
1357 The figure below describes a sub VPN attachment. The site connects
1358 to multiple VPNs but each logical access is attached to a particular
1359 set of VPN. Typical use case of subVPN is a customer site used by
1360 multiple affiliates with private resources for each affiliates that
1361 cannot be shared (communication is prevented between the affiliates).
1362 It is similar than having separate sites instead that the customer
1363 wants to share some physical components while keeping strong
1364 communication isolation between affiliates. In the example, the
1365 access#1 is attached to VPNB while the access#2 is attached to VPNA.
1367 +------------------+ Site +--------+
1368 | |----------------------------------/ \
1369 | |****(site-network-access#1)******| VPNB |
1370 | New York Office | \ /
1371 | | +--------+
1372 | | +--------+
1373 | | / \
1374 | |****(site-network-access#2)******| VPNA |
1375 | | \ /
1376 | | +--------+
1377 | |-----------------------------------
1378 +------------------+
1380 Multi-VPN can be implemented in addition to subVPN, as a consequence,
1381 each site-network-access can access to multiple VPNs. In the example
1382 below, access#1 is mapped to VPNB and VPNC, while access#2 is mapped
1383 to VPNA and VPND.
1385 +------------------+ Site +-----+
1386 | |----------------------------------/ +----+
1387 | |****(site-network-access#1)******| VPNB / \
1388 | New York Office | \ | VPN C |
1389 | | +----\ /
1390 | | +-----+
1391 | |
1392 | | +------+
1393 | | / +-----+
1394 | |****(site-network-access#2)******| VPNA / \
1395 | | \ | VPN D |
1396 | | +------\ /
1397 | |----------------------------------- +---+
1398 +------------------+
1400 Multihoming is also possible with subVPN, in this case, site-network-
1401 accesses are grouped, and a particular group will access to the same
1402 set of VPN. In the example below, access#1 and #2 are part of the
1403 same group (multihomed together) and will be mapped to VPN B and C,
1404 in addition access#3 and #4 are part of the same group (multihomed
1405 together) and will be mapped to VPN A and D.
1407 +------------------+ Site +-----+
1408 | |----------------------------------/ +----+
1409 | |****(site-network-access#1)******| VPNB / \
1410 | New York Office |****(site-network-access#2)******\ | VPN C |
1411 | | +----\ /
1412 | | +-----+
1413 | |
1414 | | +------+
1415 | | / +-----+
1416 | |****(site-network-access#3)******| VPNA / \
1417 | |****(site-network-access#4)****** \ | VPN D |
1418 | | +------\ /
1419 | |----------------------------------- +---+
1420 +------------------+
1422 In term of service configuration, subvpn can be achieved by
1423 requesting the site-network-accesses to use the same bearer (see
1424 Section 5.6.4 and Section 5.6.6.4 for more details).
1426 5.5.1.4. NNI : site-vpn-flavor-nni
1428 Some Network to Network Interface (NNI) may be modeled using the site
1429 container (see Section 5.15.1). Using the site container to model
1430 NNI is only one possible option for NNI (see Section 5.15). This
1431 option is called option A by reference to option A NNI defined in
1432 [RFC4364]. It is helpful for the service provider to identify that
1433 the requested VPN connection is not a regular site but a NNI as
1434 specific default device configuration parameters may be applied in
1435 case of NNI (example ACLs, routing policies ...).
1437 SP A SP B
1438 --------------------- --------------------
1439 / \ / \
1440 | | | |
1441 | ++++++++ InterAS link ++++++++ |
1442 | + +_____________ + + |
1443 | + (VRF1)--(VPN1)----(VRF1) + |
1444 | + ASBR + + ASBR + |
1445 | + (VRF2)--(VPN2)----(VRF2) + |
1446 | + +______________+ + |
1447 | ++++++++ ++++++++ |
1448 | | | |
1449 | | | |
1450 | | | |
1451 | ++++++++ InterAS link ++++++++ |
1452 | + +_____________ + + |
1453 | + (VRF1)--(VPN1)----(VRF1) + |
1454 | + ASBR + + ASBR + |
1455 | + (VRF2)--(VPN2)----(VRF2) + |
1456 | + +______________+ + |
1457 | ++++++++ ++++++++ |
1458 | | | |
1459 | | | |
1460 \ / \ /
1461 -------------------- -------------------
1463 The figure above describes an option A NNI scenario that could be
1464 modeled using the site container. In order to connect its customer
1465 VPN (VPN1 and VPN2) on SP B network, SP A may request creation of
1466 some site-network-accesses to SP B. The site-vpn-flavor-nni will be
1467 used to inform SP B that this is a NNI and not a regular customer
1468 site. The site-vpn-flavor-nni may be multihomed and multiVPN as
1469 well.
1471 5.5.2. Attaching a site to a VPN
1473 Due to the multiple site vpn flavors, the attachment is done at the
1474 site-network-access (logical access) level through the vpn-attachment
1475 container. The vpn-attachment container is mandatory. The model
1476 provides two ways of attachment :
1478 o Referencing directly the target VPN.
1480 o Reference a VPN policy for more complex attachments.
1482 A choice is implemented to allow user to choose the best fitting
1483 flavor.
1485 5.5.2.1. Reference a VPN
1487 Referencing a vpn-id provides an easy way to attach a particular
1488 logical access to a VPN. This is the best way in case of single VPN
1489 attachment or subVPN with single VPN attachment per logical access.
1490 When referencing a vpn-id, the site-role must be added to express the
1491 role of the site in the target VPN service topology.
1493
1494 SITE1
1495
1496
1497 LA1
1498
1499 VPNA
1500 spoke-role
1501
1502
1503 LA2
1504
1505 VPNB
1506 spoke-role
1507
1508
1509
1510
1512 The example above describes a subVPN case where a site SITE1 has two
1513 logical accesses (LA1 and LA2) with LA1 attached to VPNA and LA2
1514 attached to VPNB.
1516 5.5.2.2. VPN policy
1518 The vpn-policy helps to express a multiVPN scenario where a logical
1519 access belongs to multiple VPNs. Multiple VPN policy can be created
1520 to handle the subVPN case where each logical access is part of a
1521 different set of VPNs.
1523 As a site can belong to multiple VPNs, the vpn-policy may be composed
1524 of multiple entries. A filter can be applied to specify that only
1525 some LANs of the site should be part of a particular VPN. Each time
1526 a site (or LAN) is attached to a VPN, we must precisely describe its
1527 role (site-role) within the targeted VPN service topology.
1529 +--------------------------------------------------------------+
1530 | VPN2_Site3 ------ PE7 |
1531 +-------------------------+ |
1532 | |
1533 +-------------------------+ |
1534 | VPN2_Site1 ------ PE3 PE4 ------ VPN2_Site2 |
1535 +----------------------------------+ |
1536 | |
1537 +------------------------------------------------------------+ |
1538 | VPN3_Site1 ------ PE5 | PE6 ------ VPN3_Site2 | |
1539 +------------------------------------------------------------+ |
1540 | |
1541 +---------------------------+
1543 In the example above, VPN3_Site2 is part of two VPNs : VPN3 and VPN2.
1544 It will play hub-role in VPN2 and any-to-any role in VPN3. We can
1545 express such multiVPN scenario as follows :
1547
1548 VPN3_Site2
1549
1550
1551 POLICY1
1552
1553 ENTRY1
1554
1555 VPN2
1556 hub-role
1557
1558
1559
1560 ENTRY2
1561
1562 VPN3
1563 any-to-any-role
1564
1565
1566
1567
1568
1569
1570 LA1
1571
1572 POLICY1
1573
1574
1575
1576
1578 Now in case more specific VPN attachment is necessary, filtering can
1579 be used. For example, if LAN1 from VPN3_site2 must be attached to
1580 VPN2 as hub and LAN2 must be attached to VPN3, the following
1581 configuration can be used :
1583
1584 VPN3_Site2
1585
1586
1587 POLICY1
1588
1589 ENTRY1
1590
1591 LAN1
1592
1593
1594 VPN2
1595 hub-role
1596
1597
1598
1599 ENTRY2
1600
1601 LAN2
1602
1603
1604 VPN3
1605 any-to-any-role
1606
1607
1608
1609
1610
1611
1612 LA1
1613
1614 POLICY1
1615
1616
1617
1618
1620 5.6. Deciding where to connect the site
1622 The management system will have to decide where to connect each site-
1623 network-access of a particular site to the provider network (PE,
1624 aggregation switch ...).
1626 The current model proposes parameters and constraints that will help
1627 the management system to decide where to attach the site-network-
1628 access.
1630 The management system SHOULD honor the customer constraints, if the
1631 constraint is too strict and can not be filled, the management system
1632 MUST not provision the site and SHOULD provide an information to the
1633 user. How the information is provided is out of scope of the
1634 document. It would then be up to the user to relax the constraint or
1635 not.
1637 Parameters are just hints for the management system for service
1638 placement.
1640 In addition to parameters and constraints : the management system
1641 decision MAY be based on any other internal constraint that are up to
1642 the service provider : least load, distance ...
1644 5.6.1. Constraint : Device
1646 In case of provider-management or co-management, one or more devices
1647 have been ordered by the customer. The customer may decide to force
1648 a particular site-network-access to be connected on a particular
1649 device he ordered.
1651 New York Site
1653 +------------------+ Site
1654 | +--------------+ |-----------------------------------
1655 | | Manhattan | |
1656 | | CE1********* (site-network-access#1) ******
1657 | +--------------+ |
1658 | +--------------+ |
1659 | | Brooklyn CE2********* (site-network-access#2) ******
1660 | +--------------+ |
1661 | |-----------------------------------
1662 +------------------+
1664 In the figure above, the site-network-access#1 is associated to CE1,
1665 so the service provider MUST ensure the provisionning of this
1666 connection.
1668 5.6.2. Constraint/parameter : Site location
1670 The location information provided in this model MAY be used by a
1671 management system to decide the target PE to mesh the site (service
1672 provider side). A particular location must be associated to each
1673 site network access when configuring it. The service provider MUST
1674 honor the termination of the access on the location associated with
1675 the site network access (customer side).
1677 The site-network-access location is determined by the "location-
1678 flavor". In case of provider-managed or co-managed site, the user is
1679 expected to configure a "device-reference" (device case) that would
1680 bind the site-network-access to a particular device the customer
1681 ordered. As each device is already associated to a particular
1682 location, in such case the location information that would help the
1683 placement is retrieved from the device location. In case of
1684 customer-managed site, the user is expected to configure a "location-
1685 reference" (location case), this would provide a reference to an
1686 existing configured location that would help the placement.
1688 PoP#1 (New York)
1689 +---------+
1690 | PE1 |
1691 Site #1 ---... | PE2 |
1692 (Atlantic City) | PE3 |
1693 +---------+
1695 PoP#2 (Washington)
1696 +---------+
1697 | PE4 |
1698 | PE5 |
1699 | PE6 |
1700 +---------+
1702 PoP#3 (Philadelphia)
1703 +---------+
1704 | PE7 |
1705 Site #2 CE#1---... | PE2 |
1706 (Reston) | PE9 |
1707 +---------+
1709 In the example above, Site#1 is a customer managed site with a
1710 location L1, while Site#2 is a provider-managed site for which a CE#1
1711 was ordered, Site#2 is configured with L2 as location. When
1712 configuring a site-network-access for Site#1, the user will need to
1713 reference the location L1, so the management system will know that
1714 the access will need to terminate on this location. Then this
1715 management system may decide to mesh Site#1 on a PE from Philadelphia
1716 PoP for distance reason. It may also take into account resources
1717 available on PEs to decide the exact target PE (least load).
1718 Regarding Site#2, the user is expected to configure the site-network-
1719 access with a device-reference to CE#1, so the management system will
1720 know that the access must terminate on the location of CE#1 and must
1721 be connected to CE#1. For placing the service provider side of the
1722 access connection, in case of shortest distance PE used, it may
1723 decide to mesh Site #2 on Washington PoP.
1725 5.6.3. Constraint/parameter : access type
1727 The management system will need to elect the access method to connect
1728 the site to the customer (for example : PPP over ISDN, xSDL, leased
1729 line, Ethernet backhaul ...). The customer may provide some
1730 parameters/constraints that will provide hints to the management
1731 system.
1733 The bearer container information SHOULD be used as first input :
1735 o The "requested-type" provides an information about the media type
1736 the customer would like. If the "strict" leaf is equal to "true",
1737 this MUST be considered as a strict constraint, so the management
1738 system cannot connect the site with another media type. If the
1739 "strict" leaf is equal to "false" (default), if the requested-type
1740 cannot be fulfilled, the management system can select another
1741 type. The supported media types SHOULD be communicated by the
1742 service provider to the customer by a mechanism that is out of
1743 scope of the document.
1745 o The "always-on" leaf defines a strict constraint : if set to
1746 "true", the management system MUST elect a media type which is
1747 always-on (this means no Dial access type).
1749 o The "bearer-reference" is used in case the customer has already
1750 ordered a network connection to the service provider apart of the
1751 IPVPN site and wants to reuse this connection. The string used in
1752 an internal reference from the service provider describing the
1753 already available connection. This is also a strict requirement
1754 that cannot be relaxed. How the reference is given to the
1755 customer is out of scope of the document but as a pure example,
1756 when the customer ordered the bearer (through a process out of
1757 this model), the service provider may had provided the bearer
1758 reference that can be used for provisionning services on top.
1760 Other parameters like the requested svc-input-bandwidth, svc-output-
1761 bandwidth MAY help to decide the access type to be used. Any other
1762 internal parameters from the service provider can be used in
1763 addition.
1765 5.6.4. Constraint : access diversity
1767 Each site-network-access may have one or more constraints that would
1768 drive the placement of the access. By default, the model assumes no
1769 constraint but is expected allocation of a unique bearer per site-
1770 network-access.
1772 In order to help the different placement scenarios, a site-network-
1773 access may be tagged using one or multiple group identifiers. The
1774 group identifier is a string so can accommodate both explicit naming
1775 of a group of sites (e.g. "multi-homed-set1" or "subvpn") or using a
1776 numbered id (e.g. 12345678). The meaning of each group-id is local
1777 to each customer administrator. And the management system MUST
1778 ensure that different customers can use the same group-ids. One or
1779 more group-id can also be defined at site-level, as a consequence,
1780 all site-network-accesses under the site MUST inherit the group-ids
1781 of the site they are belonging to. When, in addition to the site
1782 group-ids, some group-ids are defined at site-network-access level,
1783 the management system MUST consider the union of all groups (site
1784 level and site network access level) for this particular site network
1785 access.
1787 For a particular currently configured site-network-access, each
1788 constraint MUST be expressed against a targeted set of site-network-
1789 accesses, the currently configured site-network-access MUST never be
1790 taken into account in the targeted set : e.g. "I want my current
1791 site-network-access to be not be connected on the same PoP as the
1792 site-network-accesses that are part of group 10". The set of site-
1793 network-accesses against which the constraint is evaluated can be
1794 expressed as a list of groups or all-other-accesses or all-other-
1795 groups. "all-other-accesses" means that the current site-network-
1796 access constraint MUST be evaluated against all the other site-
1797 network-accesses belonging to the current site. "all-other-groups"
1798 means that the constraint MUST be evaluated against all groups the
1799 current site-network-access is not belonging to.
1801 The current model proposes multiple constraint-types :
1803 pe-diverse : the current site-network-access MUST not be connected
1804 to the same PE as the targeted site-network-accesses.
1806 pop-diverse : the current site-network-access MUST not be
1807 connected to the same PoP as the targeted site-network-accesses.
1809 linecard-diverse : the current site-network-access MUST not be
1810 connected to the same linecard as the targeted site-network-
1811 accesses.
1813 same-pe : the current site-network-access MUST be connected to the
1814 same PE as the targeted site-network-accesses.
1816 same-bearer : the current site-network-access MUST be connected
1817 using the same bearer as the targeted site-network-accesses.
1819 Those constraint-types could be extended through augmentation.
1821 Each constraint is expressed as "I want my current site-network-
1822 access to be (e.g. pe-diverse, pop-diverse) from
1823 those site-network-accesses". In addition,
1825 The group-id used to target some site-network-accesses may be the
1826 same as the one used by the current site-network-access. This ease
1827 configuration of scenarios where a group of site-network-access has a
1828 constraint between each other. As an example if we want a set of
1829 sites (site#1 up to #5) to be all connected on a different PE, we can
1830 tag them with the same group-id and express a pe-diverse constraint
1831 for this group-id.
1833
1834 SITE1
1835
1836
1837 1
1838
1839
1840
1841 10
1842
1843
1844
1845
1846 pe-diverse
1847
1848
1849 10
1850
1851
1852
1853
1854
1855
1856 VPNA
1857 spoke-role
1858
1859
1860
1861
1862
1863 SITE2
1864
1865
1866 1
1867
1868
1869
1870 10
1871
1872
1873
1874
1875 pe-diverse
1876
1877
1878 10
1879
1880
1881
1882
1883
1884
1885 VPNA
1886 spoke-role
1887
1888
1889
1890
1891 ...
1892
1893 SITE5
1894
1895
1896 1
1897
1898
1899
1900 10
1901
1902
1903
1904
1905 pe-diverse
1906
1907
1908 10
1909
1910
1911
1912
1913
1914
1915 VPNA
1916 spoke-role
1918
1919
1920
1921
1923 The group-id used to target some site-network-accesses may be also
1924 different as the one used by the current site-network-access. This
1925 is used to express that a group of site has some constraint against
1926 another group of sites, but there may not be constraint inside the
1927 group itself. As an example, if we consider a set of 6 sites with
1928 two sets and we want to ensure that a site in the first set must be
1929 pop-diverse from a site in the second set.
1931
1932 SITE1
1933
1934
1935 1
1936
1937
1938
1939 10
1940
1941
1942
1943
1944 pop-diverse
1945
1946
1947 20
1948
1949
1950
1951
1952
1953
1954 VPNA
1955 spoke-role
1956
1957
1958
1959
1960
1961 SITE2
1962
1963
1964 1
1965
1966
1967
1968 10
1969
1970
1971
1972
1973 pop-diverse
1974
1975
1976 20
1977
1978
1979
1980
1981
1982
1983 VPNA
1984 spoke-role
1985
1986
1987
1988
1989 ...
1990
1991 SITE5
1992
1993
1994 1
1995
1996
1997
1998 20
1999
2000
2001
2002
2003 pop-diverse
2004
2005
2006 10
2007
2008
2009
2010
2011
2012
2013 VPNA
2014 spoke-role
2015
2016
2017
2018
2019
2020 SITE6
2021
2022
2023 1
2024
2025
2026
2027 20
2028
2029
2030
2031
2032 pop-diverse
2033
2034
2035 10
2036
2037
2038
2039
2040
2041
2042 VPNA
2043 spoke-role
2044
2045
2046
2047
2049 5.6.5. Impossible access placement
2051 Some impossible placement scenarios may be created through the
2052 proposed configuration framework. Impossible scenarios could be too
2053 restrictive constraints leading to impossible placement in the
2054 network or conflicting constraints that would also lead to impossible
2055 placement. An example of conflicting rules would be to ask a site-
2056 network-access#1 to be pe-diverse from a site-network-access#2 and to
2057 ask at the same time that site-network-access#2 to be on the same PE
2058 as site-network-access#1. When the management system cannot place
2059 the access, it SHOULD return an error message indicating that
2060 placement was not possible.
2062 5.6.6. Examples of access placement
2064 5.6.6.1. Multihoming
2066 The customer wants to create a multihomed site. The site will be
2067 composed of two site-network-accesses and the customer wants the two
2068 site-network-accesses to be meshed on different PoPs for resiliency
2069 purpose.
2071 PoP#1
2072 +-------+ +---------+
2073 | | | PE1 |
2074 | |---site_network_access#1 ---- | PE2 |
2075 | | | PE3 |
2076 | | +---------+
2077 | Site#1|
2078 | | PoP#2
2079 | | +---------+
2080 | | | PE4 |
2081 | |---site_network_access#2 ---- | PE5 |
2082 | | | PE6 |
2083 | | +---------+
2084 +-------+
2086 This scenario could be expressed in the following way :
2088
2089 SITE1
2090
2091
2092 1
2093
2094
2095
2096 10
2097
2098
2099
2100
2101 pop-diverse
2102
2103
2104 20
2105
2106
2107
2108
2109
2110
2111 VPNA
2112 spoke-role
2113
2114
2115
2116 2
2117
2118
2119
2120 20
2121
2122
2123
2124
2125 pop-diverse
2126
2127
2128 10
2129
2130
2131
2132
2133
2134
2135 VPNA
2136 spoke-role
2137
2138
2139
2140
2142 But it can also be expressed as :
2144
2145 SITE1
2146
2147
2148 1
2149
2150
2151
2152 pop-diverse
2153
2154
2155
2156
2157
2158
2159
2160 VPNA
2161 spoke-role
2162
2163
2164
2165 2
2166
2167
2168
2169 pop-diverse
2170
2171
2172
2173
2174
2175
2176
2177 VPNA
2178 spoke-role
2179
2180
2181
2182
2184 5.6.6.2. Site offload
2186 The customer has a 6 branch offices in a particular region and he
2187 wants to prevent to have all branch offices on the same PE.
2189 He wants to express that 3 branch offices cannot be connected on the
2190 same linecard. But the other branch offices must be connected on a
2191 different PoP. Those other branch offices cannot also be connected
2192 on the same linecard.
2194 PoP#1
2195 +---------+
2196 | PE1 |
2197 Office#1 ---... | PE2 |
2198 Office#2 ---... | PE3 |
2199 Office#3 ---... | PE4 |
2200 +---------+
2202 PoP#2
2203 +---------+
2204 Office#4 ---... | PE4 |
2205 Office#5 ---... | PE5 |
2206 Office#6 ---... | PE6 |
2207 +---------+
2209 This scenario could be expressed in the following way :
2211 o We need to create two sets of sites : set#1 composed of Office#1
2212 up to 3, set#2 composed of Office#4 up to 6.
2214 o Sites within set#1 must be pop-diverse from sites within set#2 and
2215 vice versa.
2217 o Sites within set#1 must be linecard-diverse from other sites in
2218 set#1 (same for set#2).
2220
2221 SITE1
2222
2223
2224 1
2225
2226
2227
2228 10
2229
2230
2231
2232
2233 pop-diverse
2234
2235
2236 20
2237
2238
2239
2240
2241 linecard-diverse
2242
2243
2244 10
2245
2246
2247
2248
2249
2250
2251 VPNA
2252 spoke-role
2253
2254
2255
2256
2257 SITE2
2258
2259
2260 1
2261
2262
2263
2264 10
2265
2266
2267
2268
2269 pop-diverse
2270
2271
2272 20
2273
2274
2275
2276
2277 linecard-diverse
2278
2279
2280 10
2281
2282
2283
2285
2286
2287
2288 VPNA
2289 spoke-role
2290
2291
2292
2293
2294 SITE3
2295
2296
2297 1
2298
2299
2300
2301 10
2302
2303
2304
2305
2306 pop-diverse
2307
2308
2309 20
2310
2311
2312
2313
2314 linecard-diverse
2315
2316
2317 10
2318
2319
2320
2321
2322
2323
2324 VPNA
2325 spoke-role
2326
2327
2328
2329
2331
2332 SITE4
2333
2334
2335 1
2336
2337
2338
2339 20
2340
2341
2342
2343
2344 pop-diverse
2345
2346
2347 10
2348
2349
2350
2351
2352 linecard-diverse
2353
2354
2355 20
2356
2357
2358
2359
2360
2361
2362 VPNA
2363 spoke-role
2364
2365
2366
2367
2368 SITE5
2369
2370
2371 1
2372
2373
2374
2375 20
2376
2377
2378
2379
2380 pop-diverse
2381
2382
2383 10
2384
2385
2386
2387
2388 linecard-diverse
2389
2390
2391 20
2392
2393
2394
2395
2396
2397
2398 VPNA
2399 spoke-role
2400
2401
2402
2403
2404 SITE6
2405
2406
2407 1
2408
2409
2410
2411 20
2412
2413
2414
2415
2416 pop-diverse
2417
2418
2419 10
2420
2421
2422
2423
2424 linecard-diverse
2425
2426
2427 20
2428
2430
2431
2432
2433
2434
2435 VPNA
2436 spoke-role
2437
2438
2439
2440
2442 5.6.6.3. Parallel links
2444 To increase its site bandwidth at a cheaper cost, a customer wants to
2445 order to parallel site-network-accesses that will be connected to the
2446 same PE.
2448 *******SNA1**********
2449 Site 1 *******SNA2********** PE1
2451 This scenario could be expressed in the following way :
2453
2454 SITE1
2455
2456
2457 1
2458
2459
2460
2461 PE-linkgrp-1
2462
2463
2464
2465
2466 same-pe
2467
2468
2469 PE-linkgrp-1
2470
2471
2472
2473
2474
2475
2476 VPNB
2477 spoke-role
2478
2479
2480
2481 2
2482
2483
2484
2485 PE-linkgrp-1
2486
2487
2488
2489
2490 same-pe
2491
2492
2493 PE-linkgrp-1
2494
2495
2496
2497
2498
2499
2500 VPNB
2501 spoke-role
2502
2503
2504
2505
2507 5.6.6.4. SubVPN with multihoming
2509 A customer has site which is dual-homed, the dual-homing must be done
2510 on two different PEs. The customer wants also to implement two
2511 subVPNs on those multi-homed accesses.
2513 +------------------+ Site +-----+
2514 | |----------------------------------/ +----+
2515 | |****(site-network-access#1)******| VPNB / \
2516 | New York Office |****(site-network-access#2)*************| VPN C |
2517 | | +----\ /
2518 | | +-----+
2519 | |
2520 | | +------+
2521 | | / +-----+
2522 | |****(site-network-access#3)******| VPNB / \
2523 | |****(site-network-access#4)**************| VPN C |
2524 | | +------\ /
2525 | |----------------------------------- +---+
2526 +------------------+
2528 This scenario could be expressed in the following way :
2530 o The site will have 4 site network accesses (2 subVPN coupled with
2531 dual homing).
2533 o Site-network-access#1 and #3 will correspond to the multihoming of
2534 the subVPN B. A PE-diverse constraint is required between them.
2536 o Site-network-access#2 and #4 will correspond to the multihoming of
2537 the subVPN C. A PE-diverse constraint is required between them.
2539 o To ensure proper usage of the same bearer for the subVPN, site-
2540 network-access #1 and #2 must share the same bearer as site-
2541 network-access #3 and #4.
2543
2544 SITE1
2545
2546
2547 1
2548
2549
2550
2551 dual-homed-1
2552
2553
2554
2555
2556 pe-diverse
2557
2558
2559 dual-homed-2
2560
2562
2563
2564
2565 same-bearer
2566
2567
2568 dual-homed-1
2569
2570
2571
2572
2573
2574
2575 VPNB
2576 spoke-role
2577
2578
2579
2580 2
2581
2582
2583
2584 dual-homed-1
2585
2586
2587
2588
2589 pe-diverse
2590
2591
2592 dual-homed-2
2593
2594
2595
2596
2597 same-bearer
2598
2599
2600 dual-homed-1
2601
2602
2603
2604
2605
2606
2607 VPNC
2608 spoke-role
2609
2611
2612 3
2613
2614
2615
2616 dual-homed-2
2617
2618
2619
2620
2621 pe-diverse
2622
2623
2624 dual-homed-1
2625
2626
2627
2628
2629 same-bearer
2630
2631
2632 dual-homed-2
2633
2634
2635
2636
2637
2638
2639 VPNB
2640 spoke-role
2641
2642
2643
2644 4
2645
2646
2647
2648 dual-homed-2
2649
2650
2651
2652
2653 pe-diverse
2654
2655
2656 dual-homed-1
2657
2658
2660
2661
2662 same-bearer
2663
2664
2665 dual-homed-2
2666
2667
2668
2669
2670
2671
2672 VPNC
2673 spoke-role
2674
2675
2676
2677
2679 5.6.7. Route Distinguisher and VRF allocation
2681 Route distinguisher is also a critical parameter of PE-based L3VPN as
2682 described in [RFC4364] that will allow to distinguish common
2683 addressing plans in different VPNs. As for Route-targets, it is
2684 expected management system to allocate a VRF on the target PE and a
2685 route-distinguisher for this VRF.
2687 If a VRF exists on the target PE, and the VRF fulfils the
2688 connectivity constraints for the site, there is no need to recreate
2689 another VRF and the site MAY be meshed within this existing VRF. How
2690 the management system checks that an existing VRF fulfils the
2691 connectivity constraints for a site is out of scope of this document.
2693 If no VRF exists on the target PE, filling the site constraints, the
2694 management system will have to initiate a new VRF creation on the
2695 target PE and will have to allocate a new route distinguisher for
2696 this new VRF.
2698 The management system MAY apply a per-VPN or per-VRF allocation
2699 policy for the route-distinguisher depending of the service provider
2700 policy. In a per-VPN allocation policy, all VRFs (dispatched on
2701 multiple PEs) within a VPN will share the same route distinguisher
2702 value. In a per-VRF model, all VRFs will always have a unique route-
2703 distinguisher value. Some other allocation policies are also
2704 possible, and this document does not restrict the allocation policies
2705 to be used.
2707 Allocation of route-distinguisher MAY be done in the same way as the
2708 route-targets. The example provided in Section 5.2.1.1 could be
2709 reused.
2711 Note that a service provider MAY decide to configure target PE for
2712 automated allocation of route distinguisher. In this case, there
2713 will be no need for any backend system to allocate a route-
2714 distinguisher value.
2716 5.7. Site network access availability
2718 A site may be multihomed, so having multiple site-network-accesses.
2719 Placement constraints defined in previous sections will help to
2720 ensure physical diversity.
2722 When the site-network-accesses are placed on the network, a customer
2723 may want to use a particular routing policy on those accesses.
2725 The site-network-access/availability defines parameters for the site
2726 redundancy. The access-priority defines a preference for a
2727 particular access. This preference is used to model loadbalancing or
2728 primary/backup scenario. The highest the access-priority is, and the
2729 highest the preference will be.
2731 The figure below describes how access-priority attribute can be used.
2733 Hub#1 LAN (Primary/backup) Hub#2 LAN (Loadsharing)
2734 | |
2735 | access-priority 1 access-priority 1 |
2736 |--- CE1 ------- PE1 PE3 --------- CE3 --- |
2737 | |
2738 | |
2739 |--- CE2 ------- PE2 PE4 --------- CE4 --- |
2740 | access-priority 2 access-priority 1 |
2742 PE5
2743 |
2744 |
2745 |
2746 CE5
2747 |
2748 Spoke#1 site (Single-homed)
2750 In the figure above, Hub#2 requires loadsharing so all the site-
2751 network-accesses must use the same access-priority value. On the
2752 contrary, as Hub#1 requires primary/backup, a higher access-priority
2753 will be configured on the primary access.
2755 More complex scenario can be modeled. Let's consider a Hub site with
2756 5 accesses to the network (A1,A2,A3,A4,A5). The customer wants to
2757 loadshare traffic on A1,A2 in the nominal situation. If A1 and A2
2758 fails, he wants to loadshare traffic on A3 and A4, and finally if A1
2759 to A4 are down, he wants to use A5. We can model it easily by
2760 associating the following access-priorities : A1=100, A2=100, A3=50,
2761 A4=50, A5=10.
2763 The access-priority has some limitation. A scenario like the
2764 previous one with 5 accesses but with the constraint of having
2765 traffic loadshared between A3 and A4 in case of A1 OR A2 being down
2766 is not achievable. But the authors consider that the access-priority
2767 covers most of the deployment use cases and the model can still be
2768 extended by augmentation to support new use cases.
2770 5.8. Traffic protection
2772 The service model supports the ability to protect traffic for the
2773 site. Protection provides a better availability to multihoming by,
2774 for example, using local-repair techniques in case of failures. The
2775 associated level of service guarantee would be based on an agreement
2776 between customer and service provider and is out of scope of this
2777 document.
2779 Site#1 Site#2
2780 CE1 ----- PE1 -- P1 P3 -- PE3 ---- CE3
2781 | | |
2782 | | |
2783 CE2 ----- PE2 -- P2 P4 -- PE4 ---- CE4
2784 /
2785 /
2786 CE5 ----+
2787 Site#3
2789 In the figure above, we consider an IPVPN service with three sites
2790 including two dual homed sites (site#1 and #2). For dual homed
2791 sites, we consider PE1-CE1 and PE3-CE3 as primary, and
2792 PE2-CE2,PE4-CE4 as backup for the example (even if protection also
2793 applies to loadsharing scenarios.)
2795 In order to protect Site#2 against a failure, user may set the
2796 enabled leaf of traffic-protection to true on the site-network-
2797 accesses of site#2. How the traffic protection will be implemented
2798 is out of scope of the document. But as an example, in such case, if
2799 we consider traffic coming from a remote site (site#1 or site#3),
2800 primary path is to use PE3 as egress PE. PE3 may have preprogrammed
2801 a backup forwarding entry pointing to backup path (through PE4-CE4)
2802 for all prefixes going through PE3-CE3 link. How backup path is
2803 computed is out of scope of the document. When PE3-CE3 link fails,
2804 traffic is still received by PE3 but PE3 switch automatically traffic
2805 to the backup entry, path will so be PE1-P1-(...)-P3-PE3-PE4-CE4
2806 until remote PEs reconverge and use PE4 as egress PE.
2808 5.9. Security
2810 Security container defines customer specific security parameters for
2811 the site.
2813 5.9.1. Authentication
2815 The current model does not support any authentication parameters, but
2816 such parameters may be added in the authentication container through
2817 augmentation.
2819 5.9.2. Encryption
2821 Encryption can be requested on the connection. It may be performed
2822 at layer 2 or layer 3 by selecting the appropriate enumeration in
2823 "layer" leaf. The encryption profile can be a service provider
2824 defined profile or customer specific.
2826 5.10. Management
2828 The model proposes three types of common management options :
2830 o provider-managed : the CE router is managed only by the provider.
2831 In this model, the responsibility boundary between SP and customer
2832 is between CE and customer network.
2834 o customer-managed : the CE router is managed only by the customer.
2835 In this model, the responsibility boundary between SP and customer
2836 is between PE and CE.
2838 o co-managed : the CE router is primarly managed by the provider and
2839 in addition SP lets customer accessing the CE for some
2840 configuration/monitoring purpose. In the co-managed mode the
2841 responsibility boundary is the same as the provider-managed model.
2843 Based on the management model, different security options MAY be
2844 derived.
2846 In case of "co-managed", the model proposes some option to define the
2847 management transport protocol (IPv4 or IPv6) and the associated
2848 management address.
2850 5.11. Routing protocols
2852 Routing-protocol defines which routing protocol must be activated
2853 between the provider and the customer router. The current model
2854 support : bgp, rip, ospf, static, direct, vrrp.
2856 The routing protocol defined applies at the provider to customer
2857 boundary. Depending of the management of the management model, it
2858 may apply to the PE-CE boundary or CE to customer boundary. In case
2859 of customer managed site, the routing-protocol defined will be
2860 activated between the PE and the CE router managed by the customer.
2861 In case of provider managed site, the routing-protocol defined will
2862 be activated between the CE managed by the SP and the router or LAN
2863 belonging to the customer. In this case, it is expected that the PE-
2864 CE routing will be configured based on the service provider rules as
2865 both are managed by the same entity.
2867 Rtg protocol
2868 192.0.2.0/24 ----- CE ----------------- PE1
2870 Customer managed site
2872 Rtg protocol
2873 Customer router ----- CE ----------------- PE1
2875 Provider managed site
2877 All the examples below will refer to a customer managed site case.
2879 5.11.1. Dual stack handling
2881 All routing protocol types support dual stack by using address-family
2882 leaf-list.
2884 Example of Dual stack using the same routing protocol :
2886
2887
2888 static
2889
2890 ipv4
2891 ipv6
2892
2893
2894
2896 Example of Dual stack using two different routing protocols :
2898
2899
2900 rip
2901
2902 ipv4
2903
2904
2905
2906 ospf
2907
2908 ipv6
2909
2910
2911
2913 5.11.2. Direct LAN connection onto SP network
2915 Routing-protocol "direct" SHOULD be used when a customer LAN is
2916 directly connected to the provider network and must be advertised in
2917 the IPVPN.
2919 LAN attached directly to provider network :
2921 192.0.2.0/24 ----- PE1
2923 In this case, the customer has a default route to the PE address.
2925 5.11.3. Direct LAN connection onto SP network with redundancy
2927 Routing-protocol "vrrp" SHOULD be used when a customer LAN is
2928 directly connected to the provider network and must be advertised in
2929 the IPVPN and LAN redundancy is expected.
2931 LAN attached directly to provider network with LAN redundancy:
2933 192.0.2.0/24 ------ PE1
2934 |
2935 +--- PE2
2937 In this case, the customer has a default route to the service
2938 provider network.
2940 5.11.4. Static routing
2942 Routing-protocol "static" MAY be used when a customer LAN is
2943 connected to the provider network through a CE router and must be
2944 advertised in the IPVPN.
2946 Static rtg
2947 192.0.2.0/24 ------ CE -------------- PE
2948 | |
2949 | Static route 192.0.2.0/24 nh CE
2950 Static route 0.0.0.0/0 nh PE
2952 In this case, the customer has a default route to the service
2953 provider network.
2955 5.11.5. RIP routing
2957 Routing-protocol "rip" MAY be used when a customer LAN is connected
2958 to the provider network through a CE router and must be advertised in
2959 the IPVPN. For IPv4, the model assumes usage of RIP version 2.
2961 In case of dual stack routing requested through this model, the
2962 management system will be responsible to configure rip (including
2963 right version number) and associated address-families on network
2964 elements.
2966 RIP rtg
2967 192.0.2.0/24 ------ CE -------------- PE
2969 5.11.6. OSPF routing
2971 Routing-protocol "ospf" MAY be used when a customer LAN is connected
2972 to the provider network through a CE router and must be advertised in
2973 the IPVPN.
2975 It can be used to extend an existing OSPF network and interconnect
2976 different areas. See [RFC4577] for more details.
2978 +---------------------+
2979 | |
2980 OSPF | | OSPF
2981 area 1 | | area 2
2982 (OSPF | | (OSPF
2983 area 1) --- CE ---------- PE PE ----- CE --- area 2)
2984 | |
2985 +---------------------+
2987 The model also proposes an option to create an OSPF sham-link between
2988 two sites sharing the same area and having a backdoor link. The
2989 sham-link is created by referencing the target site sharing the same
2990 OSPF area. The management system will be responsible to check if
2991 there is already a shamlink configured for this VPN and area between
2992 the same pair of PEs. If there is no existing shamlink, the
2993 management system will provision it, this shamlink MAY be reused by
2994 other sites.
2996 +------------------------+
2997 | |
2998 | |
2999 | PE (--shamlink--)PE |
3000 | | | |
3001 +----|----------------|--+
3002 | OSPF area1 | OSPF area 1
3003 | |
3004 CE1 CE2
3005 | |
3006 (OSPF area1) (OSPF area1)
3007 | |
3008 +----------------+
3010 Regarding Dual stack support, user MAY decide to fill both IPv4 and
3011 IPv6 address families, if both protocols SHOULD be routed through
3012 OSPF. As OSPF is using two different protocol for IPv4 and IPv6, the
3013 management system will need to configure both ospf version 2 and
3014 version 3 on the PE-CE link.
3016 Example of OSPF routing parameters in service model.
3018
3019
3020 ospf
3021
3022 0.0.0.1
3023 ipv4
3024 ipv6
3025
3026
3027
3029 Example of PE configuration done by management system :
3031 router ospf 10
3032 area 0.0.0.1
3033 interface Ethernet0/0
3034 !
3035 router ospfv3 10
3036 area 0.0.0.1
3037 interface Ethernet0/0
3038 !
3040 5.11.7. BGP routing
3042 Routing-protocol "bgp" MAY be used when a customer LAN is connected
3043 to the provider network through a CE router and must be advertised in
3044 the IPVPN.
3046 BGP rtg
3047 192.0.2.0/24 ------ CE -------------- PE
3049 The session addressing will be derived from connection parameters as
3050 well as internal knowledge of SP.
3052 In case of dual stack access, user MAY request BGP routing for both
3053 IPv4 and IPv6 by filling both address-families. It will be up to SP
3054 and management system to decide how to decline the configuration (two
3055 BGP sessions, single, multisession ...).
3057 The service configuration below activates BGP on PE-CE link for both
3058 IPv4 and IPv6.
3060 BGP activation requires SP to know the address of the customer peer.
3061 "static-address" allocation type for the IP connection MUST be used.
3063
3064
3065 bgp
3066
3067 65000
3068 ipv4
3069 ipv6
3070
3071
3072
3074 This service configuration can be derived by management system into
3075 multiple flavors depending on SP flavor.
3077 Example #1 of PE configuration done by management system
3078 (single session IPv4 transport):
3080 router bgp 100
3081 neighbor 203.0.113.2 remote-as 65000
3082 address-family ipv4 vrf Cust1
3083 neighbor 203.0.113.2 activate
3084 address-family ipv6 vrf Cust1
3085 neighbor 203.0.113.2 activate
3086 neighbor 203.0.113.2 route-map SET-NH-IPV6 out
3088 Example #2 of PE configuration done
3089 by management system (two sessions):
3091 router bgp 100
3092 neighbor 203.0.113.2 remote-as 65000
3093 neighbor 2001::2 remote-as 65000
3094 address-family ipv4 vrf Cust1
3095 neighbor 203.0.113.2 activate
3096 address-family ipv6 vrf Cust1
3097 neighbor 2001::2 activate
3099 Example #3 of PE configuration done
3100 by management system (multisession):
3102 router bgp 100
3103 neighbor 203.0.113.2 remote-as 65000
3104 neighbor 203.0.113.2 multisession per-af
3105 address-family ipv4 vrf Cust1
3106 neighbor 203.0.113.2 activate
3107 address-family ipv6 vrf Cust1
3108 neighbor 203.0.113.2 activate
3109 neighbor 203.0.113.2 route-map SET-NH-IPV6 out
3111 5.12. Service
3113 The service defines service parameters associated with the site.
3115 5.12.1. Bandwidth
3117 The service bandwidth refers to the bandwidth requirement between PE
3118 and CE (WAN access bandwidth). The requested bandwidth is expressed
3119 as svc-input-bandwidth and svc-output-bandwidth in bit per seconds.
3120 Input/output direction is using customer site as reference : input
3121 bandwidth so means download bandwidth for the site, and output
3122 bandwidth means upload bandwidth for the site.
3124 The service bandwidth is only configurable at site-network-access
3125 level.
3127 Using a different input and output bandwidth will allow service
3128 provider to know if customer allows for asymmetric bandwidth access
3129 like ADSL. It can also be used to set rate-limit in a different way
3130 upload and download on a symmetric bandwidth access.
3132 The bandwidth is a service bandwidth : expressed primarily as IP
3133 bandwidth but if the customer enables MPLS for carrier's carrier,
3134 this becomes MPLS bandwidth.
3136 5.12.2. QoS
3138 The model proposes to define QoS parameters in an abstracted way :
3140 o qos-classification-policy : define a set of ordered rules to
3141 classify customer traffic.
3143 o qos-profile : QoS scheduling profile to be applied.
3145 5.12.2.1. QoS classification
3147 QoS classification rules are handled by qos-classification-policy.
3148 The qos-classification-policy is an ordered list of rules that match
3149 a flow or application and set the appropriate target class of service
3150 (target-class-id). The user can define the match using an
3151 application reference or a more specific flow definition (based layer
3152 3 source and destination address, layer 4 ports, layer 4 protocol).
3153 The current model defines some applications but new application
3154 identities may be added through augmentation. The exact meaning of
3155 each application identity is up to the service provider, so it will
3156 be necessary for the service provider to advise customer on usage of
3157 application matching.
3159 Where the classification is done depends on the SP implementation of
3160 the service, but classification concerns the flow coming from the
3161 customer site and entering the network.
3163 Provider network
3164 +-----------------------+
3165 192.0.2.0/24
3166 198.51.100.0/24 ---- CE --------- PE
3168 Traffic flow
3169 ---------->
3171 In the figure above, the management system can decide :
3173 o if the CE is customer managed, to implement the classification
3174 rule in the ingress direction on the PE interface.
3176 o if the CE is provider managed, to implement the classification
3177 rule in the ingress direction on the CE interface connected to
3178 customer LAN.
3180 The figure below describes a sample service description of qos-
3181 classification for a site :
3183
3184
3185
3186
3187 1
3188
3189 192.0.2.0/24
3190 203.0.113.1/32
3191 80
3192 tcp
3193
3194 DATA2
3195
3196
3197 2
3198
3199 192.0.2.0/24
3200 203.0.113.1/32
3201 21
3202 tcp
3203
3204 DATA2
3205
3206
3207 3
3208 p2p
3209 DATA3
3210
3211
3212 4
3213 DATA1
3214
3215
3216
3217
3219 In the example above :
3221 o HTTP traffic from 192.0.2.0/24 LAN destinated to 203.0.113.1/32
3222 will be classified in DATA2.
3224 o FTP traffic from 192.0.2.0/24 LAN destinated to 203.0.113.1/32
3225 will be classified in DATA2.
3227 o Peer to peer traffic will be classified in DATA3.
3229 o All other traffic will be classified in DATA1.
3231 The order of rules is really important. The management system
3232 responsible for translating those rules in network element
3233 configuration MUST keep the same processing order in element
3234 configuration. The order of rule is defined by the "id" leaf. The
3235 lowest "id" MUST be processed first.
3237 5.12.2.2. QoS profile
3239 User can choose between standard profile provided by the operator or
3240 custom profile. The qos-profile defines the traffic scheduling
3241 policy to be used by the service provider.
3243 Provider network
3244 +-----------------------+
3245 192.0.2.0/24
3246 198.51.100.0/24 ---- CE --------- PE
3247 \ /
3248 qos-profile
3250 In case of provider managed or co-managed connection, the provider
3251 should ensure scheduling according to the requested policy in both
3252 traffic directions (SP to customer and customer to SP). As example
3253 of implementation, a device scheduling policy may be implemented both
3254 at PE and CE side on the WAN link. In case of customer managed
3255 connection, the provider is only responsible to ensure scheduling
3256 from SP network to the customer site. As example of implementation,
3257 a device scheduling policy may be implemented only at PE side on the
3258 WAN link towards the customer.
3260 A custom qos-profile is defined as a list of class of services and
3261 associated properties. The properties are :
3263 o rate-limit : used to rate-limit the class of service. The value
3264 is expressed as a percentage of the global service bandwidth.
3265 When the qos-profile is implemented at CE side the svc-output-
3266 bandwidth is taken into account as reference. When it is
3267 implemented at PE side, the svc-input-bandwidth is used.
3269 o priority-level : used to define priorities between class of
3270 services. The value of the priority to be used is dependant of
3271 each administration. The higher the priority-level is, the higher
3272 the priority of the class will be. Priority-level can be used to
3273 define strict priority queueing. A priority-level 250 class will
3274 be served before a priority-level 100 class until there is no more
3275 packet to process or until rate-limit does not allow anymore
3276 packets from the higher priority class.
3278 o guaranteed-bw-percent : used to define a guaranteed amount of
3279 bandwidth for the class of service. It is expressed as a
3280 percentage. The guaranteed-bw-percent uses available bandwidth at
3281 the priority-level of the class. When the qos-profile is
3282 implemented at CE side the svc-output-bandwidth is taken into
3283 account as reference. When it is implemented at PE side, the svc-
3284 input-bandwidth is used.
3286 Example of service configuration using a standard qos profile :
3288
3289 1245HRTFGJGJ154654
3290
3291 100000000
3292 100000000
3293
3294
3295 PLATINUM
3296
3297
3298
3299
3300
3301 555555AAAA2344
3302
3303 2000000
3304 2000000
3305
3306
3307 GOLD
3308
3309
3310
3311
3313 Example of service configuration using a custom qos profile :
3315
3316 Site1
3317
3318 100000000
3319 100000000
3320
3321
3322
3323
3324 REAL_TIME
3325 10
3326 10
3327
3328
3329 DATA
3330 5
3331
3332
3333
3334
3335
3336
3337
3338 Site2
3339
3340 200000000
3341 200000000
3342
3343
3344
3345
3346 REAL_TIME
3347 30
3348 10
3349
3350
3351 DATA1
3352 5
3353 80
3354
3355
3356 DATA2
3357 5
3358 20
3359
3360
3361
3362
3363
3364
3366 The custom qos-profile for site1 defines that traffic from REAL_TIME
3367 class will have a higher priority than traffic from DATA class. The
3368 REAL_TIME traffic will be rate-limit to 10% of the service bandwidth
3369 (10% of 100Mbps = 10Mbps) to let some place for DATA traffic.
3371 The custom qos-profile for site2 defines that traffic from REAL_TIME
3372 class will have a higher priority than traffic from data traffic.
3373 Data traffic will be splitted in two class of service DATA1 and DATA2
3374 that will share bandwidth between them according to the percentage of
3375 guaranteed-bw-percent. The maximum of percentage to be used is not
3376 limited by this model but MUST be limited by the management system
3377 according to the policies authorized by the service provider. The
3378 REAL_TIME traffic will be rate-limit to 30% of the service bandwidth
3379 (30% of 200Mbps = 60Mbps) to let some place for data traffic. In
3380 case of congestion of the access, the REAL_TIME traffic can go up to
3381 60Mbps (Let's assume that 20Mbps only are consumed). The DATA1 and
3382 DATA2 will share remaining bandwidth (180Mbps) according to their
3383 percentage. So DATA1 will be served with at least 144Mbps of
3384 bandwidth.
3386 5.12.3. Multicast
3388 The multicast section defines the type of site in the customer
3389 multicast service topology : source, receiver, or both. These
3390 parameters will help management system to optimize the multicast
3391 service. User can also define the type of multicast relation with
3392 the customer : router (requires a protocol like PIM), host (IGMP or
3393 MLD), or both. Transport protocol (IPv4 or IPv6 or both) can also be
3394 defined.
3396 5.13. Enhanced VPN features
3398 5.13.1. Carrier's Carrier
3400 In case of Carrier's Carrier ([RFC4364]), a customer MAY want to
3401 build MPLS service using an IPVPN as transport layer.
3403 LAN customer1
3404 |
3405 |
3406 CE1
3407 |
3408 | -------------
3409 (vrf_cust1)
3410 CE1_ISP1
3411 | ISP1 PoP
3412 | MPLS link
3413 | -------------
3414 |
3415 (vrf ISP1)
3416 PE1
3418 (...) Provider backbone
3420 PE2
3421 (vrf ISP1)
3422 |
3423 | ------------
3424 |
3425 | MPLS link
3426 | ISP1 PoP
3427 CE2_ISP1
3428 (vrf_cust1)
3429 |-------------
3430 |
3431 CE2
3432 |
3433 Lan customer1
3435 In the figure above, ISP1 resells IPVPN service but has no transport
3436 infrastructure between its PoPs. ISP1 uses an IPVPN as transport
3437 infrastructure (belonging to another provider) between its PoPs.
3439 In order to support CsC, the VPN service must be declared MPLS
3440 support using the "carrierscarrier" leaf set to true in vpn-svc. The
3441 link between CE1_ISP1/PE1 and CE2_ISP1/PE2 must also run a MPLS
3442 signalling protocol. This configuration is done at the site level.
3444 In the proposed model, LDP or BGP can be used as MPLS signalling
3445 protocol. In case of LDP, an IGP routing protocol MUST also be
3446 activated. In case of BGP signalling, BGP MUST also be configured as
3447 routing-protocol.
3449 In case Carrier's Carrier is enabled, the requested svc-mtu will
3450 refer to the MPLS MTU and no more to the IP MTU.
3452 5.13.2. Transport constraints
3454 A customer may require some constraints for transporting traffic
3455 between particular sites. As example, a customer may require low
3456 latencies and disjoint paths between two hub sites. The current
3457 model proposes to define a list of constraints that can be augmented
3458 for unicast and/or multicast traffic. For unicast traffic, the model
3459 considers that the constraints are bidirectional (same constraint
3460 from site1 to site2 and site2 to site1). For multicast, constraints
3461 are unidirectional from source to receiver. The current model
3462 supports the following constraints :
3464 o Latency : this constraint allows to create the lowest latency path
3465 possible or to create a path with a latency boundary. In case a
3466 latency boundary is required, the boundary MUST be encoded in the
3467 constraint-opaque-value using a millisecond unit.
3469 o Bandwidth : this constraint allows to create a path that fits
3470 specific bandwidth requirement. If no constraint-opaque-value is
3471 provided, an implementation SHOULD use the lowest bandwidth
3472 between the two sites as reference. If constraint-opaque-value is
3473 used, the required bandwidth MUST be encoded in Mbps, and the
3474 implementation MUST use this value as reference.
3476 o Jitter : this constraint allows to create a path with a jitter
3477 boundary. constraint-opaque-value MUST be used with jitter
3478 constraint and MUST contain the jitter boundary expressed in
3479 milliseconds.
3481 o Path diversity : this constraint allows creation of disjoint paths
3482 between two sites. This requires the customer sites to be
3483 multihomed. constraint-opaque-value is not used.
3485 o Site diversity : this constraint is similar to path diversity but
3486 ensures that paths are not crossing the same provider PoPs. This
3487 requires the customer sites to be multihomed. constraint-opaque-
3488 value MAY be used to encode additional site location that must be
3489 avoided.
3491 5.14. External ID references
3493 The service model sometimes refers to external information through
3494 identifiers. As an example, to order a cloud-access to a particular
3495 Cloud Service Provider (CSP), the model uses an identifier to refer
3496 to the targeted CSP. In case, a customer is using directly this
3497 service model as an API (through REST or NETCONF for example) to
3498 order a particular service, the service provider should provide a
3499 list of authorized identifiers. In case of cloud-access, the service
3500 provider will provide the identifiers associated of each available
3501 CSP. The same applies to other identifiers like std-qos-profile, oam
3502 profile-name, provider-profile for encryption ...
3504 How SP provides those identifiers meaning to the customer is out of
3505 scope of this document.
3507 5.15. Defining NNIs
3509 An autonomous system is a single network or group of networks that is
3510 controlled by a common system administration group and that uses a
3511 single, clearly defined routing protocol. In some cases, VPNs need
3512 to span across different autonomous systems in different geographic
3513 areas or across different service providers. The connection between
3514 autonomous systems is established by the Service Providers and is
3515 seamless to the customer.
3517 Some examples are : Partnership between service providers (transport,
3518 cloud ...) to extend their VPN service seamlessly, or internal
3519 administrative boundary within a single service provider (Backhaul vs
3520 Core vs Datacenter ...).
3522 NNIs (Network to Network Interfaces) have to be defined to extend the
3523 VPNs across multiple autonomous systems.
3525 [RFC4364] defines multiple flavor of VPN NNI implementations. Each
3526 implementation has different pros/cons that are outside the scope of
3527 this document. As an example : In an Inter-AS Option A, ASBR peers
3528 are connected by multiple interfaces with at least one interface
3529 which VPN spans the two autonomous systems. These ASBRs associate
3530 each interface with a VPN routing and forwarding (VRF) instance and a
3531 Border Gateway Protocol (BGP) session to signal unlabeled IP
3532 prefixes. As a result, traffic between the back-to-back VRFs is IP.
3533 In this scenario, the VPNs are isolated from each other, and because
3534 the traffic is IP, QoS mechanisms that operate on IP traffic can be
3535 applied to achieve customer Service Level Agreements (SLAs).
3537 -------- -------------- -----
3538 / \ / \ / \
3539 | Cloud | | | | |
3540 | Provider | ----NNI---- | | ---NNI---| DC |
3541 | #1 | | | | |
3542 \ / | | \ /
3543 -------- | | ----
3544 | |
3545 -------- | My network | -----------
3546 / \ | | / \
3547 | Cloud | | | | |
3548 | Provider | ----NNI---- | |---NNI---| L3VPN |
3549 | #2 | | | | Partner |
3550 \ / | | | |
3551 -------- | | | |
3552 \ / | |
3553 -------------- \ /
3554 | ----------
3555 |
3556 NNI
3557 |
3558 |
3559 -------------------
3560 / \
3561 | |
3562 | |
3563 | |
3564 | L3VPN partner |
3565 | |
3566 \ /
3567 ------------------
3569 The figure above describes a service provider network "My network"
3570 that has several NNIs. This network uses NNI to :
3572 o increase its footprint by relying on L3VPN partners.
3574 o connect its own datacenter services to the customer IPVPN.
3576 o enable customer to access to its private resources located in
3577 private cloud owned by some cloud service providers.
3579 5.15.1. Defining NNI with option A flavor
3580 AS A AS B
3581 --------------------- --------------------
3582 / \ / \
3583 | | | |
3584 | ++++++++ InterAS link ++++++++ |
3585 | + +_____________ + + |
3586 | + (VRF1)--(VPN1)----(VRF1) + |
3587 | + ASBR + + ASBR + |
3588 | + (VRF2)--(VPN2)----(VRF2) + |
3589 | + +______________+ + |
3590 | ++++++++ ++++++++ |
3591 | | | |
3592 | | | |
3593 | | | |
3594 | ++++++++ InterAS link ++++++++ |
3595 | + +_____________ + + |
3596 | + (VRF1)--(VPN1)----(VRF1) + |
3597 | + ASBR + + ASBR + |
3598 | + (VRF2)--(VPN2)----(VRF2) + |
3599 | + +______________+ + |
3600 | ++++++++ ++++++++ |
3601 | | | |
3602 | | | |
3603 \ / \ /
3604 -------------------- -------------------
3606 In option A, the two ASes are connected between each other with
3607 physical links on Autonomous System Border Routers (ASBR). There may
3608 be multiple physical connections between the ASes for a resiliency
3609 purpose. A VPN connection, physical or logical (on top of physical),
3610 is created for each VPN that needs to cross the AS boundary. A back-
3611 to-back VRF model is so created.
3613 This VPN connection can be seen as a site from a service model
3614 perspective. Let's say that AS B wants to extend some VPN connection
3615 for VPN C on AS A. Administrator of AS B can use this service model
3616 to order a site on AS A. All connection scenarios could be realized
3617 using the current model features. As an example, the figure above,
3618 where two physical connections are involved with logical connections
3619 per VPN on top, could be seen as a dual-homed subvpn scenario. And
3620 for example, administrator from AS B will be able to choose the
3621 appropriate routing protocol (e.g. ebgp) to dynamically exchange
3622 routes between ASes.
3624 This document so supposes that option A NNI flavor SHOULD reuse the
3625 existing VPN site modeling.
3627 Example : a customer wants from its cloud service provider A to
3628 attach its virtual network N to an existing IPVPN (VPN1) he has from
3629 a L3VPN service provider B.
3631 CSP A L3VPN SP B
3633 ----------------- --------------------
3634 / \ / \
3635 | | | | |
3636 | VM --| ++++++++ NNI ++++++++ |---- VPN1
3637 | | + +_________+ + | Site#1
3638 | |--------(VRF1)---(VPN1)--(VRF1)+ |
3639 | | + ASBR + + ASBR + |
3640 | | + +_________+ + |
3641 | | ++++++++ ++++++++ |
3642 | VM --| | | |---- VPN1
3643 | |Virtual | | | Site#2
3644 | |Network | | |
3645 | VM --| | | |---- VPN1
3646 | | | | | Site#3
3647 \ / \ /
3648 ---------------- -------------------
3649 |
3650 |
3651 VPN1
3652 Site#4
3654 The cloud service provider or the customer itself may use our L3VPN
3655 service model exposed by service provider B to create the VPN
3656 connectivity. We could consider that, as the NNI is shared, the
3657 physical connection (bearer) between CSP A and SP B already exists.
3658 CSP A may so request through a service model a new site creation with
3659 a single site-network-access (single homing used in the diagram). As
3660 placement constraint, CSP A may use the existing bearer reference it
3661 has from SP A to force the placement of the VPN NNI on the existing
3662 link. The XML below describes what could be the configuration
3663 request to SP B :
3665
3666 CSP_A_attachment
3667
3668 NY
3669 US
3670
3671 site-vpn-flavor-nni
3672
3673
3674 bgp
3675
3676 500
3677 ipv4
3678
3679
3680
3681
3682
3683 CSP_A_VN1
3684
3685
3686 static-address
3687
3688 203.0.113.1
3689 203.0.113.2
3690 30
3691
3692
3693
3694
3695 450000000
3696 450000000
3697
3698
3699 VPN1
3700 any-to-any-role
3701
3702
3703
3704
3705 customer-managed
3706
3707
3709 The case described above is different from the cloud-access container
3710 usage as the cloud-access provides a public cloud access while this
3711 example enables access to private resources located in a cloud
3712 service provider network.
3714 5.15.2. Defining NNI with option B flavor
3716 AS A AS B
3717 --------------------- --------------------
3718 / \ / \
3719 | | | |
3720 | ++++++++ InterAS link ++++++++ |
3721 | + +_____________ + + |
3722 | + + + + |
3723 | + ASBR +<---mpebgp--->+ ASBR + |
3724 | + + + + |
3725 | + +______________+ + |
3726 | ++++++++ ++++++++ |
3727 | | | |
3728 | | | |
3729 | | | |
3730 | ++++++++ InterAS link ++++++++ |
3731 | + +_____________ + + |
3732 | + + + + |
3733 | + ASBR +<---mpebgp--->+ ASBR + |
3734 | + + + + |
3735 | + +______________+ + |
3736 | ++++++++ ++++++++ |
3737 | | | |
3738 | | | |
3739 \ / \ /
3740 -------------------- -------------------
3742 In option B, the two ASes are connected between each other with
3743 physical links on Autonomous System Border Routers (ASBR). There may
3744 be multiple physical connections between the ASes for a resiliency
3745 purpose. The VPN "connection" between ASes is done by exchanging VPN
3746 routes through MP-BGP.
3748 There are multiple flavors of implementations of such NNI, for
3749 example :
3751 1. The NNI is a provider internal NNI between for example of
3752 backbone and a DC. There is enough trust between the domains to
3753 not filter the VPN routes. So all the VPN routes are exchanged.
3754 Route target filtering may be implemented to save some
3755 unnecessary route states.
3757 2. The NNI is used between providers that agreed to exchange VPN
3758 routes for specific route-targets only. Each provider is
3759 authorized to use the route-target values from the other
3760 provider.
3762 3. The NNI is used between providers that agreed to exchange VPN
3763 routes for specific route-targets only. Each provider has its
3764 own route-target scheme. So a customer spanning the two networks
3765 will have different route-target in each network for a particular
3766 VPN.
3768 Case 1 does not require any service modeling, as the protocol enables
3769 dynamic exchange of necessary VPN routes.
3771 Case 2 requires to maintain some route-target filtering policy on
3772 ASBRs. From a service modeling point of view, it is necessary to
3773 agree on the list of route target to authorize.
3775 In case 3, both ASes need to agree on the VPN route-target to
3776 exchange and in addition how to map a VPN route-target from AS A to
3777 the corresponding route-target in AS B (and vice-versa).
3779 Those modelings are currently out of scope of this document.
3781 Cloud SP L3VPN SP B
3782 A
3783 ----------------- --------------------
3784 / \ / \
3785 | | | | |
3786 | VM --| ++++++++ NNI ++++++++ |---- VPN1
3787 | | + +_________+ + | Site#1
3788 | |-------+ + + + |
3789 | | + ASBR +<-mpebgp->+ ASBR + |
3790 | | + +_________+ + |
3791 | | ++++++++ ++++++++ |
3792 | VM --| | | |---- VPN1
3793 | |Virtual | | | Site#2
3794 | |Network | | |
3795 | VM --| | | |---- VPN1
3796 | | | | | Site#3
3797 \ / | |
3798 ---------------- | |
3799 \ /
3800 -------------------
3801 |
3802 |
3803 VPN1
3804 Site#4
3806 The example above describes a NNI connection between the service
3807 provider network B and a cloud service provider A. Both service
3808 providers does not trust themselves and use a different route-target
3809 allocation policy. So, in term of implementation, the customer VPN
3810 has a different route-target in each network (RT A in CSP A and RT B
3811 is CSP B). In order to connect the customer virtual network in CSP A
3812 to the customer IPVPN (VPN1) in SP B network, CSP A should request SP
3813 B to open the customer VPN on the NNI (accept the appropriate RT).
3814 Who does the RT translation is up to an agreement between the two
3815 service providers : SP B may permit CSP A to request VPN (RT)
3816 translation.
3818 5.15.3. Defining NNI with option C flavor
3819 AS A AS B
3820 --------------------- --------------------
3821 / \ / \
3822 | | | |
3823 | | | |
3824 | | | |
3825 | ++++++++ Multihop ebgp++++++++ |
3826 | + + + + |
3827 | + + + + |
3828 | + RGW +<---mpebgp--->+ RGW + |
3829 | + + + + |
3830 | + + + + |
3831 | ++++++++ ++++++++ |
3832 | | | |
3833 | | | |
3834 | | | |
3835 | | | |
3836 | | | |
3837 | ++++++++ InterAS link ++++++++ |
3838 | + +_____________ + + |
3839 | + + + + |
3840 | + ASBR + + ASBR + |
3841 | + + + + |
3842 | + +______________+ + |
3843 | ++++++++ ++++++++ |
3844 | | | |
3845 | | | |
3846 | | | |
3847 | ++++++++ InterAS link ++++++++ |
3848 | + +_____________ + + |
3849 | + + + + |
3850 | + ASBR + + ASBR + |
3851 | + + + + |
3852 | + +______________+ + |
3853 | ++++++++ ++++++++ |
3854 | | | |
3855 | | | |
3856 \ / \ /
3857 -------------------- -------------------
3859 From a VPN service perspective, option C NNI is very similar to
3860 option B as a MP-BGP session is used to exchange VPN routes between
3861 the ASes. The difference is that the forwarding and control plane
3862 are separated on different nodes, so the MP-BGP is multi-hop between
3863 routing gateway (RGW) nodes.
3865 Modeling option B and C will be identical from a VPN service point of
3866 view.
3868 6. Service model usage example
3870 As explained in Section 4, this service model is intended to be
3871 instantiated at a management layer and is not intended to be used
3872 directly on network elements. The management system serves as a
3873 central point of configuration of the overall service.
3875 This section provides an example on how a management system can use
3876 this model to configure an IPVPN service on network elements.
3878 The example wants to achieve the provisionning of a VPN service for 3
3879 sites using hub and spoke VPN service topology. One of the site will
3880 be dual homed and loadsharing is expected.
3882 +-------------------------------------------------------------+
3883 | Hub_Site ------ PE1 PE2 ------ Spoke_Site1 |
3884 | | +----------------------------------+
3885 | | |
3886 | | +----------------------------------+
3887 | Hub_Site ------ PE3 PE4 ------ Spoke_Site2 |
3888 +-------------------------------------------------------------+
3890 The following XML describes the overall simplified service
3891 configuration of this VPN.
3893
3894 12456487
3895 CUSTOMER1
3896 hub-spoke
3897
3899 When receiving the request for provisioning the VPN service, the
3900 management system will internally (or through discussion with other
3901 OSS component) allocates VPN route-targets. In this specific case
3902 two RTs will be allocated (100:1 for Hub and 100:2 for Spoke). The
3903 output below describes the configuration of Spoke1.
3905
3906 Spoke_Site1
3907
3908 NY
3909 US
3910
3911
3912
3913 bgp
3914
3915 500
3916 ipv4
3917 ipv6
3918
3919
3920
3921
3922
3923 Spoke_Site1
3924
3925
3926
3927 20
3928
3929
3930
3931
3932 pe-diverse
3933
3934
3935 10
3936
3937
3938
3939
3940
3941
3942
3943
3944 static-address
3945
3946
3947 203.0.113.254
3948 203.0.113.2
3949 24
3950
3951
3952
3953
3954 static-address
3955
3956
3957 2001:db8::1
3958 2001:db8::2
3959 64
3960
3962
3963
3964
3965 450000000
3966 450000000
3967
3968
3969 12456487
3970 spoke-role
3971
3972
3973
3974
3975 provider-managed
3976
3977
3979 When receiving the request for provisioning Spoke1 site, the
3980 management system MUST allocate network resources for this site. It
3981 MUST first decide the target network elements to provision the
3982 access, and especially the PE router (and may be an aggregation
3983 switch). As described in Section 5.6, the management system SHOULD
3984 use the location information and SHOULD use the access-diversity
3985 constraint to find the appropriate PE. In this case, we consider
3986 Spoke1 requires PE diversity with Hub and that management system
3987 allocate PEs based on lowest distance. Based on the location
3988 information, the management system finds the available PEs in the
3989 nearest area of the customer and picks one that fits the access-
3990 diversity constraint.
3992 When the PE is chosen, management system needs to allocate interface
3993 resources on the node, one interface is so picked from the PE
3994 available pool. The management system can start provisioning the PE
3995 node by using any mean (Netconf, CLI, ...). The management system
3996 will check if a VRF is already present that fits the needs. If not,
3997 it will provision the VRF : Route distinguisher will come from
3998 internal allocation policy model, route-targets are coming from the
3999 vpn-policy configuration of the site (management system allocated
4000 some RTs for the VPN). As the site is a spoke site (site-role), the
4001 management system knows which RT must be imported and exported. As
4002 the site is provider managed, some management route-targets may also
4003 be added (100:5000). Standard provider VPN policies MAY also be
4004 added in the configuration.
4006 Example of generated PE configuration :
4008 ip vrf Customer1
4009 export-map STD-CUSTOMER-EXPORT <---- Standard SP configuration
4010 route-distinguisher 100:3123234324
4011 route-target import 100:1
4012 route-target import 100:5000 <---- Standard SP configuration
4013 route-target export 100:2 for provider managed
4014 !
4016 When the VRF has been provisioned, the management system can start
4017 configuring the access on the PE using the allocated interface
4018 information. IP addressing is chosen by the management system. One
4019 address will be picked from an allocated subnet for the PE, another
4020 will be used for the CE configuration. Routing protocols will also
4021 be configured between PE and CE and due to provider managed model,
4022 the choice is up to service provider : BGP was chosen for the
4023 example. This choice is independant of the routing protocol chosen
4024 by customer. For the CE - LAN part, bgp will be used as requested in
4025 the service model. Peering addresses will be derived from those of
4026 the connection. As CE is provider managed, CE AS number can be
4027 automatically allocated by the management system. Some provider
4028 standard configuration templates may also be added.
4030 Example of generated PE configuration :
4032 interface Ethernet1/1/0.10
4033 encapsulation dot1q 10
4034 ip vrf forwarding Customer1
4035 ip address 198.51.100.1 255.255.255.252 <---- Comes from
4036 automated allocation
4037 ipv6 address 2001:db8::10:1/64
4038 ip access-group STD-PROTECT-IN <---- Standard SP config
4039 !
4040 router bgp 100
4041 address-family ipv4 vrf Customer1
4042 neighbor 198.51.100.2 remote-as 65000 <---- Comes from
4043 automated allocation
4044 neighbor 198.51.100.2 route-map STD in <---- Standard SP config
4045 neighbor 198.51.100.2 filter-list 10 in <---- Standard SP config
4046 !
4047 address-family ipv6 vrf Customer1
4048 neighbor 2001:db8::0A10:2 remote-as 65000 <---- Comes from
4049 automated allocation
4050 neighbor 2001:db8::0A10:2 route-map STD in <---- Standard SP config
4051 neighbor 2001:db8::0A10:2 filter-list 10 in <---- Standard SP config
4052 !
4053 ip route vrf Customer1 192.0.2.1 255.255.255.255 198.51.100.2
4054 ! Static route for provider administration of CE
4055 !
4057 As the CE router is not reachable at this stage, the management
4058 system can produce a complete CE configuration that can be uploaded
4059 to the node by manual operation before sending the CE to customer
4060 premise. The CE configuration will be built as for the PE. Based on
4061 the CE type (vendor/model) allocated to the customer and bearer
4062 information, the management system knows which interface must be
4063 configured on the CE. PE-CE link configuration is expected to be
4064 handled automatically using the service provider OSS as both
4065 resources are managed internally. CE to LAN interface parameters
4066 like IP addressing are derived from ip-connection taking into account
4067 how management system distributes addresses between PE and CE within
4068 the subnet. This will allow to produce a plug'n'play configuration
4069 for the CE.
4071 Example of generated CE configuration :
4073 interface Loopback10
4074 description "Administration"
4075 ip address 192.0.2.1 255.255.255.255
4076 !
4077 interface FastEthernet10
4078 description "WAN"
4079 ip address 198.51.100.2 255.255.255.252 <---- Comes from
4080 automated allocation
4081 ipv6 address 2001:db8::0A10:2/64
4082 !
4083 interface FastEthernet11
4084 description "LAN"
4085 ip address 203.0.113.254 255.255.255.0 <---- Comes from
4086 ip-connection
4087 ipv6 address 2001:db8::1/64
4088 !
4089 router bgp 65000
4090 address-family ipv4
4091 redistribute static route-map STATIC2BGP <---- Standard SP
4092 configuration
4093 neighbor 198.51.100.1 remote-as 100 <---- Comes from
4094 automated allocation
4095 neighbor 203.0.113.2 remote-as 500 <---- Comes from
4096 ip-connection
4097 address-family ipv6
4098 redistribute static route-map STATIC2BGP <---- Standard SP
4099 configuration
4100 neighbor 2001:db8::0A10:1 remote-as 100 <---- Comes from
4101 automated allocation
4102 neighbor 2001:db8::2 remote-as 500 <---- Comes from
4103 ip-connection
4104 !
4105 route-map STATIC2BGP permit 10
4106 match tag 10
4107 !
4109 7. Interaction with Other YANG Modules
4111 As expressed in Section 4, this service module is intended to be
4112 instantiated in management system and not directly on network
4113 elements.
4115 It will be the role of the management system to configure the network
4116 elements. The management system MAY be modular, so the component
4117 instantiating the service model (let's call it service component) and
4118 the component responsible for network element configuration (let's
4119 call it configuration component) MAY be different.
4121 L3VPN-SVC |
4122 service model |
4123 |
4124 +----------------------+
4125 | Service component | service datastore
4126 +----------------------+
4127 |
4128 |
4129 +----------------------+
4130 +----| Config component |-------+
4131 / +----------------------+ \ Network
4132 / / \ \ Configuration
4133 / / \ \ models
4134 / / \ \
4135 +++++++ ++++++++ ++++++++ +++++++
4136 + CEA + ------- + PE A + + PE B + ----- + CEB + Config
4137 +++++++ ++++++++ ++++++++ +++++++ datastore
4139 Site A Site B
4141 In the previous sections, we provided some example of translation of
4142 service provisioning request to router configuration lines as
4143 illustration. In the NETCONF/YANG ecosystem, it will be expected
4144 NETCONF/YANG to be used between configuration component and network
4145 elements to configure the requested service on these elements.
4147 In this framework, it is expected from standardization to also work
4148 on specific configuration YANG modelization of service components on
4149 network elements. There will be so a strong relation between the
4150 abstracted view provided by this service model and the detailed
4151 configuration view that will be provided by specific configuration
4152 models for network elements.
4154 Authors of this document are expecting definition of YANG models for
4155 network elements on this non exhaustive list of items :
4157 o VRF definition including VPN policy expression.
4159 o Physical interface.
4161 o IP layer (IPv4, IPv6).
4163 o QoS : classification, profiles...
4165 o Routing protocols : support of configuration of all protocols
4166 listed in the document, as well as routing policies associated
4167 with these protocols.
4169 o Multicast VPN.
4171 o Network Address Translation.
4173 o ...
4175 Example of VPN site request at service level using this model :
4177
4178 Site A
4179
4180
4181
4182
4183 static-address
4184
4185 203.0.113.254
4186 203.0.113.2
4187 24
4188
4189
4190
4191
4192 VPNPOL1
4193
4194
4195
4196
4197
4198 static
4199
4200
4201
4202 198.51.100.0/30
4203 203.0.113.2
4204
4205
4206
4207
4208
4209
4210 customer-managed
4211
4212
4213
4214 VPNPOL1
4215
4216 1
4217
4218 VPN1
4219 any-to-any-role
4220
4221
4222
4223
4224
4225 In the service example above, it is expected that the service
4226 component requests to the configuration component of the management
4227 system the configuration of the service elements. If we consider
4228 that service component selected a PE (PE A) as target PE for the
4229 site, the configuration component will need to push the configuration
4230 to PE A. The configuration component will use several YANG data
4231 models to define the configuration to be applied to PE A. The XML
4232 configuration of PE-A may look like this :
4234
4235
4236 eth0
4237 ianaift:ethernetCsmacd
4238
4239 Link to CEA.
4240
4241
4242
4243 203.0.113.254
4244 24
4245
4246 true
4247
4248
4249
4250
4251
4252 VRF_CustA
4253 l3vpn:vrf
4254 VRF for CustomerA
4255
4256 100:1546542343
4257
4258 100:1
4259 100:1
4260
4261
4262 eth0
4263
4264
4265
4266
4267 rt:static
4268 st0
4269
4270
4271
4272
4273 198.51.100.0/30
4274
4275
4276
4277 203.0.113.2
4278
4279
4280
4281
4282
4283
4284
4285
4286
4288 8. YANG Module
4290 file "ietf-l3vpn-svc@2016-09-27.yang"
4292 module ietf-l3vpn-svc {
4293 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
4295 prefix l3vpn-svc;
4297 import ietf-inet-types {
4298 prefix inet;
4299 }
4301 import ietf-yang-types {
4302 prefix yang;
4303 }
4305 organization
4306 "IETF L3SM Working Group";
4308 contact
4309 "WG List: <mailto:l3sm@ietf.org>
4311 Editor:
4312 L3SM WG
4314 Chairs:
4315 Adrian Farrel, Qin Wu
4316 ";
4318 description
4319 "The YANG module defines a generic service configuration
4320 model for Layer 3 VPN common across all of the vendor
4321 implementations.";
4323 revision 2016-09-27 {
4324 description
4325 "Initial document";
4326 reference
4327 "draft-ietf-l3sm-l3vpn-service-yang-15";
4328 }
4330 /* Features */
4332 feature cloud-access {
4333 description
4334 "Allow VPN to connect to a Cloud Service
4335 provider.";
4336 }
4337 feature multicast {
4338 description
4339 "Enables multicast capabilities in a VPN";
4340 }
4341 feature ipv4 {
4342 description
4343 "Enables IPv4 support in a VPN";
4344 }
4345 feature ipv6 {
4346 description
4347 "Enables IPv6 support in a VPN";
4348 }
4349 feature carrierscarrier {
4350 description
4351 "Enables support of carrier's carrier";
4352 }
4353 feature traffic-engineering {
4354 description
4355 "Enables support of transport constraint.";
4356 }
4357 feature traffic-engineering-multicast {
4358 description
4359 "Enables support of transport constraint
4360 for multicast.";
4361 }
4362 feature extranet-vpn {
4363 description
4364 "Enables support of extranet VPNs";
4365 }
4366 feature site-diversity {
4367 description
4368 "Enables support of site diversity constraints";
4369 }
4370 feature encryption {
4371 description
4372 "Enables support of encryption";
4373 }
4374 feature qos {
4375 description
4376 "Enables support of Class of Services";
4377 }
4378 feature qos-custom {
4379 description
4380 "Enables support of custom qos profile";
4381 }
4382 feature rtg-bgp {
4383 description
4384 "Enables support of BGP routing protocol.";
4385 }
4386 feature rtg-rip {
4387 description
4388 "Enables support of RIP routing protocol.";
4389 }
4390 feature rtg-ospf {
4391 description
4392 "Enables support of OSPF routing protocol.";
4393 }
4394 feature rtg-ospf-sham-link {
4395 description
4396 "Enables support of OSPF sham-links.";
4397 }
4398 feature rtg-vrrp {
4399 description
4400 "Enables support of VRRP routing protocol.";
4401 }
4402 feature fast-reroute {
4403 description
4404 "Enables support of Fast Reroute.";
4405 }
4406 feature bfd {
4407 description
4408 "Enables support of BFD.";
4409 }
4410 feature always-on {
4411 description
4412 "Enables support for always-on access
4413 constraint.";
4414 }
4415 feature requested-type {
4416 description
4417 "Enables support for requested-type access
4418 constraint.";
4419 }
4420 feature bearer-reference {
4421 description
4422 "Enables support for bearer-reference access
4423 constraint.";
4424 }
4426 /* Typedefs */
4428 typedef svc-id {
4429 type string;
4430 description
4431 "Defining a type of service component
4432 identificators.";
4433 }
4435 typedef template-id {
4436 type string;
4437 description
4438 "Defining a type of service template
4439 identificators.";
4440 }
4442 /* Identities */
4444 identity site-network-access-type {
4445 description
4446 "Base identity for site-network-access type";
4447 }
4448 identity point-to-point {
4449 base site-network-access-type;
4450 description
4451 "Identity for point-to-point connection";
4452 }
4453 identity multipoint {
4454 base site-network-access-type;
4455 description
4456 "Identity for multipoint connection
4457 Example : ethernet broadcast segment";
4458 }
4460 identity placement-diversity {
4461 description
4462 "Base identity for site placement
4463 constraints";
4464 }
4465 identity pe-diverse {
4466 base placement-diversity;
4467 description
4468 "Identity for PE diversity";
4469 }
4470 identity pop-diverse {
4471 base placement-diversity;
4472 description
4473 "Identity for POP diversity";
4474 }
4475 identity linecard-diverse {
4476 base placement-diversity;
4477 description
4478 "Identity for linecard diversity";
4479 }
4480 identity same-pe {
4481 base placement-diversity;
4482 description
4483 "Identity for having sites connected
4484 on the same PE";
4485 }
4486 identity same-bearer {
4487 base placement-diversity;
4488 description
4489 "Identity for having sites connected
4490 using the same bearer";
4491 }
4493 identity customer-application {
4494 description
4495 "Base identity for customer application";
4496 }
4497 identity web {
4498 base customer-application;
4499 description
4500 "Identity for web application (e.g. HTTP,HTTPS)";
4501 }
4502 identity mail {
4503 base customer-application;
4504 description
4505 "Identity for mail applications";
4506 }
4507 identity file-transfer {
4508 base customer-application;
4509 description
4510 "Identity for file transfer applications (
4511 e.g. FTP, SFTP, ...)";
4512 }
4513 identity database {
4514 base customer-application;
4515 description
4516 "Identity for database applications";
4517 }
4518 identity social {
4519 base customer-application;
4520 description
4521 "Identity for social network applications";
4522 }
4523 identity games {
4524 base customer-application;
4525 description
4526 "Identity for gaming applications";
4527 }
4528 identity p2p {
4529 base customer-application;
4530 description
4531 "Identity for peer to peer applications";
4532 }
4533 identity network-management {
4534 base customer-application;
4535 description
4536 "Identity for management applications (e.g. telnet
4537 syslog, snmp ...)";
4538 }
4539 identity voice {
4540 base customer-application;
4541 description
4542 "Identity for voice applications";
4543 }
4544 identity video {
4545 base customer-application;
4546 description
4547 "Identity for video conference applications";
4548 }
4550 identity address-family {
4551 description
4552 "Base identity for an address family.";
4553 }
4554 identity ipv4 {
4555 base address-family;
4556 description
4557 "Identity for IPv4 address family.";
4558 }
4559 identity ipv6 {
4560 base address-family;
4561 description
4562 "Identity for IPv6 address family.";
4563 }
4565 identity site-vpn-flavor {
4566 description
4567 "Base identity for the site VPN service flavor.";
4568 }
4569 identity site-vpn-flavor-single {
4570 base site-vpn-flavor;
4571 description
4572 "Base identity for the site VPN service flavor.
4573 Used when the site belongs to only one VPN.";
4574 }
4575 identity site-vpn-flavor-multi {
4576 base site-vpn-flavor;
4577 description
4578 "Base identity for the site VPN service flavor.
4579 Used when a logical connection of a site
4580 belongs to multiple VPNs.";
4581 }
4583 identity site-vpn-flavor-sub {
4584 base site-vpn-flavor;
4585 description
4586 "Base identity for the site VPN service flavor.
4587 Used when a site has multiple logical connections.
4588 Each of the connection may belong to different
4589 multiple VPNs.";
4590 }
4591 identity site-vpn-flavor-nni {
4592 base site-vpn-flavor;
4593 description
4594 "Base identity for the site VPN service flavor.
4595 Used to describe a NNI option A connection.";
4596 }
4598 identity transport-constraint {
4599 description
4600 "Base identity for transport constraint.";
4601 }
4602 identity tc-latency {
4603 base transport-constraint;
4604 description
4605 "Base identity for transport constraint
4606 based on latency.";
4607 }
4608 identity tc-jitter {
4609 base transport-constraint;
4610 description
4611 "Base identity for transport constraint
4612 based on jitter.";
4613 }
4614 identity tc-bandwidth {
4615 base transport-constraint;
4616 description
4617 "Base identity for transport constraint
4618 based on bandwidth.";
4619 }
4620 identity tc-path-diversity {
4621 base transport-constraint;
4622 description
4623 "Base identity for transport constraint
4624 based on path diversity.";
4625 }
4626 identity tc-site-diversity {
4627 base transport-constraint;
4628 description
4629 "Base identity for transport constraint
4630 based on site diversity.";
4631 }
4633 identity management {
4634 description
4635 "Base identity for site management scheme.";
4636 }
4637 identity co-managed {
4638 base management;
4639 description
4640 "Base identity for comanaged site.";
4641 }
4642 identity customer-managed {
4643 base management;
4644 description
4645 "Base identity for customer managed site.";
4646 }
4647 identity provider-managed {
4648 base management;
4649 description
4650 "Base identity for provider managed site.";
4652 }
4654 identity address-allocation-type {
4655 description
4656 "Base identity for address-allocation-type
4657 for PE-CE link.";
4658 }
4659 identity provider-dhcp {
4660 base address-allocation-type;
4661 description
4662 "Provider network provides DHCP service to customer.";
4663 }
4664 identity provider-dhcp-relay {
4665 base address-allocation-type;
4666 description
4667 "Provider network provides DHCP relay service to customer.";
4668 }
4669 identity static-address {
4670 base address-allocation-type;
4671 description
4672 "Provider to customer addressing is static.";
4673 }
4674 identity slaac {
4675 base address-allocation-type;
4676 description
4677 "Use IPv6 SLAAC.";
4678 }
4680 identity site-role {
4681 description
4682 "Base identity for site type.";
4683 }
4684 identity any-to-any-role {
4685 base site-role;
4686 description
4687 "Site in a any to any IPVPN.";
4688 }
4689 identity spoke-role {
4690 base site-role;
4691 description
4692 "Spoke Site in a Hub & Spoke IPVPN.";
4693 }
4694 identity hub-role {
4695 base site-role;
4696 description
4697 "Hub Site in a Hub & Spoke IPVPN.";
4698 }
4699 identity vpn-topology {
4700 description
4701 "Base identity for VPN topology.";
4702 }
4703 identity any-to-any {
4704 base vpn-topology;
4705 description
4706 "Identity for any to any VPN topology.";
4707 }
4708 identity hub-spoke {
4709 base vpn-topology;
4710 description
4711 "Identity for Hub'n'Spoke VPN topology.";
4712 }
4713 identity hub-spoke-disjoint {
4714 base vpn-topology;
4715 description
4716 "Identity for Hub'n'Spoke VPN topology
4717 where Hubs cannot talk between each other.";
4718 }
4720 identity multicast-tree-type {
4721 description
4722 "Base identity for multicast tree type.";
4723 }
4725 identity ssm-tree-type {
4726 base multicast-tree-type;
4727 description
4728 "Identity for SSM tree type.";
4729 }
4730 identity asm-tree-type {
4731 base multicast-tree-type;
4732 description
4733 "Identity for ASM tree type.";
4734 }
4735 identity bidir-tree-type {
4736 base multicast-tree-type;
4737 description
4738 "Identity for BiDir tree type.";
4739 }
4741 identity multicast-rp-discovery-type {
4742 description
4743 "Base identity for rp discovery type.";
4744 }
4745 identity auto-rp {
4746 base multicast-rp-discovery-type;
4747 description
4748 "Base identity for auto-rp discovery type.";
4749 }
4750 identity static-rp {
4751 base multicast-rp-discovery-type;
4752 description
4753 "Base identity for static type.";
4754 }
4755 identity bsr-rp {
4756 base multicast-rp-discovery-type;
4757 description
4758 "Base identity for BDR discovery type.";
4759 }
4761 identity routing-protocol-type {
4762 description
4763 "Base identity for routing-protocol type.";
4764 }
4766 identity ospf {
4767 base routing-protocol-type;
4768 description
4769 "Identity for OSPF protocol type.";
4770 }
4772 identity bgp {
4773 base routing-protocol-type;
4774 description
4775 "Identity for BGP protocol type.";
4776 }
4778 identity static {
4779 base routing-protocol-type;
4780 description
4781 "Identity for static routing protocol type.";
4782 }
4784 identity rip {
4785 base routing-protocol-type;
4786 description
4787 "Identity for RIP protocol type.";
4788 }
4790 identity vrrp {
4791 base routing-protocol-type;
4792 description
4793 "Identity for VRRP protocol type.
4794 This is to be used when LAn are directly connected
4795 to provider Edge routers.";
4796 }
4798 identity direct {
4799 base routing-protocol-type;
4800 description
4801 "Identity for direct protocol type.
4802 .";
4803 }
4805 identity protocol-type {
4806 description
4807 "Base identity for protocol field type.";
4808 }
4810 identity tcp {
4811 base protocol-type;
4812 description
4813 "TCP protocol type.";
4814 }
4815 identity udp {
4816 base protocol-type;
4817 description
4818 "UDP protocol type.";
4819 }
4820 identity icmp {
4821 base protocol-type;
4822 description
4823 "icmp protocol type.";
4824 }
4825 identity icmp6 {
4826 base protocol-type;
4827 description
4828 "icmp v6 protocol type.";
4829 }
4830 identity gre {
4831 base protocol-type;
4832 description
4833 "GRE protocol type.";
4834 }
4835 identity ipip {
4836 base protocol-type;
4837 description
4838 "IPinIP protocol type.";
4839 }
4840 identity hop-by-hop {
4841 base protocol-type;
4842 description
4843 "Hop by Hop IPv6 header type.";
4844 }
4845 identity routing {
4846 base protocol-type;
4847 description
4848 "Routing IPv6 header type.";
4849 }
4850 identity esp {
4851 base protocol-type;
4852 description
4853 "ESP header type.";
4854 }
4855 identity ah {
4856 base protocol-type;
4857 description
4858 "AH header type.";
4859 }
4861 /* Groupings */
4863 grouping vpn-service-cloud-access {
4864 container cloud-accesses {
4865 list cloud-access {
4866 if-feature cloud-access;
4867 key cloud-identifier;
4869 leaf cloud-identifier {
4870 type string;
4871 description
4872 "Identification of cloud service. Local
4873 admin meaning.";
4874 }
4875 container authorized-sites {
4876 list authorized-site {
4877 key site-id;
4879 leaf site-id {
4880 type leafref {
4881 path "/l3vpn-svc/sites/site/site-id";
4882 }
4883 description
4884 "Site ID.";
4886 }
4887 description
4888 "List of authorized sites.";
4889 }
4890 description
4891 "Configuration of authorized sites";
4892 }
4893 container denied-sites {
4894 list denied-site {
4895 key site-id;
4897 leaf site-id {
4898 type leafref {
4899 path "/l3vpn-svc/sites/site/site-id";
4900 }
4901 description
4902 "Site ID.";
4903 }
4904 description
4905 "List of denied sites.";
4906 }
4907 description
4908 "Configuration of denied sites";
4909 }
4910 leaf nat-enabled {
4911 type boolean;
4912 description
4913 "Control if NAT is required or not.";
4914 }
4915 leaf customer-nat-address {
4916 type inet:ipv4-address;
4917 description
4918 "NAT address to be used in case of public
4919 or shared cloud.
4920 This is to be used in case customer is providing
4921 the public address.";
4922 }
4923 description
4924 "Cloud access configuration.";
4925 }
4926 description
4927 "Container for cloud access configurations";
4928 }
4929 description
4930 "grouping for vpn cloud definition";
4931 }
4933 grouping multicast-rp-group-cfg {
4934 choice group-format {
4935 case startend {
4936 leaf group-start {
4937 type inet:ip-address;
4938 description
4939 "First group address.";
4940 }
4941 leaf group-end {
4942 type inet:ip-address;
4943 description
4944 "Last group address.";
4945 }
4946 }
4947 case singleaddress {
4948 leaf group-address {
4949 type inet:ip-address;
4950 description
4951 "Group address";
4952 }
4953 }
4954 description
4955 "Choice for group format.";
4956 }
4957 description
4958 "Definition of groups for
4959 RP to group mapping.";
4960 }
4962 grouping vpn-service-multicast {
4963 container multicast {
4964 if-feature multicast;
4965 leaf enabled {
4966 type boolean;
4967 default false;
4968 description
4969 "Enable multicast.";
4970 }
4971 container customer-tree-flavors {
4972 list tree-flavor {
4973 key type;
4975 leaf type {
4976 type identityref {
4977 base multicast-tree-type;
4978 }
4979 description
4980 "Type of tree to be used.";
4981 }
4982 description
4983 "List of tree flavors.";
4984 }
4985 description
4986 "Type of trees used by customer.";
4987 }
4988 container rp {
4989 container rp-group-mappings {
4990 list rp-group-mapping {
4991 key "id";
4993 leaf id {
4994 type uint16;
4995 description
4996 "Unique identifier for the mapping.";
4997 }
4998 container provider-managed {
4999 leaf enabled {
5000 type boolean;
5001 default false;
5002 description
5003 "Set to true, if the RP must be a
5004 provider
5005 managed node.
5006 Set to false, if it is a customer
5007 managed node.";
5008 }
5010 leaf rp-redundancy {
5011 when "../enabled = 'true'" {
5012 description
5013 "Relevant when RP
5014 is provider managed.";
5015 }
5016 type boolean;
5017 default false;
5018 description
5019 "If true, redundancy
5020 mechanism for RP is required.";
5021 }
5022 leaf optimal-traffic-delivery {
5023 when "../enabled = 'true'" {
5024 description
5025 "Relevant when RP
5026 is provider managed.";
5027 }
5028 type boolean;
5029 default false;
5030 description
5031 "If true, SP must ensure
5032 that traffic uses an optimal path.";
5033 }
5034 description
5035 "Parameters for provider managed RP.";
5036 }
5038 leaf rp-address {
5039 when "../provider-managed/enabled = 'false'" {
5040 description
5041 "Relevant when RP
5042 is provider managed.";
5043 }
5044 type inet:ip-address;
5045 description
5046 "Defines the address of the
5047 RendezvousPoint.
5048 Used if RP is customer managed.";
5049 }
5051 container groups {
5052 list group {
5053 key id;
5055 leaf id {
5056 type uint16;
5057 description
5058 "Identifier for the group.";
5059 }
5060 uses multicast-rp-group-cfg;
5061 description
5062 "List of groups.";
5063 }
5064 description
5065 "Multicast groups associated with RP.";
5066 }
5068 description
5069 "List of RP to group mappings.";
5070 }
5071 description
5072 "RP to group mappings.";
5073 }
5074 container rp-discovery {
5075 leaf rp-discovery-type {
5076 type identityref {
5077 base multicast-rp-discovery-type;
5079 }
5080 default static-rp;
5081 description
5082 "Type of RP discovery used.";
5083 }
5084 container bsr-candidates {
5085 when "../rp-discovery-type = 'bsr-rp'" {
5086 description
5087 "Only applicable if discovery type
5088 is BSR-RP";
5089 }
5090 list bsr-candidate {
5091 key address;
5093 leaf address {
5094 type inet:ip-address;
5095 description
5096 "Address of BSR candidate";
5097 }
5099 description
5100 "List of customer BSR candidates";
5101 }
5102 description
5103 "Customer BSR candidates address";
5104 }
5105 description
5106 "RP discovery parameters";
5107 }
5109 description
5110 "RendezvousPoint parameters.";
5111 }
5112 description
5113 "Multicast global parameters for the VPN service.";
5114 }
5115 description
5116 "grouping for multicast vpn definition";
5117 }
5119 grouping vpn-service-mpls {
5120 leaf carrierscarrier {
5121 if-feature carrierscarrier;
5122 type boolean;
5123 default false;
5124 description
5125 "The VPN is using Carrier's Carrier,
5126 and so MPLS is required.";
5128 }
5129 description
5130 "grouping for mpls CsC definition";
5131 }
5133 grouping customer-location-info {
5134 container locations {
5135 list location {
5136 key location-id;
5138 leaf location-id {
5139 type svc-id;
5140 description
5141 "Identifier for a particular location";
5142 }
5143 leaf address {
5144 type string;
5145 description
5146 "Address (number and street)
5147 of the site.";
5149 }
5150 leaf zip-code {
5151 type string;
5152 description
5153 "ZIP code of the site.";
5154 }
5155 leaf state {
5156 type string;
5157 description
5158 "State of the site.
5159 This leaf can also be used
5160 to describe a region
5161 for country who does not have
5162 states.
5163 ";
5164 }
5165 leaf city {
5166 type string;
5167 description
5168 "City of the site.";
5169 }
5170 leaf country-code {
5171 type string;
5172 description
5173 "Country of the site.";
5174 }
5175 description
5176 "Location of the site.";
5177 }
5178 description
5179 "List of locations for the site";
5180 }
5181 description
5182 "This grouping defines customer location
5183 parameters";
5184 }
5186 grouping site-diversity {
5187 container site-diversity {
5188 if-feature site-diversity;
5190 container groups {
5191 list group {
5192 key group-id;
5194 leaf group-id {
5195 type string;
5196 description
5197 "Group-id the site
5198 is belonging to";
5199 }
5200 description
5201 "List of group-id";
5202 }
5203 description
5204 "Groups the site
5205 is belonging to.
5206 All site network accesses will
5207 inherit those group values.";
5208 }
5209 description
5210 "Diversity constraint type.";
5211 }
5212 description
5213 "This grouping defines site diversity
5214 parameters";
5215 }
5216 grouping access-diversity {
5217 container access-diversity {
5218 if-feature site-diversity;
5219 container groups {
5220 list group {
5221 key group-id;
5222 leaf group-id {
5223 type string;
5224 description
5225 "Group-id the site network access
5226 is belonging to";
5227 }
5228 description
5229 "List of group-id";
5230 }
5231 description
5232 "Groups the site network access
5233 is belonging to";
5234 }
5235 container constraints {
5236 list constraint {
5237 key constraint-type;
5239 leaf constraint-type {
5240 type identityref {
5241 base placement-diversity;
5242 }
5243 description
5244 "Diversity constraint type.";
5245 }
5246 container target {
5247 choice target-flavor {
5248 case id {
5249 list group {
5250 key group-id;
5252 leaf group-id {
5253 type string;
5254 description
5255 "The constraint will apply
5256 against this particular
5257 group-id";
5258 }
5259 description
5260 "List of groups";
5261 }
5262 }
5263 case all-accesses {
5264 leaf all-other-accesses {
5265 type empty;
5266 description
5267 "The constraint will apply
5268 against all other site network
5269 access
5270 of this site";
5271 }
5272 }
5273 case all-groups {
5274 leaf all-other-groups {
5275 type empty;
5276 description
5277 "The constraint will apply
5278 against all other groups the
5279 customer
5280 is managing";
5281 }
5282 }
5283 description
5284 "Choice for the group definition";
5285 }
5286 description
5287 "The constraint will apply against
5288 this list of groups";
5289 }
5290 description
5291 "List of constraints";
5292 }
5293 description
5294 "Constraints for placing this site
5295 network access";
5296 }
5298 description
5299 "Diversity parameters.";
5300 }
5301 description
5302 "This grouping defines access diversity
5303 parameters";
5304 }
5306 grouping operational-requirements {
5307 leaf requested-site-start {
5308 type yang:date-and-time;
5309 description
5310 "Optional leaf indicating requested date
5311 and time
5312 when the service at a particular site is
5313 expected
5314 to start";
5315 }
5317 leaf requested-site-stop {
5318 type yang:date-and-time;
5319 description
5320 "Optional leaf indicating requested date
5321 and time
5322 when the service at a particular site is
5323 expected
5324 to stop";
5325 }
5326 description
5327 "This grouping defines some operational parameters
5328 parameters";
5329 }
5330 grouping operational-requirements-ops {
5331 leaf actual-site-start {
5332 type yang:date-and-time;
5333 config false;
5334 description
5335 "Optional leaf indicating actual date
5336 and time
5337 when the service at a particular site
5338 actually
5339 started";
5340 }
5341 leaf actual-site-stop {
5342 type yang:date-and-time;
5343 config false;
5344 description
5345 "Optional leaf indicating actual date
5346 and time
5347 when the service at a particular site
5348 actually
5349 stopped";
5350 }
5351 description
5352 "This grouping defines some operational parameters
5353 parameters";
5354 }
5356 grouping flow-definition {
5357 container match-flow {
5358 leaf dscp {
5359 type uint8 {
5360 range "0 .. 63";
5361 }
5362 description
5363 "DSCP value.";
5364 }
5365 leaf tos {
5366 type uint8 {
5367 range "0 .. 254";
5368 }
5369 description
5370 "TOS value.";
5371 }
5372 leaf dot1p {
5373 type uint8 {
5374 range "0 .. 7";
5375 }
5376 description
5377 "802.1p matching.";
5378 }
5379 leaf ipv4-src-prefix {
5380 type inet:ipv4-prefix;
5381 description
5382 "Match on IPv4 src address.";
5383 }
5384 leaf ipv6-src-prefix {
5385 type inet:ipv6-prefix;
5386 description
5387 "Match on IPv6 src address.";
5388 }
5389 leaf ipv4-dst-prefix {
5390 type inet:ipv4-prefix;
5391 description
5392 "Match on IPv4 dst address.";
5393 }
5394 leaf ipv6-dst-prefix {
5395 type inet:ipv6-prefix;
5396 description
5397 "Match on IPv6 dst address.";
5398 }
5399 leaf l4-src-port {
5400 type uint16;
5401 description
5402 "Match on layer 4 src port.";
5403 }
5404 leaf l4-dst-port {
5405 type uint16;
5406 description
5407 "Match on layer 4 dst port.";
5408 }
5409 leaf protocol-field {
5410 type union {
5411 type uint8;
5412 type identityref {
5413 base protocol-type;
5415 }
5416 }
5417 description
5418 "Match on IPv4 protocol or
5419 Ipv6 Next Header
5420 field.";
5421 }
5423 description
5424 "Describe flow matching
5425 criterions.";
5426 }
5427 description
5428 "Flow definition based on criteria.";
5429 }
5430 grouping site-service-basic {
5431 leaf svc-input-bandwidth {
5432 type uint32;
5433 units bps;
5434 description
5435 "From the PE perspective, the service input
5436 bandwidth of the connection.";
5437 }
5438 leaf svc-output-bandwidth {
5439 type uint32;
5440 units bps;
5441 description
5442 "From the PE perspective, the service output
5443 bandwidth of the connection.";
5444 }
5445 leaf svc-mtu {
5446 type uint16;
5447 units bytes;
5448 description
5449 "MTU at service level.
5450 If the service is IP,
5451 it refers to the IP MTU.";
5452 }
5453 description
5454 "Defines basic service parameters for a site.";
5455 }
5456 grouping site-protection {
5457 container traffic-protection {
5458 if-feature fast-reroute;
5459 leaf enabled {
5460 type boolean;
5461 description
5462 "Enables
5463 traffic protection of access link.";
5464 }
5466 description
5467 "Fast reroute service parameters
5468 for the site.";
5469 }
5470 description
5471 "Defines protection service parameters for a site.";
5472 }
5473 grouping site-service-mpls {
5474 container carrierscarrier {
5475 if-feature carrierscarrier;
5476 leaf signalling-type {
5477 type enumeration {
5478 enum "ldp" {
5479 description
5480 "Use LDP as signalling
5481 protocol between PE and CE.";
5482 }
5483 enum "bgp" {
5484 description
5485 "Use BGP 3107 as signalling
5486 protocol between PE and CE.
5487 In this case, bgp must be also
5488 configured
5489 as routing-protocol.
5490 ";
5491 }
5492 }
5493 description
5494 "MPLS signalling type.";
5495 }
5496 description
5497 "This container is used when customer provides
5498 MPLS based services.
5499 This is used in case of Carrier's
5500 Carrier.";
5501 }
5502 description
5503 "Defines MPLS service parameters for a site.";
5504 }
5505 grouping site-service-qos-profile {
5506 container qos {
5507 if-feature qos;
5508 container qos-classification-policy {
5509 list rule {
5510 key id;
5511 ordered-by user;
5513 leaf id {
5514 type uint16;
5515 description
5516 "ID of the rule.";
5517 }
5519 choice match-type {
5520 case match-flow {
5521 uses flow-definition;
5522 }
5523 case match-application {
5524 leaf match-application {
5525 type identityref {
5526 base customer-application;
5527 }
5528 description
5529 "Defines the application
5530 to match.";
5531 }
5532 }
5533 description
5534 "Choice for classification";
5535 }
5537 leaf target-class-id {
5538 type string;
5539 description
5540 "Identification of the
5541 class of service.
5542 This identifier is internal to
5543 the administration.";
5544 }
5546 description
5547 "List of marking rules.";
5548 }
5549 description
5550 "Need to express marking rules ...";
5551 }
5552 container qos-profile {
5554 choice qos-profile {
5555 description
5556 "Choice for QoS profile.
5557 Can be standard profile or custom.";
5558 case standard {
5559 leaf profile {
5560 type string;
5561 description
5562 "QoS profile to be used";
5563 }
5564 }
5565 case custom {
5566 container classes {
5567 if-feature qos-custom;
5568 list class {
5569 key class-id;
5571 leaf class-id {
5572 type string;
5573 description
5574 "Identification of the
5575 class of service.
5576 This identifier is internal to
5577 the administration.";
5578 }
5579 leaf rate-limit {
5580 type uint8;
5581 units percent;
5582 description
5583 "To be used if class must
5584 be rate
5585 limited. Expressed as
5586 percentage of the svc-bw.";
5587 }
5588 leaf priority-level {
5589 type uint8;
5590 description
5591 "Defines the level of the
5592 class in
5593 term of priority queueing.
5594 The higher the level is the
5595 higher
5596 is the priority.";
5597 }
5598 leaf guaranteed-bw-percent {
5599 type uint8;
5600 units percent;
5601 description
5602 "To be used to define the
5603 guaranteed
5604 BW in percent of the svc-bw
5605 available at the priority-level.";
5606 }
5607 description
5608 "List of class of services.";
5609 }
5610 description
5611 "Container for
5612 list of class of services.";
5613 }
5615 }
5617 }
5618 description
5619 "Qos profile configuration.";
5620 }
5621 description
5622 "QoS configuration.";
5623 }
5624 description
5625 "This grouping defines QoS parameters
5626 for a site";
5628 }
5630 grouping site-security-authentication {
5631 container authentication {
5632 description
5633 "Authentication parameters";
5634 }
5635 description
5636 "This grouping defines authentication
5637 parameters
5638 for a site";
5640 }
5641 grouping site-security-encryption {
5642 container encryption {
5643 if-feature encryption;
5644 leaf enabled {
5645 type boolean;
5646 description
5647 "If true, access encryption is required.";
5648 }
5649 leaf layer {
5650 type enumeration {
5651 enum layer2 {
5652 description
5653 "Encryption will occur at layer2.";
5654 }
5655 enum layer3 {
5656 description
5657 "IPSec is requested.";
5658 }
5659 }
5660 description
5661 "Layer on which encryption is applied.";
5662 }
5663 container encryption-profile {
5664 choice profile {
5665 case provider-profile {
5666 leaf profile-name {
5667 type string;
5668 description
5669 "Name of the SP profile
5670 to be applied.";
5671 }
5672 }
5673 case customer-profile {
5674 leaf algorithm {
5675 type string;
5676 description
5677 "Encryption algorithm to
5678 be used.";
5679 }
5680 choice key-type {
5681 case psk {
5682 leaf preshared-key {
5683 type string;
5684 description
5685 "Key coming from
5686 customer.";
5687 }
5688 }
5689 case pki {
5691 }
5692 description
5693 "Type of keys to be used.";
5694 }
5695 }
5696 description
5697 "Choice of profile.";
5698 }
5699 description
5700 "Profile of encryption to be applied.";
5701 }
5702 description
5703 "Encryption parameters.";
5704 }
5705 description
5706 "This grouping defines encryption parameters
5707 for a site";
5708 }
5710 grouping site-attachment-bearer {
5711 container bearer {
5712 container requested-type {
5713 if-feature requested-type;
5714 leaf requested-type {
5715 type string;
5716 description
5717 "Type of requested bearer Ethernet, DSL,
5718 Wireless ...
5719 Operator specific.";
5720 }
5721 leaf strict {
5722 type boolean;
5723 default false;
5724 description
5725 "define if the requested-type is a preference
5726 or a strict requirement.";
5727 }
5728 description
5729 "Container for requested type.";
5730 }
5731 leaf always-on {
5732 if-feature always-on;
5733 type boolean;
5734 default true;
5735 description
5736 "Request for an always on access type.
5737 This means no Dial access type for
5738 example.";
5739 }
5740 leaf bearer-reference {
5741 if-feature bearer-reference;
5742 type string;
5743 description
5744 "This is an internal reference for the
5745 service provider.
5746 Used ";
5747 }
5748 description
5749 "Bearer specific parameters.
5751 To be augmented.";
5752 }
5753 description
5754 "Defines physical properties of
5755 a site attachment.";
5756 }
5758 grouping site-routing {
5759 container routing-protocols {
5760 list routing-protocol {
5761 key type;
5763 leaf type {
5764 type identityref {
5765 base routing-protocol-type;
5766 }
5767 description
5768 "Type of routing protocol.";
5769 }
5771 container ospf {
5772 when "../type = 'ospf'" {
5773 description
5774 "Only applies
5775 when protocol is OSPF.";
5776 }
5777 if-feature rtg-ospf;
5778 leaf-list address-family {
5779 type identityref {
5780 base address-family;
5781 }
5782 description
5783 "Address family to be activated.";
5784 }
5785 leaf area-address {
5786 type yang:dotted-quad;
5787 description
5788 "Area address.";
5789 }
5790 leaf metric {
5791 type uint16;
5792 description
5793 "Metric of PE-CE link.";
5794 }
5795 container sham-links {
5796 if-feature rtg-ospf-sham-link;
5797 list sham-link {
5798 key target-site;
5800 leaf target-site {
5801 type svc-id;
5802 description
5803 "Target site for the sham link
5804 connection.
5805 The site is referred through it's ID.";
5806 }
5807 leaf metric {
5808 type uint16;
5809 description
5810 "Metric of the sham link.";
5811 }
5812 description
5813 "Creates a shamlink with another
5814 site";
5815 }
5816 description
5817 "List of Sham links";
5818 }
5819 description
5820 "OSPF specific configuration.";
5821 }
5823 container bgp {
5825 when "../type = 'bgp'" {
5826 description
5827 "Only applies when
5828 protocol is BGP.";
5829 }
5830 if-feature rtg-bgp;
5831 leaf autonomous-system {
5832 type uint32;
5833 description
5834 "AS number.";
5835 }
5836 leaf-list address-family {
5837 type identityref {
5838 base address-family;
5839 }
5840 description
5841 "Address family to be activated.";
5842 }
5843 description
5844 "BGP specific configuration.";
5845 }
5846 container static {
5847 when "../type = 'static'" {
5848 description
5849 "Only applies when protocol
5850 is static.";
5851 }
5853 container cascaded-lan-prefixes {
5854 list ipv4-lan-prefixes {
5855 if-feature ipv4;
5856 key "lan next-hop";
5858 leaf lan {
5859 type inet:ipv4-prefix;
5860 description
5861 "Lan prefixes.";
5862 }
5863 leaf lan-tag {
5864 type string;
5865 description
5866 "Internal tag to be used in vpn
5867 policies.";
5868 }
5869 leaf next-hop {
5870 type inet:ipv4-address;
5871 description
5872 "Nexthop address to use at customer
5873 side.";
5874 }
5875 description "
5876 List of LAN prefixes for
5877 the site.
5878 ";
5879 }
5880 list ipv6-lan-prefixes {
5881 if-feature ipv6;
5882 key "lan next-hop";
5884 leaf lan {
5885 type inet:ipv6-prefix;
5886 description
5887 "Lan prefixes.";
5888 }
5889 leaf lan-tag {
5890 type string;
5891 description
5892 "Internal tag to be used
5893 in vpn policies.";
5895 }
5896 leaf next-hop {
5897 type inet:ipv6-address;
5898 description
5899 "Nexthop address to use at
5900 customer side.";
5901 }
5902 description "
5903 List of LAN prefixes for the site.
5904 ";
5905 }
5906 description
5907 "LAN prefixes from the customer.";
5908 }
5909 description
5910 "Static routing
5911 specific configuration.";
5912 }
5913 container rip {
5915 when "../type = 'rip'" {
5916 description
5917 "Only applies when
5918 protocol is RIP.";
5919 }
5920 if-feature rtg-rip;
5921 leaf-list address-family {
5922 type identityref {
5923 base address-family;
5924 }
5925 description
5926 "Address family to be
5927 activated.";
5928 }
5930 description
5931 "RIP routing specific
5932 configuration.";
5933 }
5935 container vrrp {
5937 when "../type = 'vrrp'" {
5938 description
5939 "Only applies when
5940 protocol is VRRP.";
5941 }
5942 if-feature rtg-vrrp;
5943 leaf-list address-family {
5944 type identityref {
5945 base address-family;
5946 }
5947 description
5948 "Address family to be activated.";
5949 }
5950 description
5951 "VRRP routing specific configuration.";
5952 }
5954 description
5955 "List of routing protocols used
5956 on the site.
5957 Need to be augmented.";
5958 }
5959 description
5960 "Defines routing protocols.";
5961 }
5962 description
5963 "Grouping for routing protocols.";
5964 }
5966 grouping site-attachment-ip-connection {
5967 container ip-connection {
5968 container ipv4 {
5969 if-feature ipv4;
5970 leaf address-allocation-type {
5971 type identityref {
5972 base address-allocation-type;
5973 }
5974 default "static-address";
5975 description
5976 "Defines how addresses are allocated.
5977 ";
5978 }
5980 leaf number-of-dynamic-address {
5981 when
5982 "../address-allocation-type = 'provider-dhcp'"
5983 {
5984 description
5985 "Only applies when
5986 addresses are dhcp allocated";
5987 }
5988 type uint8;
5989 default 1;
5990 description
5991 "Describes the number of IP addresses the
5992 customer requires";
5993 }
5994 container dhcp-relay {
5995 when
5996 "../address-allocation-type = 'provider-dhcp-relay'"
5997 {
5998 description
5999 "Only applies when
6000 provider is required to implementations
6001 DHCP relay function";
6002 }
6003 container customer-dhcp-servers {
6004 leaf-list server-ip-address {
6005 type inet:ipv4-address;
6006 description
6007 "IP address of customer DHCP server";
6008 }
6009 description
6010 "Container for list of customer DHCP server";
6011 }
6012 description
6013 "DHCP relay provided by operator.";
6014 }
6015 container addresses {
6016 when
6017 "../address-allocation-type = 'static-address'" {
6018 description
6019 "Only applies when
6020 protocol allocation type is static";
6021 }
6022 leaf provider-address {
6023 type inet:ipv4-address;
6024 description
6025 "Provider side address.";
6026 }
6027 leaf customer-address {
6028 type inet:ipv4-address;
6029 description
6030 "Customer side address.";
6031 }
6032 leaf mask {
6033 type uint8 {
6034 range "0..32";
6035 }
6036 description
6037 "Subnet mask expressed
6038 in bits";
6039 }
6040 description
6041 "Describes IP addresses used";
6042 }
6044 description
6045 "IPv4 specific parameters";
6047 }
6048 container ipv6 {
6049 if-feature ipv6;
6050 leaf address-allocation-type {
6051 type identityref {
6052 base address-allocation-type;
6053 }
6054 default "static-address";
6055 description
6056 "Defines how addresses are allocated.
6057 ";
6058 }
6059 leaf number-of-dynamic-address {
6060 when
6061 "../address-allocation-type = 'provider-dhcp'" {
6062 description
6063 "Only applies when
6064 addresses are dhcp allocated";
6065 }
6066 type uint8;
6067 default 1;
6068 description
6069 "Describes the number of IP addresses the
6070 customer requires";
6071 }
6072 container dhcp-relay {
6073 when
6074 "../address-allocation-type = 'provider-dhcp-relay'"
6075 {
6076 description
6077 "Only applies when
6078 provider is required to implementations
6079 DHCP relay function";
6080 }
6081 container customer-dhcp-servers {
6082 leaf-list server-ip-address {
6083 type inet:ipv6-address;
6084 description
6085 "IP address of customer DHCP server";
6086 }
6087 description
6088 "Container for list of customer DHCP server";
6089 }
6090 description
6091 "DHCP relay provided by operator.";
6092 }
6093 container addresses {
6094 when
6095 "../address-allocation-type = 'static-address'" {
6096 description
6097 "Only applies when
6098 protocol allocation type is static";
6099 }
6100 leaf provider-address {
6101 type inet:ipv6-address;
6102 description
6103 "Provider side address.";
6104 }
6105 leaf customer-address {
6106 type inet:ipv6-address;
6107 description
6108 "Customer side address.";
6109 }
6110 leaf mask {
6111 type uint8 {
6112 range "0..128";
6113 }
6114 description
6115 "Subnet mask expressed
6116 in bits";
6117 }
6118 description
6119 "Describes IP addresses used";
6120 }
6122 description
6123 "IPv6 specific parameters";
6125 }
6126 container oam {
6127 container bfd {
6128 if-feature bfd;
6129 leaf bfd-enabled {
6130 type boolean;
6131 description
6132 "BFD activation";
6133 }
6135 choice holdtime {
6136 case profile {
6137 leaf profile-name {
6138 type string;
6139 description
6140 "Service provider well
6141 known profile.";
6142 }
6143 description
6144 "Service provider well
6145 known profile.";
6146 }
6147 case fixed {
6148 leaf fixed-value {
6149 type uint32;
6150 units msec;
6151 description
6152 "Expected holdtime
6153 expressed
6154 in msec.";
6155 }
6156 }
6157 description
6158 "Choice for holdtime flavor.";
6159 }
6160 description
6161 "Container for BFD.";
6162 }
6163 description
6164 "Define the OAM used on the connection.";
6165 }
6166 description
6167 "Defines connection parameters.";
6168 }
6169 description
6170 "This grouping defines IP connection parameters.";
6171 }
6173 grouping site-service-multicast {
6174 container multicast {
6175 if-feature multicast;
6176 leaf multicast-site-type {
6177 type enumeration {
6178 enum receiver-only {
6179 description
6180 "The site has only receivers.";
6181 }
6182 enum source-only {
6183 description
6184 "The site has only sources.";
6185 }
6186 enum source-receiver {
6187 description
6188 "The site has both
6189 sources & receivers.";
6190 }
6191 }
6192 default "source-receiver";
6193 description
6194 "Type of multicast site.";
6195 }
6196 container multicast-transport-protocol {
6197 leaf ipv4 {
6198 if-feature ipv4;
6199 type boolean;
6200 default true;
6201 description
6202 "Enables ipv4 multicast transport";
6203 }
6204 leaf ipv6 {
6205 if-feature ipv6;
6206 type boolean;
6207 default false;
6208 description
6209 "Enables ipv6 multicast transport";
6210 }
6211 description
6212 "Defines protocol to transport multicast.";
6213 }
6214 leaf protocol-type {
6215 type enumeration {
6216 enum host {
6217 description
6218 "
6219 Hosts are directly connected
6220 to the provider network.
6221 Host protocols like IGMP, MLD
6222 are required.
6223 ";
6224 }
6225 enum router {
6226 description
6227 "
6228 Hosts are behind a customer router.
6229 PIM will be implemented.
6230 ";
6231 }
6232 enum both {
6233 description
6234 "Some Hosts are behind a customer
6235 router and some others are directly
6236 connected to the provider network.
6237 Both host and routing protocols must be
6238 used. Typically IGMP and PIM will be
6239 implemented.
6240 ";
6241 }
6242 }
6243 default "both";
6244 description
6245 "Multicast protocol type to be used
6246 with the customer site.";
6247 }
6249 description
6250 "Multicast parameters for the site.";
6251 }
6252 description
6253 "Multicast parameters for the site.";
6254 }
6256 grouping site-management {
6257 container management {
6258 leaf type {
6259 type identityref {
6260 base management;
6261 }
6262 description
6263 "Management type of the connection.";
6264 }
6265 description
6266 "Management configuration";
6267 }
6268 description
6269 "Management parameters for the site.";
6270 }
6272 grouping site-devices {
6273 container devices {
6274 must "/l3vpn-svc/sites/site/management/type = "+
6275 "'provider-managed' or "+
6276 "/l3vpn-svc/sites/site/management/type ="+
6277 "'co-managed'" {
6278 description
6279 "Applicable only for provider-managed or
6280 co-managed device";
6281 }
6282 list device {
6283 key device-id;
6285 leaf device-id {
6286 type svc-id;
6287 description
6288 "identifier for the device";
6289 }
6290 leaf location {
6291 type leafref {
6292 path "/l3vpn-svc/sites/site/locations/"+
6293 "location/location-id";
6294 }
6295 description
6296 "Location of the device";
6297 }
6298 container management {
6299 must "/l3vpn-svc/sites/site/management/type"+
6300 "= 'co-managed'" {
6301 description
6302 "Applicable only for
6303 co-managed device";
6304 }
6305 leaf management-transport {
6306 type identityref {
6307 base address-family;
6308 }
6309 description
6310 "Transport protocol used for management.";
6311 }
6312 leaf address {
6313 type inet:ip-address;
6314 description
6315 "Management address";
6316 }
6317 description
6318 "Management configuration. Only for
6319 co-managed case.";
6320 }
6321 description
6322 "Device configuration";
6323 }
6324 description
6325 "List of devices requested by customer";
6326 }
6327 description
6328 "Grouping for device allocation";
6329 }
6330 grouping site-vpn-flavor {
6331 leaf site-vpn-flavor {
6332 type identityref {
6333 base site-vpn-flavor;
6334 }
6335 default site-vpn-flavor-single;
6336 description
6337 "Defines if the site
6338 is a single VPN site, or multiVPN or ...";
6339 }
6340 description
6341 "Grouping for site-vpn-flavor.";
6342 }
6344 grouping site-vpn-policy {
6345 container vpn-policy-list {
6346 list vpn-policy {
6347 key vpn-policy-id;
6349 leaf vpn-policy-id {
6350 type svc-id;
6351 description
6352 "Unique identifier for
6353 the VPN policy.";
6354 }
6356 list entries {
6357 key id;
6359 leaf id {
6360 type svc-id;
6361 description
6362 "Unique identifier for
6363 the policy entry.";
6364 }
6365 container filter {
6366 choice lan {
6367 case lan-prefix {
6368 container lan-prefixes {
6369 list ipv4-lan-prefixes {
6370 if-feature ipv4;
6371 key lan;
6372 leaf lan {
6373 type inet:ipv4-prefix;
6374 description
6375 "Lan prefixes.";
6376 }
6377 description "
6378 List of LAN prefixes
6379 for the site.
6380 ";
6381 }
6382 list ipv6-lan-prefixes {
6383 if-feature ipv6;
6384 key lan;
6386 leaf lan {
6387 type inet:ipv6-prefix;
6388 description
6389 "Lan prefixes.";
6390 }
6391 description "
6392 List of LAN prefixes
6393 for the site.
6394 ";
6395 }
6396 description
6397 "LAN prefixes from the customer.";
6398 }
6399 }
6400 case lan-tag {
6401 leaf-list lan-tag {
6402 type string;
6403 description
6404 "List of lan-tags to be matched.";
6405 }
6406 }
6407 description
6408 "Choice for LAN matching type";
6409 }
6410 description
6411 "If used, it permit to split site LANs
6412 among multiple VPNs.
6413 If no filter used, all the LANs will be
6414 part of the same VPNs with the same
6415 role.";
6416 }
6417 container vpn {
6418 leaf vpn-id {
6419 type leafref {
6420 path "/l3vpn-svc/vpn-services/vpn-svc/vpn-id";
6421 }
6422 mandatory true;
6423 description
6424 "Reference to an IPVPN.";
6425 }
6426 leaf site-role {
6427 type identityref {
6428 base site-role;
6429 }
6430 mandatory true;
6431 description
6432 "Role of the site in the IPVPN.";
6433 }
6434 description
6435 "List of VPNs the LAN is associated to.";
6436 }
6437 description
6438 "List of entries for export policy.";
6439 }
6440 description
6441 "List of VPN policies.";
6442 }
6443 description
6444 "VPN policy.";
6445 }
6446 description
6447 "VPN policy parameters for the site.";
6448 }
6450 grouping site-maximum-routes {
6451 container maximum-routes {
6452 list address-family {
6453 key af;
6455 leaf af {
6456 type identityref {
6457 base address-family;
6458 }
6459 description
6460 "Address-family.";
6461 }
6462 leaf maximum-routes {
6463 type uint32;
6464 description
6465 "Maximum prefixes the VRF can
6466 accept for this
6467 address-family.";
6468 }
6469 description
6470 "List of address families.";
6471 }
6473 description
6474 "Define maximum-routes for the VRF.";
6475 }
6476 description
6477 "Define maximum-routes for the site.";
6478 }
6480 grouping site-security {
6481 container security {
6482 uses site-security-authentication;
6483 uses site-security-encryption;
6485 description
6486 "Site specific security parameters.";
6487 }
6488 description
6489 "Grouping for security parameters.";
6490 }
6492 grouping site-service {
6493 container service {
6494 uses site-service-qos-profile;
6495 uses site-service-mpls;
6496 uses site-service-multicast;
6498 description
6499 "Service parameters on the attachement.";
6500 }
6501 description
6502 "Grouping for service parameters.";
6503 }
6505 grouping site-network-access-service {
6506 container service {
6507 uses site-service-basic;
6508 uses site-service-qos-profile;
6509 uses site-service-mpls;
6510 uses site-service-multicast;
6512 description
6513 "Service parameters on the attachement.";
6515 }
6516 description
6517 "Grouping for service parameters.";
6518 }
6520 grouping transport-constraint {
6521 list constraint-list {
6522 key constraint-type;
6524 leaf constraint-type {
6525 type identityref {
6526 base transport-constraint;
6527 }
6528 description
6529 "Constraint type to be applied.";
6530 }
6531 leaf constraint-opaque-value {
6532 type string;
6533 description
6534 "Opaque value that can be used to
6535 specify constraint parameters.";
6536 }
6537 description
6538 "List of constraints";
6539 }
6540 description
6541 "Grouping for transport constraint.";
6542 }
6544 grouping transport-constraints {
6545 container transport-constraints {
6546 if-feature traffic-engineering;
6547 container unicast-transport-constraints {
6548 list constraint {
6549 key constraint-id;
6551 leaf constraint-id {
6552 type svc-id;
6553 description
6554 "Defines an ID for the constraint
6555 rule.";
6556 }
6558 leaf site1 {
6559 type svc-id;
6560 description
6561 "The ID refers to one site end.";
6562 }
6563 leaf site2 {
6564 type svc-id;
6565 description
6566 "The ID refers to the other
6567 site end.";
6568 }
6569 uses transport-constraint;
6570 description
6571 "List of constraints.
6572 Constraints are bidirectional.";
6573 }
6574 description
6575 "Unicast transport constraints.";
6576 }
6577 container multicast-transport-constraints {
6578 if-feature traffic-engineering-multicast;
6579 list constraint {
6580 key constraint-id;
6582 leaf constraint-id {
6583 type svc-id;
6584 description
6585 "Defines an ID for the constraint
6586 rule.";
6587 }
6589 leaf src-site {
6590 type svc-id;
6591 description
6592 "The ID refers to source site.";
6593 }
6594 leaf dst-site {
6595 type svc-id;
6596 description
6597 "The ID refers to the receiver
6598 site.";
6599 }
6600 uses transport-constraint;
6601 description
6602 "List of constraints.
6603 Constraints are unidirectional.";
6604 }
6605 description
6606 "Multicast transport constraints.";
6607 }
6608 description
6609 "transport constraints.";
6610 }
6611 description
6612 "Grouping for transport constraints
6613 description.";
6614 }
6616 grouping vpn-extranet {
6617 container extranet-vpns {
6618 if-feature extranet-vpn;
6619 list extranet-vpn {
6620 key vpn-id;
6622 leaf vpn-id {
6623 type svc-id;
6624 description
6625 "Identifies the target VPN";
6626 }
6627 leaf local-sites-role {
6628 type identityref {
6629 base site-role;
6630 }
6631 description
6632 "This describes the role of the
6633 local sites in the target VPN topology.";
6634 }
6635 description
6636 "List of extranet VPNs the local
6637 VPN is attached to.";
6638 }
6639 description
6640 "Container for extranet vpn cfg.";
6641 }
6642 description
6643 "grouping for extranet VPN configuration.
6644 Extranet provides a way to interconnect all sites
6645 from two VPNs in a easy way.";
6647 }
6649 grouping site-attachment-availability {
6650 container availability {
6651 leaf access-priority {
6652 type uint32;
6653 default 1;
6654 description
6655 "Defines the priority for the access.
6656 The highest the priority value is,
6657 the highest the
6658 preference of the access is.";
6660 }
6661 description
6662 "Availability parameters
6663 (used for multihoming)";
6664 }
6665 description
6666 "Defines site availability parameters.";
6667 }
6669 grouping access-vpn-policy {
6670 container vpn-attachment {
6672 choice attachment-flavor {
6673 case vpn-policy-id {
6674 leaf vpn-policy-id {
6675 type leafref {
6676 path "/l3vpn-svc/sites/site/"+
6677 "vpn-policy-list/vpn-policy/"+
6678 "vpn-policy-id";
6679 }
6680 description
6681 "Reference to a VPN policy.";
6682 }
6683 }
6684 case vpn-id {
6685 leaf vpn-id {
6686 type leafref {
6687 path "/l3vpn-svc/vpn-services"+
6688 "/vpn-svc/vpn-id";
6689 }
6690 description
6691 "Reference to a VPN.";
6692 }
6693 leaf site-role {
6694 type identityref {
6695 base site-role;
6696 }
6697 mandatory true;
6698 description
6699 "Role of the site in the IPVPN.";
6700 }
6701 }
6702 mandatory true;
6703 description
6704 "Choice for VPN attachment flavor.";
6705 }
6706 description
6707 "Defines VPN attachment of a site.";
6709 }
6710 description
6711 "Defines the VPN attachment rules
6712 for a site logical access.";
6713 }
6715 grouping vpn-svc-cfg {
6716 leaf vpn-id {
6717 type svc-id;
6718 description
6719 "VPN identifier. Local administration meaning.";
6720 }
6721 leaf customer-name {
6722 type string;
6723 description
6724 "Name of the customer.";
6725 }
6726 leaf vpn-service-topology {
6727 type identityref {
6728 base vpn-topology;
6729 }
6730 default "any-to-any";
6731 description
6732 "VPN service topology.";
6733 }
6735 uses vpn-service-cloud-access;
6736 uses vpn-service-multicast;
6737 uses vpn-service-mpls;
6738 uses transport-constraints;
6739 uses vpn-extranet;
6741 description
6742 "grouping for vpn-svc configuration.";
6743 }
6745 grouping site-top-level-cfg {
6746 uses operational-requirements;
6747 uses customer-location-info;
6748 uses site-devices;
6749 uses site-diversity;
6750 uses site-management;
6751 uses site-vpn-policy;
6752 uses site-vpn-flavor;
6753 uses site-maximum-routes;
6754 uses site-security;
6755 uses site-service;
6756 uses site-protection;
6757 uses site-routing;
6759 description
6760 "Grouping for site top level cfg.";
6761 }
6762 grouping site-network-access-top-level-cfg {
6763 leaf site-network-access-type {
6764 type identityref {
6765 base site-network-access-type;
6766 }
6767 default "point-to-point";
6768 description
6769 "Describes the type of connection, e.g. :
6770 point-to-point or multipoint";
6771 }
6773 choice location-flavor {
6774 case location {
6775 when "/l3vpn-svc/sites/site/management/type = "+
6776 "'customer-managed'" {
6777 description
6778 "Applicable only for customer-managed";
6779 }
6780 leaf location-reference {
6781 type leafref {
6782 path "/l3vpn-svc/sites/site/locations/"+
6783 "location/location-id";
6784 }
6785 description
6786 "Location of the site-network-access";
6787 }
6788 }
6789 case device {
6790 when "/l3vpn-svc/sites/site/management/type = "+
6791 "'provider-managed' or "+
6792 "/l3vpn-svc/sites/site/management/type = "+
6793 "'co-managed'" {
6794 description
6795 "Applicable only for provider-managed or
6796 co-managed device";
6797 }
6798 leaf device-reference {
6799 type leafref {
6800 path "/l3vpn-svc/sites/site/devices/"+
6801 "device/device-id";
6802 }
6803 description
6804 "Identifier of CE to use";
6806 }
6807 }
6808 mandatory true;
6809 description
6810 "Choice on how to describe the site location";
6811 }
6813 uses access-diversity;
6814 uses site-attachment-bearer;
6815 uses site-attachment-ip-connection;
6816 uses site-security;
6817 uses site-network-access-service;
6818 uses site-routing;
6819 uses site-attachment-availability;
6820 uses access-vpn-policy;
6822 description
6823 "Grouping for site network access
6824 top level cfg.";
6825 }
6827 /* Main blocks */
6829 container l3vpn-svc {
6830 container vpn-services {
6831 list vpn-svc {
6832 key vpn-id;
6834 uses vpn-svc-cfg;
6836 description "
6837 List of VPN services.
6838 ";
6839 }
6840 description
6841 "top level container
6842 for the VPN services.";
6843 }
6845 container sites {
6846 list site {
6847 key site-id;
6849 leaf site-id {
6850 type svc-id;
6851 description
6852 "Identifier of the site.";
6853 }
6854 uses site-top-level-cfg;
6855 uses operational-requirements-ops;
6857 container site-network-accesses {
6858 list site-network-access {
6859 key site-network-access-id;
6861 leaf site-network-access-id {
6862 type svc-id;
6863 description
6864 "Identifier for the access";
6865 }
6866 uses site-network-access-top-level-cfg;
6868 description
6869 "List of accesses for a site.";
6870 }
6871 description
6872 "List of accesses for a site.";
6873 }
6875 description "List of sites.";
6876 }
6877 description
6878 "Container for sites";
6879 }
6881 description
6882 "Main container for L3VPN service configuration.";
6883 }
6885 }
6886
6888 9. Security Considerations
6890 The YANG modules defined in this document MAY be accessed via the
6891 RESTCONF protocol [I-D.ietf-netconf-restconf] or NETCONF protocol
6892 ([RFC6241]. The lowest RESTCONF or NETCONF layer requires that the
6893 transport-layer protocol provides both data integrity and
6894 confidentiality, see Section 2 in [I-D.ietf-netconf-restconf] and
6895 [RFC6241]. The client MUST carefully examine the certificate
6896 presented by the server to determine if it meets the client's
6897 expectations, and the server MUST authenticate client access to any
6898 protected resource. The client identity derived from the
6899 authentication mechanism used is subject to the NETCONF Access
6900 Control Module (NACM) ([RFC6536]). Other protocols to access this
6901 YANG module are also required to support the similar mechanism.
6903 The data nodes defined in the "ietf-l3vpn-svc" YANG module MUST be
6904 carefully created/read/updated/deleted. The entries in the lists
6905 below include customer proprietary or confidential information,
6906 therefore only authorized clients MUST access the information and the
6907 other clients MUST NOT be able to access to the information.
6909 o /l3vpn-svc/vpn-services/vpn-svc
6911 o /l3vpn-svc/sites/site
6913 10. Acknowledgements
6915 Thanks to Qin Wu, Maxim Klyus, Luis Miguel Contreras, Gregory Mirsky,
6916 Zitao Wang, Jing Zhao, Kireeti Kompella, Eric Rosen, Aijun Wang,
6917 Michael Scharf, Xufeng Liu, David Ball, Lucy yong, Jean-Philippe
6918 Landry, Rob Shakir and Andrew Leu for the contributions to the
6919 document.
6921 11. IANA Considerations
6923 The IANA is requested to assign a new URI from the IETF XML registry
6924 ([RFC3688]). Authors are suggesting the following URI :
6926 URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
6927 Registrant Contact: L3SM WG
6928 XML: N/A, the requested URI is an XML namespace
6930 This document also requests a new YANG module name in the YANG Module
6931 Names registry ([RFC7950]) with the following suggestion :
6933 name: ietf-l3vpn-svc
6934 namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
6935 prefix: l3vpn-svc
6936 reference: RFC XXXX
6938 12. Change Log
6940 12.1. Changes between versions -15 and-16
6942 o Rename "topology" leaf to "vpn-service-topology"
6944 12.2. Changes between versions -13 and-14
6946 o Choice between device reference and location reference.
6948 12.3. Changes between versions -12 and-13
6950 o Removed rip-ng identity (rip container has AF information)
6952 o renamed pe-dhcp to provider-dhcp
6954 o add provider-dhcp-relay identity and container
6956 o BW/MTU is now only under site-network-access
6958 o Add list of location and location ID
6960 o Site-network-access mapped to location Identifier
6962 o Add list of devices (provided by operator) requested by customer
6964 o Some management parameters moved under device list
6966 o Site-network-access mapped to device identifier
6968 12.4. Changes between versions -11 and-12
6970 o Fixing some 'when' statements that prevented compilation.
6972 12.5. Changes between versions -09 and-10
6974 o Removed templates.
6976 o Add site-network-access-type.
6978 o Add a leaf number-of-dynamic-address in case of pe-dhcp
6979 addressing.
6981 12.6. Changes between versions -08 and-09
6983 o Add site-vpn-flavor NNI.
6985 12.7. Changes between versions -07 and-08
6987 o Traffic protection moved to site level.
6989 o Decouple operational-requirements in two containers.
6991 12.8. Changes between versions -06 and-07
6993 o Set config false to actual-site-start and stop.
6995 o Add a container before cloud-access list.
6997 o Add a container before authorized-sites list.
6999 o Add a container before denied-sites list.
7001 o Modified access-diversity modeling.
7003 o Replacing type placement diversity by an identity.
7005 12.9. Changes between versions -05 and-06
7007 o Added linecard diverse for site diversity
7009 o Added a new diversity enum in placement-diversity : none
7011 o Added state to site location
7013 o remove reference to core routing model : created new address
7014 family identities
7016 o added features
7018 o Modified bearer parameters
7020 o Modified union for ipv4/ipv6 addresses to ip-address type
7022 o Add BSR parameters for multicast
7024 o Add applications matching for QoS classification
7026 12.10. Changes between versions -04 and-05
7028 o Modify VPN policy and creating a vpn-policy-list
7030 o Add VPN policy reference and VPN ID reference under site-network-
7031 access
7033 12.11. Changes between versions -02 and-03
7035 o Add extranet-vpn container in vpn-svc
7037 o Creating top level containers
7038 o Refine groupings
7040 o Added site-vpn-flavor
7042 o qos-profile moved to choice
7044 o vpn leaf moved to vpn-id in vpn-policy
7046 o added ordered-by user to qos classification list
7048 o moved traffic protection to access availability
7050 o creating a choice in matching filter for VPN policy
7052 o added dot1p matching field in flow-definition
7054 12.12. Changes between versions -01 and-02
7056 o A site is now a collection of site-accesses. This was introduced
7057 to support M to N availability.
7059 o Site-availability has been removed, replaced by availability
7060 parameters under site-accesses
7062 o Added transport-constraints within vpn-svc
7064 o Add ToS support in match-flow
7066 o nexthop in cascaded lan as mandatory
7068 o customer-specific-info deleted and moved to routing protocols
7070 o customer-lan-connection modified : need prefix and CE address
7072 o add choice in managing PE-CE addressing
7074 o Simplifying traffic protection
7076 o Refine groupings for vpn-svc
7078 o Removed name in vpn-svc
7080 o id in vpn-svc moved to string
7082 o Rename id in vpn-svc to vpn-id
7084 o Changed key of vpn-svc list to vpn-id
7085 o Add DSCP support in flow definition
7087 o Removed ACL from security
7089 o Add FW for site and cloud access
7091 12.13. Changes between versions -00 and-01
7093 o Creating multiple reusable groupings
7095 o Added mpls leaf in vpn-svc for carrier's carrier case
7097 o Modify identity single to single-site
7099 o Modify site-type to site-role and also child identities.
7101 o Creating OAM container under site and moved BFD in.
7103 o Creating flow-definition grouping to be reused in ACL, QoS ...
7105 o Simplified VPN policy.
7107 o Adding multicast static group to RP mappings.
7109 o Removed native-vpn and site-role from global site cfg, now managed
7110 within the VPN policy.
7112 o Creating a separate list for site templates.
7114 13. References
7116 13.1. Normative References
7118 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
7119 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
7120 RFC2119, March 1997,
7121 .
7123 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
7124 DOI 10.17487/RFC3688, January 2004,
7125 .
7127 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
7128 Private Network (VPN) Terminology", RFC 4026, DOI
7129 10.17487/RFC4026, March 2005,
7130 .
7132 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
7133 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
7134 2006, .
7136 [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the
7137 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
7138 Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577,
7139 June 2006, .
7141 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
7142 Address Autoconfiguration", RFC 4862, DOI 10.17487/
7143 RFC4862, September 2007,
7144 .
7146 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
7147 and A. Bierman, Ed., "Network Configuration Protocol
7148 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
7149 .
7151 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
7152 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
7153 2012, .
7155 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
7156 RFC 7950, DOI 10.17487/RFC7950, August 2016,
7157 .
7159 13.2. Informative References
7161 [I-D.ietf-netconf-restconf]
7162 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
7163 Protocol", draft-ietf-netconf-restconf-16 (work in
7164 progress), August 2016.
7166 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
7167 Provider-Provisioned Virtual Private Networks (PPVPNs)",
7168 RFC 4110, DOI 10.17487/RFC4110, July 2005,
7169 .
7171 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
7172 Protocol (NETCONF) Access Control Model", RFC 6536, DOI
7173 10.17487/RFC6536, March 2012,
7174 .
7176 Authors' Addresses
7178 Stephane Litkowski
7179 Orange Business Services
7181 Email: stephane.litkowski@orange.com
7183 Luis Tomotaki
7184 Verizon
7186 Email: luis.tomotaki@verizon.com
7188 Kenichi Ogaki
7189 KDDI
7191 Email: ke-oogaki@kddi.com