idnits 2.17.1
draft-wu-l3sm-rfc8049bis-07.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 166 instances of too long lines in the document, the longest
one being 70 characters in excess of 72.
== 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 482 has weird spacing: '...--rw id str...'
== Line 484 has weird spacing: '...--rw id str...'
== Line 486 has weird spacing: '...--rw id str...'
== Line 488 has weird spacing: '...--rw id str...'
== Line 562 has weird spacing: '...roup-id str...'
== (16 more instances...)
-- The document date (October 13, 2017) is 2386 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)
** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341)
** Obsolete normative reference: RFC 8049 (Obsoleted by RFC 8299)
Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group Q. Wu, Ed.
3 Internet-Draft Huawei
4 Obsoletes: 8049 (if approved) S. Litkowski
5 Intended status: Standards Track Orange
6 Expires: April 16, 2018 L. Tomotaki
7 Verizon
8 K. Ogaki
9 KDDI Corporation
10 October 13, 2017
12 YANG Data Model for L3VPN Service Delivery
13 draft-wu-l3sm-rfc8049bis-07
15 Abstract
17 This document defines a YANG data model that can be used for
18 communication between customers and network operators and to deliver
19 a Layer 3 provider-provisioned VPN service. This document is limited
20 to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This
21 model is intended to be instantiated at the management system to
22 deliver the overall service. It is not a configuration model to be
23 used directly on network elements. This model provides an abstracted
24 view of the Layer 3 IP VPN service configuration components. It will
25 be up to the management system to take this model as input and use
26 specific configuration models to configure the different network
27 elements to deliver the service. How the configuration of network
28 elements is done is out of scope for this document.
30 This document obsoletes RFC 8049 to replace the unimplementable
31 module in that RFC with a new module with the same name that is not
32 backward compatible. The changes are a series of small fixes to the
33 YANG module, and some clarifications to the text.
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 https://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 April 16, 2018.
51 Copyright Notice
53 Copyright (c) 2017 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
69 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
70 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
71 1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
72 1.4. Summary of Changes from RFC 8049 . . . . . . . . . . . . 5
73 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 6
74 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
75 4. Layer 3 IP VPN Service Model . . . . . . . . . . . . . . . . 9
76 5. Service Data Model Usage . . . . . . . . . . . . . . . . . . 9
77 6. Design of the Data Model . . . . . . . . . . . . . . . . . . 11
78 6.1. Features and Augmentation . . . . . . . . . . . . . . . . 20
79 6.2. VPN Service Overview . . . . . . . . . . . . . . . . . . 20
80 6.2.1. VPN Service Topology . . . . . . . . . . . . . . . . 20
81 6.2.2. Cloud Access . . . . . . . . . . . . . . . . . . . . 23
82 6.2.3. Multicast Service . . . . . . . . . . . . . . . . . . 26
83 6.2.4. Extranet VPNs . . . . . . . . . . . . . . . . . . . . 28
84 6.3. Site Overview . . . . . . . . . . . . . . . . . . . . . . 29
85 6.3.1. Devices and Locations . . . . . . . . . . . . . . . . 31
86 6.3.2. Site Network Accesses . . . . . . . . . . . . . . . . 31
87 6.4. Site Role . . . . . . . . . . . . . . . . . . . . . . . . 34
88 6.5. Site Belonging to Multiple VPNs . . . . . . . . . . . . . 34
89 6.5.1. Site VPN Flavor . . . . . . . . . . . . . . . . . . . 34
90 6.5.2. Attaching a Site to a VPN . . . . . . . . . . . . . . 38
91 6.6. Deciding Where to Connect the Site . . . . . . . . . . . 44
92 6.6.1. Constraint: Device . . . . . . . . . . . . . . . . . 45
93 6.6.2. Constraint/Parameter: Site Location . . . . . . . . . 45
94 6.6.3. Constraint/Parameter: Access Type . . . . . . . . . . 47
95 6.6.4. Constraint: Access Diversity . . . . . . . . . . . . 47
96 6.6.5. Infeasible Access Placement . . . . . . . . . . . . . 57
97 6.6.6. Examples of Access Placement . . . . . . . . . . . . 57
98 6.6.7. Route Distinguisher and VRF Allocation . . . . . . . 78
99 6.7. Site Network Access Availability . . . . . . . . . . . . 79
100 6.8. Traffic Protection . . . . . . . . . . . . . . . . . . . 80
101 6.9. Security . . . . . . . . . . . . . . . . . . . . . . . . 81
102 6.9.1. Authentication . . . . . . . . . . . . . . . . . . . 81
103 6.9.2. Encryption . . . . . . . . . . . . . . . . . . . . . 81
104 6.10. Management . . . . . . . . . . . . . . . . . . . . . . . 82
105 6.11. Routing Protocols . . . . . . . . . . . . . . . . . . . . 83
106 6.11.1. Handling of Dual Stack . . . . . . . . . . . . . . . 83
107 6.11.2. LAN Directly Connected to SP Network . . . . . . . . 85
108 6.11.3. LAN Directly Connected to SP Network with Redundancy 85
109 6.11.4. Static Routing . . . . . . . . . . . . . . . . . . . 86
110 6.11.5. RIP Routing . . . . . . . . . . . . . . . . . . . . 86
111 6.11.6. OSPF Routing . . . . . . . . . . . . . . . . . . . . 87
112 6.11.7. BGP Routing . . . . . . . . . . . . . . . . . . . . 88
113 6.12. Service . . . . . . . . . . . . . . . . . . . . . . . . . 90
114 6.12.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . 91
115 6.12.2. MTU . . . . . . . . . . . . . . . . . . . . . . . . 91
116 6.12.3. QoS . . . . . . . . . . . . . . . . . . . . . . . . 91
117 6.12.4. Multicast . . . . . . . . . . . . . . . . . . . . . 100
118 6.13. Enhanced VPN Features . . . . . . . . . . . . . . . . . . 100
119 6.13.1. Carriers' Carriers . . . . . . . . . . . . . . . . . 100
120 6.14. External ID References . . . . . . . . . . . . . . . . . 102
121 6.15. Defining NNIs . . . . . . . . . . . . . . . . . . . . . . 102
122 6.15.1. Defining an NNI with the Option A Flavor . . . . . . 104
123 6.15.2. Defining an NNI with the Option B Flavor . . . . . . 107
124 6.15.3. Defining an NNI with the Option C Flavor . . . . . . 110
125 7. Service Model Usage Example . . . . . . . . . . . . . . . . . 111
126 8. Interaction with Other YANG Modules . . . . . . . . . . . . . 117
127 9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 122
128 10. Security Considerations . . . . . . . . . . . . . . . . . . . 180
129 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 180
130 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 181
131 12.1. Normative References . . . . . . . . . . . . . . . . . . 181
132 12.2. Informative References . . . . . . . . . . . . . . . . . 182
133 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 182
134 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 183
135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 183
137 1. Introduction
139 This document defines a Layer 3 VPN service data model written in
140 YANG. The model defines service configuration elements that can be
141 used in communication protocols between customers and network
142 operators. Those elements can also be used as input to automated
143 control and configuration applications.
145 The YANG module described in [RFC8049] cannot be implemented because
146 of issues around the use of XPATH. This document obsoletes [RFC8049]
147 by creating a new module with the same name that is not backward
148 compatible (in the sense described in YANG 1.1 [RFC7950]). The
149 changes (listed in full in Section 1.4) are small in scope, but
150 include fixes to the module to make it possible to implement.
152 1.1. Terminology
154 The following terms are defined in [RFC6241] and are not redefined
155 here:
157 o client
159 o configuration data
161 o server
163 o state data
165 The following terms are defined in [RFC7950] and are not redefined
166 here:
168 o augment
170 o data model
172 o data node
174 The terminology for describing YANG data models is found in
175 [RFC7950].
177 This document presents some configuration examples using XML
178 representation.
180 1.2. Requirements Language
182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
184 document are to be interpreted as described in [RFC2119].
186 1.3. Tree Diagrams
188 A simplified graphical representation of the data model is presented
189 in Section 6.
191 The meanings of the symbols in these diagrams are as follows:
193 o Brackets "[" and "]" enclose list keys.
195 o Curly braces "{" and "}" contain names of optional features that
196 make the corresponding node conditional.
198 o Abbreviations before data node names: "rw" means configuration
199 data (read-write), and "ro" means state data (read-only).
201 o Symbols after data node names: "?" means an optional node, and "*"
202 denotes a "list" or "leaf-list".
204 o Parentheses enclose choice and case nodes, and case nodes are also
205 marked with a colon (":").
207 o Ellipsis ("...") stands for contents of subtrees that are not
208 shown.
210 1.4. Summary of Changes from RFC 8049
212 This document revises and obsoletes L3VPN Service Model [RFC8049] ,
213 drawing on insights gained from L3VPN Service Model deployments and
214 on feedback from the community. The major changes are:
216 o Change type from 16-bit integer to string for the leaf id under
217 "qos-classification-policy" container.
219 o Stick to using ordered-by user and remove inefficiency to map
220 service model sequence number to device model sequence number.
222 o Remove mandating the use of deviations and add "if-feature target-
223 sites" under the leaf-list target-sites in section 6.12.2.
225 o RFC2119 language changes on operation of the management system in
226 Section 6.6,3rd paragraph,Section 6.6.5 and section 7.
228 o Fix incomplete description statements.
230 o Add YANG statement to check that slaac parameters are used only
231 for IPv6.
233 o Fix strange wording in the section 6.11.7.
235 o Change the use of the absolute paths to the use of relative paths
236 in the "must" statement or "path" statement for vpn-policy-id leaf
237 node, management container, location leaf node, devices container,
238 location case, location-reference leaf, device case, device-
239 reference leaf to make configuration is only applicable to the
240 current sites.
242 o Change "must" statement to "when" statement for management
243 container device container.
245 o Fix optional parameter issues by adding a default or description
246 for others or make some of them mandatory.
248 o Define new grouping vpn-profile-cfg for all the identifiers
249 provided by SP to the customer. The identifiers include cloud-
250 identifier, std-qos-profile, OAM profile-name, and provider-
251 profile for encryption.
253 o Add in the XPATH string representation of identityrefs and remove
254 unqualified name. Change from YANG 1.0 Support to YANG 1.1
255 Support.
257 o Remove "when" statement from leaf nat44-customer-address.
259 o Fixed broken example and Add mandatory element in the examples.
261 o Remove redundant parameters in the cloud access.
263 o Specify provider address and a list of start-end addresses from
264 provider address for DHCP case.
266 o Add a few text to clarify what the site is in section 6.3.
268 o Add multi-filter and multi-VPN per entry support for VPN policy.
270 o Modify description for svc-input-bandwidth leaf and svc-output-
271 bandwidth leaf to make it consistent with the text in section
272 6.12.1.
274 o Clarify the rational of the model in the section 5.
276 o Add text to clarify the way to achieve Per-VPN QoS policy.
278 2. Acronyms
280 AAA: Authentication, Authorization, and Accounting.
282 ACL: Access Control List.
284 ADSL: Asymmetric DSL.
286 AH: Authentication Header.
288 AS: Autonomous System.
290 ASBR: Autonomous System Border Router.
292 ASM: Any-Source Multicast.
294 BAS: Broadband Access Switch.
296 BFD: Bidirectional Forwarding Detection.
298 BGP: Border Gateway Protocol.
300 BSR: Bootstrap Router.
302 CE: Customer Edge.
304 CLI: Command Line Interface.
306 CsC: Carriers' Carriers.
308 CSP: Cloud Service Provider.
310 DHCP: Dynamic Host Configuration Protocol.
312 DSLAM: Digital Subscriber Line Access Multiplexer.
314 ESP: Encapsulating Security Payload.
316 GRE: Generic Routing Encapsulation.
318 IGMP: Internet Group Management Protocol.
320 LAN: Local Area Network.
322 MLD: Multicast Listener Discovery.
324 MTU: Maximum Transmission Unit.
326 NAT: Network Address Translation.
328 NETCONF: Network Configuration Protocol.
330 NNI: Network-to-Network Interface.
332 OAM: Operations, Administration, and Maintenance.
334 OSPF: Open Shortest Path First.
336 OSS: Operations Support System.
338 PE: Provider Edge.
340 PIM: Protocol Independent Multicast.
342 POP: Point of Presence.
344 QoS: Quality of Service.
346 RD: Route Distinguisher.
348 RIP: Routing Information Protocol.
350 RP: Rendezvous Point.
352 RT: Route Target.
354 SFTP: Secure FTP.
356 SLA: Service Level Agreement.
358 SLAAC: Stateless Address Autoconfiguration.
360 SP: Service Provider.
362 SPT: Shortest Path Tree.
364 SSM: Source-Specific Multicast.
366 VM: Virtual Machine.
368 VPN: Virtual Private Network.
370 VRF: VPN Routing and Forwarding.
372 VRRP: Virtual Router Redundancy Protocol.
374 3. Definitions
376 Customer Edge (CE) Device: A CE is equipment dedicated to a
377 particular customer; it is directly connected (at Layer 3) to one or
378 more PE devices via attachment circuits. A CE is usually located at
379 the customer premises and is usually dedicated to a single VPN,
380 although it may support multiple VPNs if each one has separate
381 attachment circuits.
383 Provider Edge (PE) Device: A PE is equipment managed by the SP; it
384 can support multiple VPNs for different customers and is directly
385 connected (at Layer 3) to one or more CE devices via attachment
386 circuits. A PE is usually located at an SP point of presence (POP)
387 and is managed by the SP.
389 PE-Based VPNs: The PE devices know that certain traffic is VPN
390 traffic. They forward the traffic (through tunnels) based on the
391 destination IP address of the packet and, optionally, based on other
392 information in the IP header of the packet. The PE devices are
393 themselves the tunnel endpoints. The tunnels may make use of various
394 encapsulations to send traffic over the SP network (such as, but not
395 restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels).
397 4. Layer 3 IP VPN Service Model
399 A Layer 3 IP VPN service is a collection of sites that are authorized
400 to exchange traffic between each other over a shared IP
401 infrastructure. This Layer 3 VPN service model aims at providing a
402 common understanding of how the corresponding IP VPN service is to be
403 deployed over the shared infrastructure. This service model is
404 limited to BGP PE-based VPNs as described in [RFC4026], [RFC4110],
405 and [RFC4364].
407 5. Service Data Model Usage
408 l3vpn-svc |
409 Model |
410 |
411 +------------------+ +-----+
412 | Orchestration | < --- > | OSS |
413 +------------------+ +-----+
414 | |
415 +----------------+ |
416 | Config manager | |
417 +----------------+ |
418 | |
419 | NETCONF/CLI ...
420 | |
421 +------------------------------------------------+
422 Network
424 +++++++
425 + AAA +
426 +++++++
428 ++++++++ Bearer ++++++++ ++++++++ ++++++++
429 + CE A + ----------- + PE A + + PE B + ---- + CE B +
430 ++++++++ Connection ++++++++ ++++++++ ++++++++
432 Site A Site B
434 The idea of the L3 IP VPN service model is to propose an abstracted
435 interface between customers and network operators to manage
436 configuration of components of an L3VPN service. The model is
437 intended to be used in a mode where the network operator's system is
438 the server and the customer's system is the client. A typical
439 scenario would be to use this model as an input for an orchestration
440 layer that will be responsible for translating it to an orchestrated
441 configuration of network elements that will be part of the service.
442 The network elements can be routers but can also be servers (like
443 AAA); the network's configuration is not limited to these examples.
444 The configuration of network elements can be done via the CLI,
445 NETCONF/RESTCONF [RFC6241] [RFC8040] coupled with YANG data models of
446 a specific configuration (BGP, VRF, BFD, etc.), or some other
447 technique, as preferred by the operator.
449 The usage of this service model is not limited to this example; it
450 can be used by any component of the management system but not
451 directly by network elements.
453 6. Design of the Data Model
455 The YANG module is divided into two main containers: "vpn-services"
456 and "sites".
458 The "vpn-service" list under the vpn-services container defines
459 global parameters for the VPN service for a specific customer.
461 A "site" is composed of at least one "site-network-access" and, in
462 the case of multihoming, may have multiple site-network-access
463 points. The site-network-access attachment is done through a
464 "bearer" with an "ip-connection" on top. The bearer refers to
465 properties of the attachment that are below Layer 3, while the
466 connection refers to properties oriented to the Layer 3 protocol.
467 The bearer may be allocated dynamically by the SP, and the customer
468 may provide some constraints or parameters to drive the placement of
469 the access.
471 Authorization of traffic exchange is done through what we call a VPN
472 policy or VPN service topology defining routing exchange rules
473 between sites.
475 The figure below describes the overall structure of the YANG module:
477 module: ietf-l3vpn-svc
478 +--rw l3vpn-svc
479 +--rw vpn-profiles
480 | +--rw valid-provider-identifiers
481 | +--rw cloud-identifier* [id] {cloud-access}?
482 | | +--rw id string
483 | +--rw encryption-profile-identifier* [id]
484 | | +--rw id string
485 | +--rw qos-profile-identifier* [id]
486 | | +--rw id string
487 | +--rw bfd-profile-identifier* [id]
488 | +--rw id string
489 +--rw vpn-services
490 | +--rw vpn-service* [vpn-id]
491 | +--rw vpn-id svc-id
492 | +--rw customer-name? string
493 | +--rw vpn-service-topology? identityref
494 | +--rw cloud-accesses {cloud-access}?
495 | | +--rw cloud-access* [cloud-identifier]
496 | | +--rw cloud-identifier -> /l3vpn-svc/vpn-profiles/valid-provider-identifiers/cloud-identifier/id
497 | | +--rw (list-flavor)?
498 | | | +--:(permit-any)
499 | | | | +--rw permit-any? empty
500 | | | +--:(deny-any-except)
501 | | | | +--rw permit-site* -> /l3vpn-svc/sites/site/site-id
502 | | | +--:(permit-any-except)
503 | | | +--rw deny-site* -> /l3vpn-svc/sites/site/site-id
504 | | +--rw address-translation
505 | | +--rw nat44
506 | | +--rw enabled? boolean
507 | | +--rw nat44-customer-address? inet:ipv4-address
508 | +--rw multicast {multicast}?
509 | | +--rw enabled? boolean
510 | | +--rw customer-tree-flavors
511 | | | +--rw tree-flavor* identityref
512 | | +--rw rp
513 | | +--rw rp-group-mappings
514 | | | +--rw rp-group-mapping* [id]
515 | | | +--rw id uint16
516 | | | +--rw provider-managed
517 | | | | +--rw enabled? boolean
518 | | | | +--rw rp-redundancy? boolean
519 | | | | +--rw optimal-traffic-delivery? boolean
520 | | | +--rw rp-address inet:ip-address
521 | | | +--rw groups
522 | | | +--rw group* [id]
523 | | | +--rw id uint16
524 | | | +--rw (group-format)
525 | | | +--:(singleaddress)
526 | | | | +--rw group-address? inet:ip-address
527 | | | +--:(startend)
528 | | | +--rw group-start? inet:ip-address
529 | | | +--rw group-end? inet:ip-address
530 | | +--rw rp-discovery
531 | | +--rw rp-discovery-type? identityref
532 | | +--rw bsr-candidates
533 | | +--rw bsr-candidate-address* inet:ip-address
534 | +--rw carrierscarrier? boolean {carrierscarrier}?
535 | +--rw extranet-vpns {extranet-vpn}?
536 | +--rw extranet-vpn* [vpn-id]
537 | +--rw vpn-id svc-id
538 | +--rw local-sites-role? identityref
539 +--rw sites
540 +--rw site* [site-id]
541 +--rw site-id svc-id
542 +--rw requested-site-start? yang:date-and-time
543 +--rw requested-site-stop? yang:date-and-time
544 +--rw locations
545 | +--rw location* [location-id]
546 | +--rw location-id svc-id
547 | +--rw address? string
548 | +--rw postal-code? string
549 | +--rw state? string
550 | +--rw city? string
551 | +--rw country-code? string
552 +--rw devices
553 | +--rw device* [device-id]
554 | +--rw device-id svc-id
555 | +--rw location -> ../../../locations/location/location-id
556 | +--rw management
557 | +--rw address-family? address-family
558 | +--rw address? inet:ip-address
559 +--rw site-diversity {site-diversity}?
560 | +--rw groups
561 | +--rw group* [group-id]
562 | +--rw group-id string
563 +--rw management
564 | +--rw type identityref
565 +--rw vpn-policies
566 | +--rw vpn-policy* [vpn-policy-id]
567 | +--rw vpn-policy-id svc-id
568 | +--rw entries* [id]
569 | +--rw id svc-id
570 | +--rw filters
571 | | +--rw filter* [type]
572 | | +--rw type identityref
573 | | +--rw lan-tag* string {lan-tag}?
574 | | +--rw ipv4-lan-prefix* inet:ipv4-prefix {ipv4}?
575 | | +--rw ipv6-lan-prefix* inet:ipv6-prefix {ipv6}?
576 | +--rw vpn* [vpn-id]
577 | +--rw vpn-id -> /l3vpn-svc/vpn-services/vpn-service/vpn-id
578 | +--rw site-role? identityref
579 +--rw site-vpn-flavor? identityref
580 +--rw maximum-routes
581 | +--rw address-family* [af]
582 | +--rw af address-family
583 | +--rw maximum-routes? uint32
584 +--rw security
585 | +--rw authentication
586 | +--rw encryption {encryption}?
587 | +--rw enabled? boolean
588 | +--rw layer? enumeration
589 | +--rw encryption-profile
590 | +--rw (profile)?
591 | +--:(provider-profile)
592 | | +--rw profile-name? -> /l3vpn-svc/vpn-profiles/valid-provider-identifiers/encryption-profile-identifier/id
593 | +--:(customer-profile)
594 | +--rw algorithm? string
595 | +--rw (key-type)?
596 | +--:(psk)
597 | +--rw preshared-key? string
598 +--rw service
599 | +--rw qos {qos}?
600 | | +--rw qos-classification-policy
601 | | | +--rw rule* [id]
602 | | | +--rw id string
603 | | | +--rw (match-type)?
604 | | | | +--:(match-flow)
605 | | | | | +--rw match-flow
606 | | | | | +--rw dscp? inet:dscp
607 | | | | | +--rw dot1p? uint8
608 | | | | | +--rw ipv4-src-prefix? inet:ipv4-prefix
609 | | | | | +--rw ipv6-src-prefix? inet:ipv6-prefix
610 | | | | | +--rw ipv4-dst-prefix? inet:ipv4-prefix
611 | | | | | +--rw ipv6-dst-prefix? inet:ipv6-prefix
612 | | | | | +--rw l4-src-port? inet:port-number
613 | | | | | +--rw target-sites* svc-id {target-sites}?
614 | | | | | +--rw l4-src-port-range
615 | | | | | | +--rw lower-port? inet:port-number
616 | | | | | | +--rw upper-port? inet:port-number
617 | | | | | +--rw l4-dst-port? inet:port-number
618 | | | | | +--rw l4-dst-port-range
619 | | | | | | +--rw lower-port? inet:port-number
620 | | | | | | +--rw upper-port? inet:port-number
621 | | | | | +--rw protocol-field? union
622 | | | | +--:(match-application)
623 | | | | +--rw match-application? identityref
624 | | | +--rw target-class-id? string
625 | | +--rw qos-profile
626 | | +--rw (qos-profile)?
627 | | +--:(standard)
628 | | | +--rw profile? -> /l3vpn-svc/vpn-profiles/valid-provider-identifiers/qos-profile-identifier/id
629 | | +--:(custom)
630 | | +--rw classes {qos-custom}?
631 | | +--rw class* [class-id]
632 | | +--rw class-id string
633 | | +--rw direction? identityref
634 | | +--rw rate-limit? uint8
635 | | +--rw latency
636 | | | +--rw (flavor)?
637 | | | +--:(lowest)
638 | | | | +--rw use-lowest-latency? empty
639 | | | +--:(boundary)
640 | | | +--rw latency-boundary? uint16
641 | | +--rw jitter
642 | | | +--rw (flavor)?
643 | | | +--:(lowest)
644 | | | | +--rw use-lowest-jitter? empty
645 | | | +--:(boundary)
646 | | | +--rw latency-boundary? uint32
647 | | +--rw bandwidth
648 | | +--rw guaranteed-bw-percent uint8
649 | | +--rw end-to-end? empty
650 | +--rw carrierscarrier {carrierscarrier}?
651 | | +--rw signalling-type? enumeration
652 | +--rw multicast {multicast}?
653 | +--rw multicast-site-type? enumeration
654 | +--rw multicast-address-family
655 | | +--rw ipv4? boolean {ipv4}?
656 | | +--rw ipv6? boolean {ipv6}?
657 | +--rw protocol-type? enumeration
658 +--rw traffic-protection {fast-reroute}?
659 | +--rw enabled? boolean
660 +--rw routing-protocols
661 | +--rw routing-protocol* [type]
662 | +--rw type identityref
663 | +--rw ospf {rtg-ospf}?
664 | | +--rw address-family* address-family
665 | | +--rw area-address yang:dotted-quad
666 | | +--rw metric? uint16
667 | | +--rw sham-links {rtg-ospf-sham-link}?
668 | | +--rw sham-link* [target-site]
669 | | +--rw target-site svc-id
670 | | +--rw metric? uint16
671 | +--rw bgp {rtg-bgp}?
672 | | +--rw autonomous-system uint32
673 | | +--rw address-family* address-family
674 | +--rw static
675 | | +--rw cascaded-lan-prefixes
676 | | +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}?
677 | | | +--rw lan inet:ipv4-prefix
678 | | | +--rw lan-tag? string
679 | | | +--rw next-hop inet:ipv4-address
680 | | +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}?
681 | | +--rw lan inet:ipv6-prefix
682 | | +--rw lan-tag? string
683 | | +--rw next-hop inet:ipv6-address
684 | +--rw rip {rtg-rip}?
685 | | +--rw address-family* address-family
686 | +--rw vrrp {rtg-vrrp}?
687 | +--rw address-family* address-family
688 +--ro actual-site-start? yang:date-and-time
689 +--ro actual-site-stop? yang:date-and-time
690 +--rw site-network-accesses
691 +--rw site-network-access* [site-network-access-id]
692 +--rw site-network-access-id svc-id
693 +--rw site-network-access-type? identityref
694 +--rw (location-flavor)
695 | +--:(location)
696 | | +--rw location-reference? -> ../../../locations/location/location-id
697 | +--:(device)
698 | +--rw device-reference? -> ../../../devices/device/device-id
699 +--rw access-diversity {site-diversity}?
700 | +--rw groups
701 | | +--rw group* [group-id]
702 | | +--rw group-id string
703 | +--rw constraints
704 | +--rw constraint* [constraint-type]
705 | +--rw constraint-type identityref
706 | +--rw target
707 | +--rw (target-flavor)?
708 | +--:(id)
709 | | +--rw group* [group-id]
710 | | +--rw group-id string
711 | +--:(all-accesses)
712 | | +--rw all-other-accesses? empty
713 | +--:(all-groups)
714 | +--rw all-other-groups? empty
715 +--rw bearer
716 | +--rw requested-type {requested-type}?
717 | | +--rw requested-type? string
718 | | +--rw strict? boolean
719 | +--rw always-on? boolean {always-on}?
720 | +--rw bearer-reference? string {bearer-reference}?
721 +--rw ip-connection
722 | +--rw ipv4 {ipv4}?
723 | | +--rw address-allocation-type? identityref
724 | | +--rw provider-dhcp
725 | | | +--rw provider-address? inet:ipv4-address
726 | | | +--rw mask? uint8
727 | | | +--rw (address-assign)?
728 | | | +--:(number)
729 | | | | +--rw number-of-dynamic-address? uint16
730 | | | +--:(explicit)
731 | | | +--rw customer-addresses
732 | | | +--rw address-group* [group-id]
733 | | | +--rw group-id string
734 | | | +--rw start-address? inet:ipv4-address
735 | | | +--rw end-address? inet:ipv4-address
736 | | +--rw dhcp-relay
737 | | | +--rw provider-address? inet:ipv4-address
738 | | | +--rw mask? uint8
739 | | | +--rw customer-dhcp-servers
740 | | | +--rw server-ip-address* inet:ipv4-address
741 | | +--rw addresses
742 | | +--rw provider-address? inet:ipv4-address
743 | | +--rw customer-address? inet:ipv4-address
744 | | +--rw mask? uint8
745 | +--rw ipv6 {ipv6}?
746 | | +--rw address-allocation-type? identityref
747 | | +--rw provider-dhcp
748 | | | +--rw provider-address? inet:ipv6-address
749 | | | +--rw mask? uint8
750 | | | +--rw (address-assign)?
751 | | | +--:(number)
752 | | | | +--rw number-of-dynamic-address? uint16
753 | | | +--:(explicit)
754 | | | +--rw customer-addresses
755 | | | +--rw address-group* [group-id]
756 | | | +--rw group-id string
757 | | | +--rw start-address? inet:ipv6-address
758 | | | +--rw end-address? inet:ipv6-address
759 | | +--rw dhcp-relay
760 | | | +--rw provider-address? inet:ipv6-address
761 | | | +--rw mask? uint8
762 | | | +--rw customer-dhcp-servers
763 | | | +--rw server-ip-address* inet:ipv6-address
764 | | +--rw addresses
765 | | +--rw provider-address? inet:ipv6-address
766 | | +--rw customer-address? inet:ipv6-address
767 | | +--rw mask? uint8
768 | +--rw oam
769 | +--rw bfd {bfd}?
770 | +--rw enabled? boolean
771 | +--rw (holdtime)?
772 | +--:(fixed)
773 | | +--rw fixed-value? uint32
774 | +--:(profile)
775 | +--rw profile-name? -> /l3vpn-svc/vpn-profiles/valid-provider-identifiers/bfd-profile-identifier/id
776 +--rw security
777 | +--rw authentication
778 | +--rw encryption {encryption}?
779 | +--rw enabled? boolean
780 | +--rw layer? enumeration
781 | +--rw encryption-profile
782 | +--rw (profile)?
783 | +--:(provider-profile)
784 | | +--rw profile-name? -> /l3vpn-svc/vpn-profiles/valid-provider-identifiers/encryption-profile-identifier/id
785 | +--:(customer-profile)
786 | +--rw algorithm? string
787 | +--rw (key-type)?
788 | +--:(psk)
789 | +--rw preshared-key? string
790 +--rw service
791 | +--rw svc-input-bandwidth uint64
792 | +--rw svc-output-bandwidth uint64
793 | +--rw svc-mtu uint16
794 | +--rw qos {qos}?
795 | | +--rw qos-classification-policy
796 | | | +--rw rule* [id]
797 | | | +--rw id string
798 | | | +--rw (match-type)?
799 | | | | +--:(match-flow)
800 | | | | | +--rw match-flow
801 | | | | | +--rw dscp? inet:dscp
802 | | | | | +--rw dot1p? uint8
803 | | | | | +--rw ipv4-src-prefix? inet:ipv4-prefix
804 | | | | | +--rw ipv6-src-prefix? inet:ipv6-prefix
805 | | | | | +--rw ipv4-dst-prefix? inet:ipv4-prefix
806 | | | | | +--rw ipv6-dst-prefix? inet:ipv6-prefix
807 | | | | | +--rw l4-src-port? inet:port-number
808 | | | | | +--rw target-sites* svc-id {target-sites}?
809 | | | | | +--rw l4-src-port-range
810 | | | | | | +--rw lower-port? inet:port-number
811 | | | | | | +--rw upper-port? inet:port-number
812 | | | | | +--rw l4-dst-port? inet:port-number
813 | | | | | +--rw l4-dst-port-range
814 | | | | | | +--rw lower-port? inet:port-number
815 | | | | | | +--rw upper-port? inet:port-number
816 | | | | | +--rw protocol-field? union
817 | | | | +--:(match-application)
818 | | | | +--rw match-application? identityref
819 | | | +--rw target-class-id? string
820 | | +--rw qos-profile
821 | | +--rw (qos-profile)?
822 | | +--:(standard)
823 | | | +--rw profile? -> /l3vpn-svc/vpn-profiles/valid-provider-identifiers/qos-profile-identifier/id
824 | | +--:(custom)
825 | | +--rw classes {qos-custom}?
826 | | +--rw class* [class-id]
827 | | +--rw class-id string
828 | | +--rw direction? identityref
829 | | +--rw rate-limit? uint8
830 | | +--rw latency
831 | | | +--rw (flavor)?
832 | | | +--:(lowest)
833 | | | | +--rw use-lowest-latency? empty
834 | | | +--:(boundary)
835 | | | +--rw latency-boundary? uint16
836 | | +--rw jitter
837 | | | +--rw (flavor)?
838 | | | +--:(lowest)
839 | | | | +--rw use-lowest-jitter? empty
840 | | | +--:(boundary)
841 | | | +--rw latency-boundary? uint32
842 | | +--rw bandwidth
843 | | +--rw guaranteed-bw-percent uint8
844 | | +--rw end-to-end? empty
845 | +--rw carrierscarrier {carrierscarrier}?
846 | | +--rw signalling-type? enumeration
847 | +--rw multicast {multicast}?
848 | +--rw multicast-site-type? enumeration
849 | +--rw multicast-address-family
850 | | +--rw ipv4? boolean {ipv4}?
851 | | +--rw ipv6? boolean {ipv6}?
852 | +--rw protocol-type? enumeration
853 +--rw routing-protocols
854 | +--rw routing-protocol* [type]
855 | +--rw type identityref
856 | +--rw ospf {rtg-ospf}?
857 | | +--rw address-family* address-family
858 | | +--rw area-address yang:dotted-quad
859 | | +--rw metric? uint16
860 | | +--rw sham-links {rtg-ospf-sham-link}?
861 | | +--rw sham-link* [target-site]
862 | | +--rw target-site svc-id
863 | | +--rw metric? uint16
864 | +--rw bgp {rtg-bgp}?
865 | | +--rw autonomous-system uint32
866 | | +--rw address-family* address-family
867 | +--rw static
868 | | +--rw cascaded-lan-prefixes
869 | | +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}?
870 | | | +--rw lan inet:ipv4-prefix
871 | | | +--rw lan-tag? string
872 | | | +--rw next-hop inet:ipv4-address
873 | | +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}?
874 | | +--rw lan inet:ipv6-prefix
875 | | +--rw lan-tag? string
876 | | +--rw next-hop inet:ipv6-address
877 | +--rw rip {rtg-rip}?
878 | | +--rw address-family* address-family
879 | +--rw vrrp {rtg-vrrp}?
880 | +--rw address-family* address-family
881 +--rw availability
882 | +--rw access-priority? uint32
883 +--rw vpn-attachment
884 +--rw (attachment-flavor)
885 +--:(vpn-policy-id)
886 | +--rw vpn-policy-id? -> ../../../../vpn-policies/vpn-policy/vpn-policy-id
887 +--:(vpn-id)
888 +--rw vpn-id? -> /l3vpn-svc/vpn-services/vpn-service/vpn-id
889 +--rw site-role? identityref
891 6.1. Features and Augmentation
893 The model defined in this document implements many features that
894 allow implementations to be modular. As an example, an
895 implementation may support only IPv4 VPNs (IPv4 feature), IPv6 VPNs
896 (IPv6 feature), or both (by advertising both features). The routing
897 protocols proposed to the customer may also be enabled through
898 features. This model also defines some features for options that are
899 more advanced, such as support for extranet VPNs (Section 6.2.4),
900 site diversity (Section 6.6), and QoS (Section 6.12.3).
902 In addition, as for any YANG model, this service model can be
903 augmented to implement new behaviors or specific features. For
904 example, this model uses different options for IP address
905 assignments; if those options do not fulfill all requirements, new
906 options can be added through augmentation.
908 6.2. VPN Service Overview
910 A vpn-service list item contains generic information about the VPN
911 service. The "vpn-id" provided in the vpn-service list refers to an
912 internal reference for this VPN service, while the customer name
913 refers to a more-explicit reference to the customer. This identifier
914 is purely internal to the organization responsible for the VPN
915 service.
917 6.2.1. VPN Service Topology
919 The type of VPN service topology is required for configuration. Our
920 proposed model supports any-to-any, Hub and Spoke (where Hubs can
921 exchange traffic), and "Hub and Spoke disjoint" (where Hubs cannot
922 exchange traffic). New topologies could be added via augmentation.
923 By default, the any-to-any VPN service topology is used.
925 6.2.1.1. Route Target Allocation
927 A Layer 3 PE-based VPN is built using route targets (RTs) as
928 described in [RFC4364]. The management system is expected to
929 automatically allocate a set of RTs upon receiving a VPN service
930 creation request. How the management system allocates RTs is out of
931 scope for this document, but multiple ways could be envisaged, as
932 described below.
934 Management system
935 <------------------------------------------------->
936 Request RT
937 +-----------------------+ Topo a2a +----------+
938 RESTCONF | | -----> | |
939 User ------------- | Service Orchestration | | Network |
940 l3vpn-svc | | <----- | OSS |
941 Model +-----------------------+ Response +----------+
942 RT1, RT2
944 In the example above, a service orchestration, owning the
945 instantiation of this service model, requests RTs to the network OSS.
946 Based on the requested VPN service topology, the network OSS replies
947 with one or multiple RTs. The interface between this service
948 orchestration and the network OSS is out of scope for this document.
950 +---------------------------+
951 RESTCONF | |
952 User ------------- | Service Orchestration |
953 l3vpn-svc | |
954 Model | |
955 | RT pool: 10:1->10:10000 |
956 | RT pool: 20:50->20:5000 |
957 +---------------------------+
959 In the example above, a service orchestration, owning the
960 instantiation of this service model, owns one or more pools of RTs
961 (specified by the SP) that can be allocated. Based on the requested
962 VPN service topology, it will allocate one or multiple RTs from the
963 pool.
965 The mechanisms shown above are just examples and should not be
966 considered an exhaustive list of solutions.
968 6.2.1.2. Any-to-Any
969 +------------------------------------------------------------+
970 | VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 |
971 | |
972 | VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 |
973 +------------------------------------------------------------+
975 Any-to-Any VPN Service Topology
977 In the any-to-any VPN service topology, all VPN sites can communicate
978 with each other without any restrictions. The management system that
979 receives an any-to-any IP VPN service request through this model is
980 expected to assign and then configure the VRF and RTs on the
981 appropriate PEs. In the any-to-any case, a single RT is generally
982 required, and every VRF imports and exports this RT.
984 6.2.1.3. Hub and Spoke
986 +-------------------------------------------------------------+
987 | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
988 | +----------------------------------+
989 | |
990 | +----------------------------------+
991 | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
992 +-------------------------------------------------------------+
994 Hub-and-Spoke VPN Service Topology
996 In the Hub-and-Spoke VPN service topology, all Spoke sites can
997 communicate only with Hub sites but not with each other, and Hubs can
998 also communicate with each other. The management system that owns an
999 any-to-any IP VPN service request through this model is expected to
1000 assign and then configure the VRF and RTs on the appropriate PEs. In
1001 the Hub-and-Spoke case, two RTs are generally required (one RT for
1002 Hub routes and one RT for Spoke routes). A Hub VRF that connects Hub
1003 sites will export Hub routes with the Hub RT and will import Spoke
1004 routes through the Spoke RT. It will also import the Hub RT to allow
1005 Hub-to-Hub communication. A Spoke VRF that connects Spoke sites will
1006 export Spoke routes with the Spoke RT and will import Hub routes
1007 through the Hub RT.
1009 The management system MUST take into account constraints on Hub-and-
1010 Spoke connections. For example, if a management system decides to
1011 mesh a Spoke site and a Hub site on the same PE, it needs to mesh
1012 connections in different VRFs, as shown in the figure below.
1014 Hub_Site ------- (VRF_Hub) PE1
1015 (VRF_Spoke)
1016 / |
1017 Spoke_Site1 -------------------+ |
1018 |
1019 Spoke_Site2 -----------------------+
1021 6.2.1.4. Hub and Spoke Disjoint
1023 +-------------------------------------------------------------+
1024 | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
1025 +--------------------------+ +-------------------------------+
1026 | |
1027 +--------------------------+ +-------------------------------+
1028 | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
1029 +-------------------------------------------------------------+
1031 Hub and Spoke Disjoint VPN Service Topology
1033 In the Hub and Spoke disjoint VPN service topology, all Spoke sites
1034 can communicate only with Hub sites but not with each other, and Hubs
1035 cannot communicate with each other. The management system that owns
1036 an any-to-any IP VPN service request through this model is expected
1037 to assign and then configure the VRF and RTs on the appropriate PEs.
1038 In the Hub-and-Spoke case, two RTs are required (one RT for Hub
1039 routes and one RT for Spoke routes). A Hub VRF that connects Hub
1040 sites will export Hub routes with the Hub RT and will import Spoke
1041 routes through the Spoke RT. A Spoke VRF that connects Spoke sites
1042 will export Spoke routes with the Spoke RT and will import Hub routes
1043 through the Hub RT.
1045 The management system MUST take into account constraints on Hub-and-
1046 Spoke connections, as in the previous case.
1048 Hub and Spoke disjoint can also be seen as multiple Hub-and-Spoke
1049 VPNs (one per Hub) that share a common set of Spoke sites.
1051 6.2.2. Cloud Access
1053 The proposed model provides cloud access configuration via the
1054 "cloud-accesses" container. The usage of cloud-access is targeted
1055 for the public cloud. An Internet access can also be considered a
1056 public cloud access service. The cloud-accesses container provides
1057 parameters for network address translation and authorization rules.
1059 A private cloud access may be addressed through NNIs, as described in
1060 Section 6.15.
1062 A cloud identifier is used to reference the target service. This
1063 identifier is local to each administration.
1065 The model allows for source address translation before accessing the
1066 cloud. IPv4-to-IPv4 address translation (NAT44) is the only
1067 supported option, but other options can be added through
1068 augmentation. If IP source address translation is required to access
1069 the cloud, the "enabled" leaf MUST be set to true in the "nat44"
1070 container. An IP address may be provided in the "customer-address"
1071 leaf if the customer is providing the IP address to be used for the
1072 cloud access. If the SP is providing this address, "customer-
1073 address" is not necessary, as it can be picked from a pool of SPs.
1075 By default, all sites in the IP VPN MUST be authorized to access the
1076 cloud. If restrictions are required, a user MAY configure the
1077 "permit-site" or "deny-site" leaf-list. The permit-site leaf-list
1078 defines the list of sites authorized for cloud access. The deny-site
1079 leaf-list defines the list of sites denied for cloud access. The
1080 model supports both "deny-any-except" and "permit-any-except"
1081 authorization.
1083 How the restrictions will be configured on network elements is out of
1084 scope for this document.
1086 IP VPN
1087 ++++++++++++++++++++++++++++++++ ++++++++++++
1088 + Site 3 + --- + Cloud 1 +
1089 + Site 1 + ++++++++++++
1090 + +
1091 + Site 2 + --- ++++++++++++
1092 + + + Internet +
1093 + Site 4 + ++++++++++++
1094 ++++++++++++++++++++++++++++++++
1095 |
1096 +++++++++++
1097 + Cloud 2 +
1098 +++++++++++
1100 In the example above, we configure the global VPN to access the
1101 Internet by creating a cloud-access pointing to the cloud identifier
1102 for the Internet service. No authorized sites will be configured, as
1103 all sites are required to access the Internet. The "address-
1104 translation/nat44/enabled" leaf will be set to true.
1106
1107
1108
1109
1110 123456487
1111
1112
1113 INTERNET
1114
1115
1116 true
1117
1118
1119
1120
1121
1122
1123
1125 If Site 1 and Site 2 require access to Cloud 1, a new cloud-access
1126 pointing to the cloud identifier of Cloud 1 will be created. The
1127 permit-site leaf-list will be filled with a reference to Site 1 and
1128 Site 2.
1130
1131
1132
1133
1134 123456487
1135
1136
1137 Cloud1
1138 site1
1139 site2
1140
1141
1142
1143
1144
1146 If all sites except Site 1 require access to Cloud 2, a new cloud-
1147 access pointing to the cloud identifier of Cloud 2 will be created.
1148 The deny-site leaf-list will be filled with a reference to Site 1.
1150
1151
1152
1153
1154 123456487
1155
1156
1157 Cloud2
1158 site1
1159
1160
1161
1162
1163
1165 A service with more than one cloud access is functionally identical
1166 to multiple services each with a single cloud access, where the sites
1167 that belong to each service in the latter case correspond with the
1168 authorized sites for each cloud access in the former case. However,
1169 defining a single service with multiple cloud accesses may be
1170 operationally simpler.
1172 6.2.3. Multicast Service
1174 Multicast in IP VPNs is described in [RFC6513].
1176 If multicast support is required for an IP VPN, some global multicast
1177 parameters are required as input for the service request.
1179 Users of this model will need to provide the flavors of trees that
1180 will be used by customers within the IP VPN (customer tree). The
1181 proposed model supports bidirectional, shared, and source-based trees
1182 (and can be augmented). Multiple flavors of trees can be supported
1183 simultaneously.
1185 Operator network
1186 ______________
1187 / \
1188 | |
1189 (SSM tree) |
1190 Recv (IGMPv3) -- Site2 ------- PE2 |
1191 | PE1 --- Site1 --- Source1
1192 | | \
1193 | | -- Source2
1194 | |
1195 (ASM tree) |
1196 Recv (IGMPv2) -- Site3 ------- PE3 |
1197 | |
1198 (SSM tree) |
1199 Recv (IGMPv3) -- Site4 ------- PE4 |
1200 | / |
1201 Recv (IGMPv2) -- Site5 -------- |
1202 (ASM tree) |
1203 | |
1204 \_______________/
1206 When an ASM flavor is requested, this model requires that the "rp"
1207 and "rp-discovery" parameters be filled. Multiple RP-to-group
1208 mappings can be created using the "rp-group-mappings" container. For
1209 each mapping, the SP can manage the RP service by setting the
1210 "provider-managed/enabled" leaf to true. In the case of a provider-
1211 managed RP, the user can request RP redundancy and/or optimal traffic
1212 delivery. Those parameters will help the SP select the appropriate
1213 technology or architecture to fulfill the customer service
1214 requirement: for instance, in the case of a request for optimal
1215 traffic delivery, an SP may use Anycast-RP or RP-tree-to-SPT
1216 switchover architectures.
1218 In the case of a customer-managed RP, the RP address must be filled
1219 in the RP-to-group mappings using the "rp-address" leaf. This leaf
1220 is not needed for a provider-managed RP.
1222 Users can define a specific mechanism for RP discovery, such as the
1223 "auto-rp", "static-rp", or "bsr-rp" modes. By default, the model
1224 uses "static-rp" if ASM is requested. A single rp-discovery
1225 mechanism is allowed for the VPN. The "rp-discovery" container can
1226 be used for both provider-managed and customer-managed RPs. In the
1227 case of a provider-managed RP, if the user wants to use "bsr-rp" as a
1228 discovery protocol, an SP should consider the provider-managed "rp-
1229 group-mappings" for the "bsr-rp" configuration. The SP will then
1230 configure its selected RPs to be "bsr-rp-candidates". In the case of
1231 a customer-managed RP and a "bsr-rp" discovery mechanism, the "rp-
1232 address" provided will be the bsr-rp candidate.
1234 6.2.4. Extranet VPNs
1236 There are some cases where a particular VPN needs access to resources
1237 (servers, hosts, etc.) that are external. Those resources may be
1238 located in another VPN.
1240 +-----------+ +-----------+
1241 / \ / \
1242 Site A -- | VPN A | --- | VPN B | --- Site B
1243 \ / \ / (Shared
1244 +-----------+ +-----------+ resources)
1246 In the figure above, VPN B has some resources on Site B that need to
1247 be available to some customers/partners. VPN A must be able to
1248 access those VPN B resources.
1250 Such a VPN connection scenario can be achieved via a VPN policy as
1251 defined in Section 6.5.2.2. But there are some simple cases where a
1252 particular VPN (VPN A) needs access to all resources in another VPN
1253 (VPN B). The model provides an easy way to set up this connection
1254 using the "extranet-vpns" container.
1256 The extranet-vpns container defines a list of VPNs a particular VPN
1257 wants to access. The extranet-vpns container must be used on
1258 customer VPNs accessing extranet resources in another VPN. In the
1259 figure above, in order to provide VPN A with access to VPN B, the
1260 extranet-vpns container needs to be configured under VPN A with an
1261 entry corresponding to VPN B. There is no service configuration
1262 requirement on VPN B.
1264 Readers should note that even if there is no configuration
1265 requirement on VPN B, if VPN A lists VPN B as an extranet, all sites
1266 in VPN B will gain access to all sites in VPN A.
1268 The "site-role" leaf defines the role of the local VPN sites in the
1269 target extranet VPN service topology. Site roles are defined in
1270 Section 6.4. Based on this, the requirements described in
1271 Section 6.4 regarding the site-role leaf are also applicable here.
1273 In the example below, VPN A accesses VPN B resources through an
1274 extranet connection. A Spoke role is required for VPN A sites, as
1275 sites from VPN A must not be able to communicate with each other
1276 through the extranet VPN connection.
1278
1279
1280
1281
1282 VPNB
1283 hub-spoke
1284
1285
1286 VPNA
1287 any-to-any
1288
1289
1290 VPNB
1291 spoke-role
1292
1293
1294
1295
1296
1298 This model does not define how the extranet configuration will be
1299 achieved.
1301 Any VPN interconnection scenario that is more complex (e.g., only
1302 certain parts of sites on VPN A accessing only certain parts of sites
1303 on VPN B) needs to be achieved using a VPN attachment as defined in
1304 Section 6.5.2, and especially a VPN policy as defined in
1305 Section 6.5.2.2.
1307 6.3. Site Overview
1309 A site represents a connection of a customer office to one or more
1310 VPN services. Each site is associated with one or more location.
1312 +-------------+
1313 / \
1314 +------------------+ +-----| VPN1 |
1315 | | | \ /
1316 | New York Office |------ (site) -----+ +-------------+
1317 | | | +-------------+
1318 +------------------+ | / \
1319 +-----| VPN2 |
1320 \ /
1321 +-------------+
1323 A site has several characteristics:
1325 o Unique identifier (site-id): uniquely identifies the site within
1326 the overall network infrastructure. The identifier is a string
1327 that allows any encoding for the local administration of the VPN
1328 service.
1330 o Locations (locations): site location information that allows easy
1331 retrieval of information from the nearest available resources. A
1332 site may be composed of multiple locations. Alternatively,two or
1333 more sites can be associated with the same location, by
1334 referencing the same location ID.
1336 o Devices (devices): allows the customer to request one or more
1337 customer premises equipment entities from the SP for a particular
1338 site.
1340 o Management (management): defines the type of management for the
1341 site -- for example, co-managed, customer-managed, or provider-
1342 managed. See Section 6.10.
1344 o Site network accesses (site-network-accesses): defines the list of
1345 network accesses associated with the sites, and their properties
1346 -- especially bearer, connection, and service parameters.
1348 A site-network-access represents an IP logical connection of a site.
1349 A site may have multiple site-network-accesses.
1351 +------------------+ Site
1352 | |-----------------------------------
1353 | |****** (site-network-access#1) ******
1354 | New York Office |
1355 | |****** (site-network-access#2) ******
1356 | |-----------------------------------
1357 +------------------+
1359 Multiple site-network-accesses are used, for instance, in the case of
1360 multihoming. Some other meshing cases may also include multiple
1361 site-network-accesses.
1363 The site configuration is viewed as a global entity; we assume that
1364 it is mostly the management system's role to split the parameters
1365 between the different elements within the network. For example, in
1366 the case of the site-network-access configuration, the management
1367 system needs to split the overall parameters between the PE
1368 configuration and the CE configuration.
1370 6.3.1. Devices and Locations
1372 A site may be composed of multiple locations. All the locations will
1373 need to be configured as part of the "locations" container and list.
1374 A typical example of a multi-location site is a headquarters office
1375 in a city composed of multiple buildings. Those buildings may be
1376 located in different parts of the city and may be linked by intra-
1377 city fibers (customer metropolitan area network). In such a case,
1378 when connecting to a VPN service, the customer may ask for
1379 multihoming based on its distributed locations.
1381 New York Site
1383 +------------------+ Site
1384 | +--------------+ |-----------------------------------
1385 | | Manhattan | |****** (site-network-access#1) ******
1386 | +--------------+ |
1387 | +--------------+ |
1388 | | Brooklyn | |****** (site-network-access#2) ******
1389 | +--------------+ |
1390 | |-----------------------------------
1391 +------------------+
1393 A customer may also request some premises equipment entities (CEs)
1394 from the SP via the "devices" container. Requesting a CE implies a
1395 provider-managed or co-managed model. A particular device must be
1396 ordered to a particular already-configured location. This would help
1397 the SP send the device to the appropriate postal address. In a
1398 multi-location site, a customer may, for example, request a CE for
1399 each location on the site where multihoming must be implemented. In
1400 the figure above, one device may be requested for the Manhattan
1401 location and one other for the Brooklyn location.
1403 By using devices and locations, the user can influence the
1404 multihoming scenario he wants to implement: single CE, dual CE, etc.
1406 6.3.2. Site Network Accesses
1408 As mentioned earlier, a site may be multihomed. Each IP network
1409 access for a site is defined in the "site-network-accesses"
1410 container. The site-network-access parameter defines how the site is
1411 connected on the network and is split into three main classes of
1412 parameters:
1414 o bearer: defines requirements of the attachment (below Layer 3).
1416 o connection: defines Layer 3 protocol parameters of the attachment.
1418 o availability: defines the site's availability policy. The
1419 availability parameters are defined in Section 6.7.
1421 The site-network-access has a specific type (site-network-access-
1422 type). This document defines two types:
1424 o point-to-point: describes a point-to-point connection between the
1425 SP and the customer.
1427 o multipoint: describes a multipoint connection between the SP and
1428 the customer.
1430 The type of site-network-access may have an impact on the parameters
1431 offered to the customer, e.g., an SP may not offer encryption for
1432 multipoint accesses. It is up to the provider to decide what
1433 parameter is supported for point-to-point and/or multipoint accesses;
1434 this topic is out of scope for this document. Some containers
1435 proposed in the model may require extensions in order to work
1436 properly for multipoint accesses.
1438 6.3.2.1. Bearer
1440 The bearer container defines the requirements for the site attachment
1441 to the provider network that are below Layer 3.
1443 The bearer parameters will help determine the access media to be
1444 used. This is further described in Section 6.6.3.
1446 6.3.2.2. Connection
1448 The "ip-connection" container defines the protocol parameters of the
1449 attachment (IPv4 and IPv6). Depending on the management mode, it
1450 refers to PE-CE addressing or CE-to-customer-LAN addressing. In any
1451 case, it describes the responsibility boundary between the provider
1452 and the customer. For a customer-managed site, it refers to the PE-
1453 CE connection. For a provider-managed site, it refers to the CE-to-
1454 LAN connection.
1456 6.3.2.2.1. IP Addressing
1458 An IP subnet can be configured for either IPv4 or IPv6 Layer 3
1459 protocols. For a dual-stack connection, two subnets will be
1460 provided, one for each address family.
1462 The "address-allocation-type" determines how the address allocation
1463 needs to be done. The current model defines five ways to perform IP
1464 address allocation:
1466 o provider-dhcp: The provider will provide DHCP service for customer
1467 equipment; this is applicable to either the "IPv4" container or
1468 the "IPv6" container.
1470 o provider-dhcp-relay: The provider will provide DHCP relay service
1471 for customer equipment; this is applicable to both IPv4 and IPv6
1472 addressing. The customer needs to populate the DHCP server list
1473 to be used.
1475 o static-address: Addresses will be assigned manually; this is
1476 applicable to both IPv4 and IPv6 addressing.
1478 o slaac: This parameter enables stateless address autoconfiguration
1479 [RFC4862]. This is applicable to IPv6 only.
1481 o provider-dhcp-slaac: The provider will provide DHCP service for
1482 customer equipment, as well as stateless address
1483 autoconfiguration. This is applicable to IPv6 only.
1485 In the dynamic addressing mechanism, the SP is expected to provide at
1486 least the IP address, mask, and default gateway information.In the
1487 case of multiple site-network-access points belonging to the same
1488 VPN, address space allocated for one site-network-access should not
1489 conflict with one allocated for other site-network-accesses.
1491 6.3.2.2.2. OAM
1493 A customer may require a specific IP connectivity fault detection
1494 mechanism on the IP connection. The model supports BFD as a fault
1495 detection mechanism. This can be extended with other mechanisms via
1496 augmentation. The provider can propose some profiles to the
1497 customer, depending on the service level the customer wants to
1498 achieve. Profile names must be communicated to the customer. This
1499 communication is out of scope for this document. Some fixed values
1500 for the holdtime period may also be imposed by the customer if the
1501 provider allows the customer this function.
1503 The "oam" container can easily be augmented by other mechanisms; in
1504 particular, work done by the LIME Working Group
1505 (https://datatracker.ietf.org/wg/lime/charter/) may be reused in
1506 applicable scenarios.
1508 6.3.2.3. Inheritance of Parameters Defined at Site Level and Site
1509 Network Access Level
1511 Some parameters can be configured at both the site level and the
1512 site-network-access level, e.g., routing, services, security.
1513 Inheritance applies when parameters are defined at the site level.
1515 If a parameter is configured at both the site level and the access
1516 level, the access-level parameter MUST override the site-level
1517 parameter. Those parameters will be described later in this
1518 document.
1520 In terms of provisioning impact, it will be up to the implementation
1521 to decide on the appropriate behavior when modifying existing
1522 configurations. But the SP will need to communicate to the user
1523 about the impact of using inheritance. For example, if we consider
1524 that a site has already provisioned three site-network-accesses, what
1525 will happen if a customer changes a service parameter at the site
1526 level? An implementation of this model may update the service
1527 parameters of all already-provisioned site-network-accesses (with
1528 potential impact on live traffic), or it may take into account this
1529 new parameter only for the new sites.
1531 6.4. Site Role
1533 A VPN has a particular service topology, as described in
1534 Section 6.2.1. As a consequence, each site belonging to a VPN is
1535 assigned with a particular role in this topology. The site-role leaf
1536 defines the role of the site in a particular VPN topology.
1538 In the any-to-any VPN service topology, all sites MUST have the same
1539 role, which will be "any-to-any-role".
1541 In the Hub-and-Spoke VPN service topology or the Hub and Spoke
1542 disjoint VPN service topology, sites MUST have a Hub role or a Spoke
1543 role.
1545 6.5. Site Belonging to Multiple VPNs
1547 6.5.1. Site VPN Flavor
1549 A site may be part of one or multiple VPNs. The "site-vpn-flavor"
1550 defines the way the VPN multiplexing is done. The current version of
1551 the model supports four flavors:
1553 o site-vpn-flavor-single: The site belongs to only one VPN.
1555 o site-vpn-flavor-multi: The site belongs to multiple VPNs, and all
1556 the logical accesses of the sites belong to the same set of VPNs.
1558 o site-vpn-flavor-sub: The site belongs to multiple VPNs with
1559 multiple logical accesses. Each logical access may map to
1560 different VPNs (one or many).
1562 o site-vpn-flavor-nni: The site represents an option A NNI.
1564 6.5.1.1. Single VPN Attachment: site-vpn-flavor-single
1566 The figure below describes a single VPN attachment. The site
1567 connects to only one VPN.
1569 +--------+
1570 +------------------+ Site / \
1571 | |-----------------------------| |
1572 | |***(site-network-access#1)***| VPN1 |
1573 | New York Office | | |
1574 | |***(site-network-access#2)***| |
1575 | |-----------------------------| |
1576 +------------------+ \ /
1577 +--------+
1579 6.5.1.2. MultiVPN Attachment: site-vpn-flavor-multi
1581 The figure below describes a site connected to multiple VPNs.
1583 +---------+
1584 +---/----+ \
1585 +------------------+ Site / | \ |
1586 | |--------------------------------- | |VPN B|
1587 | |***(site-network-access#1)******* | | |
1588 | New York Office | | | | |
1589 | |***(site-network-access#2)******* \ | /
1590 | |-----------------------------| VPN A+-----|---+
1591 +------------------+ \ /
1592 +--------+
1594 In the example above, the New York office is multihomed. Both
1595 logical accesses are using the same VPN attachment rules, and both
1596 are connected to VPN A and VPN B.
1598 Reaching VPN A or VPN B from the New York office will be done via
1599 destination-based routing. Having the same destination reachable
1600 from the two VPNs may cause routing troubles. The customer
1601 administration's role in this case would be to ensure the appropriate
1602 mapping of its prefixes in each VPN.
1604 6.5.1.3. SubVPN Attachment: site-vpn-flavor-sub
1606 The figure below describes a subVPN attachment. The site connects to
1607 multiple VPNs, but each logical access is attached to a particular
1608 set of VPNs. A typical use case for a subVPN is a customer site used
1609 by multiple affiliates with private resources for each affiliate that
1610 cannot be shared (communication between the affiliates is prevented).
1611 It is similar to have separate sites, but in the case of a SubVPN,
1612 the customer can share some physical components at a single location,
1613 while maintaining strong communication isolation between the
1614 affiliates. In this example, site-network-access#1 is attached to
1615 VPN B, while site-network-access#2 is attached to VPN A.
1617 +------------------+ Site +--------+
1618 | |----------------------------------/ \
1619 | |****(site-network-access#1)******| VPN B |
1620 | New York Office | \ /
1621 | | +--------+
1622 | | +--------+
1623 | | / \
1624 | |****(site-network-access#2)******| VPN A |
1625 | | \ /
1626 | | +--------+
1627 | |-----------------------------------
1628 +------------------+
1630 A multiVPN can be implemented in addition to a subVPN; as a
1631 consequence, each site-network-access can access multiple VPNs. In
1632 the example below, site-network-access#1 is mapped to VPN B and VPN
1633 C, while site-network-access#2 is mapped to VPN A and VPN D.
1635 +-----------------+ Site +------+
1636 | |--------------------------------/ +-----+
1637 | |****(site-network-access#1)****| VPN B / \
1638 | New York Office | \ | VPN C |
1639 | | +-----\ /
1640 | | +-----+
1641 | |
1642 | | +-------+
1643 | | / +-----+
1644 | |****(site-network-access#2)****| VPN A / \
1645 | | \ | VPN D |
1646 | | +------\ /
1647 | |--------------------------------- +-----+
1648 +-----------------+
1650 Multihoming is also possible with subVPNs; in this case, site-
1651 network-accesses are grouped, and a particular group will have access
1652 to the same set of VPNs. In the example below, site-network-access#1
1653 and site-network-access#2 are part of the same group (multihomed
1654 together) and are mapped to VPN B and VPN C; in addition, site-
1655 network-access#3 and site-network-access#4 are part of the same group
1656 (multihomed together) and are mapped to VPN A and VPN D.
1658 +-----------------+ Site +------+
1659 | |---------------------------------/ +-----+
1660 | |****(site-network-access#1)*****| VPN B / \
1661 | New York Office |****(site-network-access#2)***** \ | VPN C |
1662 | | +-----\ /
1663 | | +-----+
1664 | |
1665 | | +------+
1666 | | / +-----+
1667 | |****(site-network-access#3)*****| VPN A / \
1668 | |****(site-network-access#4)***** \ | VPN D |
1669 | | +-----\ /
1670 | |---------------------------------- +-----+
1671 +-----------------+
1673 In terms of service configuration, a subVPN can be achieved by
1674 requesting that the site-network-access use the same bearer (see
1675 Section 6.6.4 for more details).
1677 6.5.1.4. NNI: site-vpn-flavor-nni
1679 A Network-to-Network Interface (NNI) scenario may be modeled using
1680 the sites container (see Section 6.15.1). Using the sites container
1681 to model an NNI is only one possible option for NNIs (see
1682 Section 6.15). This option is called "option A" by reference to the
1683 option A NNI defined in [RFC4364]. It is helpful for the SP to
1684 indicate that the requested VPN connection is not a regular site but
1685 rather is an NNI, as specific default device configuration parameters
1686 may be applied in the case of NNIs (e.g., ACLs, routing policies).
1688 SP A SP B
1689 ------------------- -------------------
1690 / \ / \
1691 | | | |
1692 | ++++++++ Inter-AS link ++++++++ |
1693 | + +_______________+ + |
1694 | + (VRF1)---(VPN1)----(VRF1) + |
1695 | + ASBR + + ASBR + |
1696 | + (VRF2)---(VPN2)----(VRF2) + |
1697 | + +_______________+ + |
1698 | ++++++++ ++++++++ |
1699 | | | |
1700 | | | |
1701 | | | |
1702 | ++++++++ Inter-AS link ++++++++ |
1703 | + +_______________+ + |
1704 | + (VRF1)---(VPN1)----(VRF1) + |
1705 | + ASBR + + ASBR + |
1706 | + (VRF2)---(VPN2)----(VRF2) + |
1707 | + +_______________+ + |
1708 | ++++++++ ++++++++ |
1709 | | | |
1710 | | | |
1711 \ / \ /
1712 ------------------- -------------------
1714 The figure above describes an option A NNI scenario that can be
1715 modeled using the sites container. In order to connect its customer
1716 VPNs (VPN1 and VPN2) in SP B, SP A may request the creation of some
1717 site-network-accesses to SP B. The site-vpn-flavor-nni will be used
1718 to inform SP B that this is an NNI and not a regular customer site.
1719 The site-vpn-flavor-nni may be multihomed and multiVPN as well.
1721 6.5.2. Attaching a Site to a VPN
1723 Due to the multiple site-vpn flavors, the attachment of a site to an
1724 IP VPN is done at the site-network-access (logical access) level
1725 through the "vpn-attachment" container. The vpn-attachment container
1726 is mandatory. The model provides two ways to attach a site to a VPN:
1728 o By referencing the target VPN directly.
1730 o By referencing a VPN policy for attachments that are more complex.
1732 A choice is implemented to allow the user to choose the flavor that
1733 provides the best fit.
1735 6.5.2.1. Referencing a VPN
1737 Referencing a vpn-id provides an easy way to attach a particular
1738 logical access to a VPN. This is the best way in the case of a
1739 single VPN attachment or subVPN with a single VPN attachment per
1740 logical access. When referencing a vpn-id, the site-role setting
1741 must be added to express the role of the site in the target VPN
1742 service topology.
1744
1745
1746
1747
1748 VPNA
1749
1750
1751 VPNB
1752
1753
1754
1755
1756 SITE1
1757
1758
1759 L1
1760
1761
1762
1763 customer-managed
1764
1765
1766
1767 layer3
1768
1769
1770
1771
1772 LA1
1773
1774
1775 provider-dhcp
1776
1777
1778 provider-dhcp
1779
1780
1781
1782 1514
1783 10000000
1784 10000000
1785
1786
1787
1788 layer3
1789
1790
1791 L1
1792
1793 VPNA
1794 spoke-role
1795
1796
1797
1798 LA2
1799
1800
1801 provider-dhcp
1802
1803
1804 provider-dhcp
1805
1806
1807
1808 1514
1809 10000000
1810 10000000
1811
1812
1813
1814 layer3
1815
1816
1817 L1
1818
1819 VPNB
1820 spoke-role
1821
1822
1823
1824
1825
1826
1827 The example of a corresponding XML snippet above describes a subVPN
1828 case where a site (SITE1) has two logical accesses (LA1 and LA2),
1829 with LA1 attached to VPNA and LA2 attached to VPNB.
1831 6.5.2.2. VPN Policy
1833 The "vpn-policy" list helps express a multiVPN scenario where a
1834 logical access belongs to multiple VPNs. Multiple VPN policies can
1835 be created to handle the subVPN case where each logical access is
1836 part of a different set of VPNs.
1838 As a site can belong to multiple VPNs, the vpn-policy list may be
1839 composed of multiple entries. A filter can be applied to specify
1840 that only some LANs of the site should be part of a particular VPN.
1841 Each time a site (or LAN) is attached to a VPN, the user must
1842 precisely describe its role (site-role) within the target VPN service
1843 topology.
1845 +--------------------------------------------------------------+
1846 | Site1 ------ PE7 |
1847 +-------------------------+ (VPN2) |
1848 | |
1849 +-------------------------+ |
1850 | Site2 ------ PE3 PE4 ------ Site3 |
1851 +----------------------------------+ |
1852 | |
1853 +------------------------------------------------------------+ |
1854 | Site4 ------ PE5 | PE6 ------ Site5 | |
1855 | | |
1856 | (VPN3) | |
1857 +------------------------------------------------------------+ |
1858 | |
1859 +---------------------------+
1861 In the example above, Site5 is part of two VPNs: VPN3 and VPN2. It
1862 will play a Hub role in VPN2 and an any-to-any role in VPN3. We can
1863 express such a multiVPN scenario with the following XML snippet:
1865
1866
1867
1868
1869 VPN2
1870
1871
1872 VPN3
1873
1875
1876
1877
1878 Site5
1879
1880
1881 D1
1882
1883
1884
1885 provider-managed
1886
1887
1888
1889 layer3
1890
1891
1892
1893
1894 POLICY1
1895
1896 ENTRY1
1897
1898 VPN2
1899 hub-role
1900
1901
1902
1903 ENTRY2
1904
1905 VPN3
1906 any-to-any-role
1907
1908
1909
1910
1911
1912
1913 LA1
1914 D1
1915
1916
1917 provider-dhcp
1918
1919
1920 provider-dhcp
1921
1922
1923
1924 1514
1925 10000000
1926 10000000
1927
1928
1929
1930 layer3
1931
1932
1933
1934 POLICY1
1935
1936
1937
1938
1939
1940
1942 Now, if a more-granular VPN attachment is necessary, filtering can be
1943 used. For example, if LAN1 from Site5 must be attached to VPN2 as a
1944 Hub and LAN2 must be attached to VPN3, the following configuration of
1945 corresponding XML snippet can be used:
1947
1948
1949
1950
1951 VPN2
1952
1953
1954 VPN3
1955
1956
1957
1958
1959 Site5
1960
1961
1962 POLICY1
1963
1964 ENTRY1
1965
1966
1967 lan
1968 LAN1
1970
1971
1972
1973 VPN2
1974 hub-role
1975
1976
1977
1978 ENTRY2
1979
1980
1981 lan
1982 LAN2
1983
1984
1985
1986 VPN3
1987 any-to-any-role
1988
1989
1990
1991
1992
1993
1994 LA1
1995
1996 POLICY1
1997
1998
1999
2000
2001
2002
2004 6.6. Deciding Where to Connect the Site
2006 The management system will have to determine where to connect each
2007 site-network-access of a particular site to the provider network
2008 (e.g., PE, aggregation switch).
2010 The current model defines parameters and constraints that can
2011 influence the meshing of the site-network-access.
2013 The management system MUST honor all customer constraints, or if a
2014 constraint is too strict and cannot be fulfilled, the management
2015 system MUST NOT provision the site and MUST provide information to
2016 the user about which constraints that could not be fulfilled.How the
2017 information is provided is out of scope for this document. Whether
2018 or not to relax the constraint would then be left up to the user.
2020 Parameters such as site location (see Section 6.6.2) and access type
2021 are just hints (see Section 6.6.3) for the management system for
2022 service placement.
2024 In addition to parameters and constraints, the management system's
2025 decision MAY be based on any other internal constraints that are left
2026 up to the SP: least load, distance, etc.
2028 6.6.1. Constraint: Device
2030 In the case of provider management or co-management, one or more
2031 devices have been ordered by the customer to a particular already-
2032 configured location. The customer may force a particular site-
2033 network-access to be connected on a particular device that he
2034 ordered.
2036 New York Site
2038 +------------------+ Site
2039 | +--------------+ |-----------------------------------
2040 | | Manhattan | |
2041 | | CE1********* (site-network-access#1) ******
2042 | +--------------+ |
2043 | +--------------+ |
2044 | | Brooklyn CE2********* (site-network-access#2) ******
2045 | +--------------+ |
2046 | |-----------------------------------
2047 +------------------+
2049 In the figure above, site-network-access#1 is associated with CE1 in
2050 the service request. The SP must ensure the provisioning of this
2051 connection.
2053 6.6.2. Constraint/Parameter: Site Location
2055 The location information provided in this model MAY be used by a
2056 management system to determine the target PE to mesh the site (SP
2057 side). A particular location must be associated with each site
2058 network access when configuring it. The SP MUST honor the
2059 termination of the access on the location associated with the site
2060 network access (customer side). The "country-code" in the site
2061 location SHOULD be expressed as an ISO ALPHA-2 code.
2063 The site-network-access location is determined by the "location-
2064 flavor". In the case of a provider-managed or co-managed site, the
2065 user is expected to configure a "device-reference" (device case) that
2066 will bind the site-network-access to a particular device that the
2067 customer ordered. As each device is already associated with a
2068 particular location, in such a case the location information is
2069 retrieved from the device location. In the case of a customer-
2070 managed site, the user is expected to configure a "location-
2071 reference" (location case); this provides a reference to an existing
2072 configured location and will help with placement.
2074 POP#1 (New York)
2075 +---------+
2076 | PE1 |
2077 Site #1 ---... | PE2 |
2078 (Atlantic City) | PE3 |
2079 +---------+
2081 POP#2 (Washington)
2082 +---------+
2083 | PE4 |
2084 | PE5 |
2085 | PE6 |
2086 +---------+
2088 POP#3 (Philadelphia)
2089 +---------+
2090 | PE7 |
2091 Site #2 CE#1---... | PE8 |
2092 (Reston) | PE9 |
2093 +---------+
2095 In the example above, Site #1 is a customer-managed site with a
2096 location L1, while Site #2 is a provider-managed site for which a CE
2097 (CE#1) was ordered. Site #2 is configured with L2 as its location.
2098 When configuring a site-network-access for Site #1, the user will
2099 need to reference location L1 so that the management system will know
2100 that the access will need to terminate on this location. Then, for
2101 distance reasons, this management system may mesh Site #1 on a PE in
2102 the Philadelphia POP. It may also take into account resources
2103 available on PEs to determine the exact target PE (e.g., least
2104 loaded). For Site #2, the user is expected to configure the site-
2105 network-access with a device-reference to CE#1 so that the management
2106 system will know that the access must terminate on the location of
2107 CE#1 and must be connected to CE#1. For placement of the SP side of
2108 the access connection, in the case of the nearest PE used, it may
2109 mesh Site #2 on the Washington POP.
2111 6.6.3. Constraint/Parameter: Access Type
2113 The management system needs to elect the access media to connect the
2114 site to the customer (for example, xDSL, leased line, Ethernet
2115 backhaul). The customer may provide some parameters/constraints that
2116 will provide hints to the management system.
2118 The bearer container information SHOULD be the first piece of
2119 information considered when making this decision:
2121 o The "requested-type" parameter provides information about the
2122 media type that the customer would like to use. If the "strict"
2123 leaf is equal to "true", this MUST be considered a strict
2124 constraint so that the management system cannot connect the site
2125 with another media type. If the "strict" leaf is equal to "false"
2126 (default) and if the requested media type cannot be fulfilled, the
2127 management system can select another media type. The supported
2128 media types SHOULD be communicated by the SP to the customer via a
2129 mechanism that is out of scope for this document.
2131 o The "always-on" leaf defines a strict constraint: if set to true,
2132 the management system MUST elect a media type that is "always-on"
2133 (e.g., this means no dial access type).
2135 o The "bearer-reference" parameter is used in cases where the
2136 customer has already ordered a network connection to the SP apart
2137 from the IP VPN site and wants to reuse this connection. The
2138 string used is an internal reference from the SP and describes the
2139 already-available connection. This is also a strict requirement
2140 that cannot be relaxed. How the reference is given to the
2141 customer is out of scope for this document, but as a pure example,
2142 when the customer ordered the bearer (through a process that is
2143 out of scope for this model), the SP may have provided the bearer
2144 reference that can be used for provisioning services on top.
2146 Any other internal parameters from the SP can also be used. The
2147 management system MAY use other parameters, such as the requested
2148 "svc-input-bandwidth" and "svc-output-bandwidth", to help decide
2149 which access type to use.
2151 6.6.4. Constraint: Access Diversity
2153 Each site-network-access may have one or more constraints that would
2154 drive the placement of the access. By default, the model assumes
2155 that there are no constraints, but allocation of a unique bearer per
2156 site-network-access is expected.
2158 In order to help with the different placement scenarios, a site-
2159 network-access may be tagged using one or multiple group identifiers.
2160 The group identifier is a string, so it can accommodate both explicit
2161 naming of a group of sites (e.g., "multihomed-set1" or "subVPN") and
2162 the use of a numbered identifier (e.g., 12345678). The meaning of
2163 each group-id is local to each customer administrator, and the
2164 management system MUST ensure that different customers can use the
2165 same group-ids. One or more group-ids can also be defined at the
2166 site level; as a consequence, all site-network-accesses under the
2167 site MUST inherit the group-ids of the site they belong to. When, in
2168 addition to the site group-ids some group-ids are defined at the
2169 site-network-access level, the management system MUST consider the
2170 union of all groups (site level and site network access level) for
2171 this particular site-network-access.
2173 For an already-configured site-network-access, each constraint MUST
2174 be expressed against a targeted set of site-network-accesses. This
2175 site-network-access MUST never be taken into account in the targeted
2176 set -- for example, "My site-network-access S must not be connected
2177 on the same POP as the site-network-accesses that are part of Group
2178 10." The set of site-network-accesses against which the constraint
2179 is evaluated can be expressed as a list of groups, "all-other-
2180 accesses", or "all-other-groups". The all-other-accesses option
2181 means that the current site-network-access constraint MUST be
2182 evaluated against all the other site-network-accesses belonging to
2183 the current site. The all-other-groups option means that the
2184 constraint MUST be evaluated against all groups that the current
2185 site-network-access does not belong to.
2187 The current model defines multiple constraint-types:
2189 o pe-diverse: The current site-network-access MUST NOT be connected
2190 to the same PE as the targeted site-network-accesses.
2192 o pop-diverse: The current site-network-access MUST NOT be connected
2193 to the same POP as the targeted site-network-accesses.
2195 o linecard-diverse: The current site-network-access MUST NOT be
2196 connected to the same linecard as the targeted site-network-
2197 accesses.
2199 o bearer-diverse: The current site-network-access MUST NOT use
2200 common bearer components compared to bearers used by the targeted
2201 site-network-accesses. "bearer-diverse" provides some level of
2202 diversity at the access level. As an example, two bearer-diverse
2203 site-network-accesses must not use the same DSLAM, BAS, or Layer 2
2204 switch.
2206 o same-pe: The current site-network-access MUST be connected to the
2207 same PE as the targeted site-network-accesses.
2209 o same-bearer: The current site-network-access MUST be connected
2210 using the same bearer as the targeted site-network-accesses.
2212 These constraint-types can be extended through augmentation.
2214 Each constraint is expressed as "The site-network-access S must be
2215 (e.g., pe-diverse, pop-diverse) from these
2216 site-network-accesses."
2218 The group-id used to target some site-network-accesses may be the
2219 same as the one used by the current site-network-access. This eases
2220 the configuration of scenarios where a group of site-network-access
2221 points has a constraint between the access points in the group. As
2222 an example, if we want a set of sites (Site#1 to Site#5) to be
2223 connected on different PEs, we can tag them with the same group-id
2224 and express a pe-diverse constraint for this group-id with the
2225 following XML snippet:
2227
2228
2229
2230
2231 VPNA
2232
2233
2234
2235
2236 SITE1
2237
2238
2239 L1
2240
2241
2242
2243 customer-managed
2244
2245
2246
2247 1
2248
2249
2250 provider-dhcp
2251
2252
2253 provider-dhcp
2255
2256
2257
2258 1514
2259 10000000
2260 10000000
2261
2262
2263
2264 layer3
2265
2266
2267 L1
2268
2269
2270
2271 10
2272
2273
2274
2275
2276 pe-diverse
2277
2278
2279 10
2280
2281
2282
2283
2284
2285
2286 VPNA
2287 spoke-role
2288
2289
2290
2291
2292
2293 SITE2
2294
2295
2296 L1
2297
2298
2299
2300 customer-managed
2301
2302
2303
2304 layer3
2305
2306
2307
2308
2309 1
2310
2311
2312 provider-dhcp
2313
2314
2315 provider-dhcp
2316
2317
2318
2319 1514
2320 10000000
2321 10000000
2322
2323
2324
2325 layer3
2326
2327
2328 L1
2329
2330
2331
2332 10
2333
2334
2335
2336
2337 pe-diverse
2338
2339
2340 10
2341
2342
2343
2344
2345
2346
2347 VPNA
2348 spoke-role
2349
2350
2352
2353
2354 ...
2355
2356 SITE5
2357
2358
2359 L1
2360
2361
2362
2363 customer-managed
2364
2365
2366
2367 layer3
2368
2369
2370
2371
2372 1
2373
2374
2375 provider-dhcp
2376
2377
2378 provider-dhcp
2379
2380
2381
2382 1514
2383 10000000
2384 10000000
2385
2386
2387
2388 layer3
2389
2390
2391 L1
2392
2393
2394
2395 10
2396
2397
2398
2399
2400 pe-diverse
2401
2402
2403 10
2404
2405
2406
2407
2408
2409
2410 VPNA
2411 spoke-role
2412
2413
2414
2415
2416
2417
2419 The group-id used to target some site-network-accesses may also be
2420 different than the one used by the current site-network-access. This
2421 can be used to express that a group of sites has some constraints
2422 against another group of sites, but there is no constraint within the
2423 group. For example, we consider a set of six sites and two groups;
2424 we want to ensure that a site in the first group must be pop-diverse
2425 from a site in the second group. The example of a corresponding XML
2426 snippet is described as follows:
2428
2429
2430
2431
2432 VPNA
2433
2434
2435
2436
2437 SITE1
2438
2439
2440 1
2441
2442
2443
2444 10
2445
2446
2447
2448
2449 pop-diverse
2450
2451
2452 20
2453
2454
2455
2456
2457
2458
2459 VPNA
2460 spoke-role
2461
2462
2463
2464
2465
2466 SITE2
2467
2468
2469 1
2470
2471
2472
2473 10
2474
2475
2476
2477
2478 pop-diverse
2479
2480
2481 20
2482
2483
2484
2485
2486
2487
2488 VPNA
2489 spoke-role
2490
2491
2492
2493
2494 ...
2496
2497 SITE5
2498
2499
2500 1
2501
2502
2503
2504 20
2505
2506
2507
2508
2509 pop-diverse
2510
2511
2512 10
2513
2514
2515
2516
2517
2518
2519 VPNA
2520 spoke-role
2521
2522
2523
2524
2525
2526 SITE6
2527
2528
2529 L1
2530
2531
2532
2533 customer-managed
2534
2535
2536
2537 layer3
2538
2539
2540
2541
2542 1
2543
2544
2545 provider-dhcp
2546
2547
2548 provider-dhcp
2549
2550
2551
2552 1514
2553 10000000
2554 10000000
2555
2556
2557
2558 layer3
2559
2560
2561 L1
2562
2563
2564
2565 20
2566
2567
2568
2569
2570 pop-diverse
2571
2572
2573 10
2574
2575
2576
2577
2578
2579
2580 VPNA
2581 spoke-role
2582
2583
2584
2585
2586
2587
2588 6.6.5. Infeasible Access Placement
2590 Some infeasible access placement scenarios could be created via the
2591 proposed configuration framework. Such infeasible access placement
2592 scenarios could result from constraints that are too restrictive,
2593 leading to infeasible access placement in the network or conflicting
2594 constraints that would also lead to infeasible access placement. An
2595 example of conflicting rules would be to request that site-network-
2596 access#1 be pe-diverse from site-network-access#2 and to request at
2597 the same time that site-network-access#2 be on the same PE as site-
2598 network-access#1. When the management system cannot determine the
2599 placement of a site-network-access, it MUST return an error message
2600 indicating that placement was not possible.
2602 6.6.6. Examples of Access Placement
2604 6.6.6.1. Multihoming
2606 The customer wants to create a multihomed site. The site will be
2607 composed of two site-network-accesses; for resiliency purposes, the
2608 customer wants the two site-network-accesses to be meshed on
2609 different POPs.
2611 POP#1
2612 +-------+ +---------+
2613 | | | PE1 |
2614 | |---site-network-access#1----| PE2 |
2615 | | | PE3 |
2616 | | +---------+
2617 | Site#1|
2618 | | POP#2
2619 | | +---------+
2620 | | | PE4 |
2621 | |---site-network-access#2----| PE5 |
2622 | | | PE6 |
2623 | | +---------+
2624 +-------+
2626 This scenario can be expressed with the following XML snippet:
2628
2629
2630
2631
2632 VPNA
2633
2634
2635
2636
2637 SITE1
2638
2639
2640 L1
2641
2642
2643
2644 customer-managed
2645
2646
2647
2648 layer3
2649
2650
2651
2652
2653 1
2654
2655
2656 provider-dhcp
2657
2658
2659 provider-dhcp
2660
2661
2662
2663 1514
2664 10000000
2665 10000000
2666
2667
2668
2669 layer3
2670
2671
2672 L1
2673
2674
2675
2676 10
2677
2678
2679
2680
2681 pop-diverse
2682
2683
2684 20
2685
2686
2687
2688
2689
2690
2691 VPNA
2692 spoke-role
2693
2694
2695
2696 2
2697
2698
2699 provider-dhcp
2700
2701
2702 provider-dhcp
2703
2704
2705
2706 1514
2707 10000000
2708 10000000
2709
2710
2711
2712 layer3
2713
2714
2715 L1
2716
2717
2718
2719 20
2720
2721
2722
2723
2724 pop-diverse
2725
2726
2727 10
2728
2729
2730
2732
2733
2734
2735 VPNA
2736 spoke-role
2737
2738
2739
2740
2741
2742
2744 But it can also be expressed with the following XML snippet:
2746
2747
2748
2749
2750 VPNA
2751
2752
2753
2754
2755 SITE1
2756
2757
2758 1
2759
2760
2761
2762 pop-diverse
2763
2764
2765
2766
2767
2768
2769
2770 VPNA
2771 spoke-role
2772
2773
2774
2775 2
2776
2777
2778
2779 pop-diverse
2780
2781
2782
2783
2784
2785
2786
2787 VPNA
2788 spoke-role
2789
2790
2791
2792
2793
2794
2796 6.6.6.2. Site Offload
2798 The customer has six branch offices in a particular region, and he
2799 wants to prevent having all branch offices connected on the same PE.
2801 He wants to express that three branch offices cannot be connected on
2802 the same linecard. Also, the other branch offices must be connected
2803 on a different POP. Those other branch offices cannot also be
2804 connected on the same linecard.
2806 POP#1
2807 +---------+
2808 | PE1 |
2809 Office#1 ---... | PE2 |
2810 Office#2 ---... | PE3 |
2811 Office#3 ---... | PE4 |
2812 +---------+
2814 POP#2
2815 +---------+
2816 Office#4 ---... | PE5 |
2817 Office#5 ---... | PE6 |
2818 Office#6 ---... | PE7 |
2819 +---------+
2821 This scenario can be expressed as follows:
2823 o We need to create two groups of sites: Group#10, which is composed
2824 of Office#1, Office#2, and Office#3; and Group#20, which is
2825 composed of Office#4, Office#5, and Office#6.
2827 o Sites within Group#10 must be pop-diverse from sites within
2828 Group#20, and vice versa.
2830 o Sites within Group#10 must be linecard-diverse from other sites in
2831 Group#10 (same for Group#20).
2833
2834
2835
2836
2837 VPNA
2838
2839
2840
2841
2842 Office1
2843
2844
2845 L1
2846
2847
2848
2849 customer-managed
2850
2851
2852
2853 layer3
2854
2855
2856
2857
2858 1
2859
2860
2861 provider-dhcp
2862
2863
2864 provider-dhcp
2865
2866
2867
2868 1514
2869 10000000
2870 10000000
2872
2873
2874
2875 layer3
2876
2877
2878 L1
2879
2880
2881
2882 10
2883
2884
2885
2886
2887 pop-diverse
2888
2889
2890 20
2891
2892
2893
2894
2895 linecard-diverse
2896
2897
2898 10
2899
2900
2901
2902
2903
2904
2905 VPNA
2906 spoke-role
2907
2908
2909
2910
2911
2912 Office2
2913
2914
2915 L1
2916
2917
2918
2919 customer-managed
2921
2922
2923
2924 layer3
2925
2926
2927
2928
2929 1
2930
2931
2932 provider-dhcp
2933
2934
2935 provider-dhcp
2936
2937
2938
2939 1514
2940 10000000
2941 10000000
2942
2943
2944
2945 layer3
2946
2947
2948 L1
2949
2950
2951
2952 10
2953
2954
2955
2956
2957 pop-diverse
2958
2959
2960 20
2961
2962
2963
2964
2965 linecard-diverse
2966
2967
2968 10
2970
2971
2972
2973
2974
2975
2976 VPNA
2977 spoke-role
2978
2979
2980
2981
2982
2983 Office3
2984
2985
2986 L1
2987
2988
2989
2990 customer-managed
2991
2992
2993
2994 layer3
2995
2996
2997
2998
2999 1
3000
3001
3002 provider-dhcp
3003
3004
3005 provider-dhcp
3006
3007
3008
3009 1514
3010 10000000
3011 10000000
3012
3013
3014
3015 layer3
3016
3017
3018 L1
3019
3020
3021
3022 10
3023
3024
3025
3026
3027 pop-diverse
3028
3029
3030 20
3031
3032
3033
3034
3035 linecard-diverse
3036
3037
3038 10
3039
3040
3041
3042
3043
3044
3045 VPNA
3046 spoke-role
3047
3048
3049
3050
3051
3052 Office4
3053
3054
3055 L1
3056
3057
3058
3059 customer-managed
3060
3061
3062
3063 layer3
3064
3065
3066
3067
3068 1
3069
3070
3071 provider-dhcp
3072
3073
3074 provider-dhcp
3075
3076
3077
3078 1514
3079 10000000
3080 10000000
3081
3082
3083
3084 layer3
3085
3086
3087 L1
3088
3089
3090
3091 20
3092
3093
3094
3095
3096 pop-diverse
3097
3098
3099 10
3100
3101
3102
3103
3104 linecard-diverse
3105
3106
3107 20
3108
3109
3110
3111
3112
3113
3114 VPNA
3115 spoke-role
3116
3117
3118
3119
3120
3121 Office5
3122
3123
3124 L1
3125
3126
3127
3128 customer-managed
3129
3130
3131
3132 layer3
3133
3134
3135
3136
3137 1
3138
3139
3140 provider-dhcp
3141
3142
3143 provider-dhcp
3144
3145
3146
3147 1514
3148 10000000
3149 10000000
3150
3151
3152
3153 layer3
3154
3155
3156 L1
3157
3158
3159
3160 20
3161
3163
3164
3165
3166 pop-diverse
3167
3168
3169 10
3170
3171
3172
3173
3174 linecard-diverse
3175
3176
3177 20
3178
3179
3180
3181
3182
3183
3184 VPNA
3185 spoke-role
3186
3187
3188
3189
3190
3191 Office6
3192
3193
3194 L1
3195
3196
3197
3198 customer-managed
3199
3200
3201
3202 layer3
3203
3204
3205
3206
3207 1
3208
3209
3210 provider-dhcp
3212
3213
3214 provider-dhcp
3215
3216
3217
3218 1514
3219 10000000
3220 10000000
3221
3222
3223
3224 layer3
3225
3226
3227 L1
3228
3229
3230
3231 20
3232
3233
3234
3235
3236 pop-diverse
3237
3238
3239 10
3240
3241
3242
3243
3244 linecard-diverse
3245
3246
3247 20
3248
3249
3250
3251
3252
3253
3254 VPNA
3255 spoke-role
3256
3257
3258
3259
3261
3262
3264 6.6.6.3. Parallel Links
3266 To increase its site bandwidth at lower cost, a customer wants to
3267 order two parallel site-network-accesses that will be connected to
3268 the same PE.
3270 *******site-network-access#1**********
3271 Site 1 *******site-network-access#2********** PE1
3273 This scenario can be expressed with the following XML snippet:
3275
3276
3277
3278
3279 VPNB
3280
3281
3282
3283
3284 SITE1
3285
3286
3287 1
3288
3289
3290
3291 PE-linkgrp-1
3292
3293
3294
3295
3296 same-pe
3297
3298
3299 PE-linkgrp-1
3300
3301
3302
3303
3304
3305
3306 VPNB
3307 spoke-role
3308
3309
3310
3311 2
3312
3313
3314
3315 PE-linkgrp-1
3316
3317
3318
3319
3320 same-pe
3321
3322
3323 PE-linkgrp-1
3324
3325
3326
3327
3328
3329
3330 VPNB
3331 spoke-role
3332
3333
3334
3335
3336
3337
3339 6.6.6.4. SubVPN with Multihoming
3341 A customer has a site that is dual-homed. The dual-homing must be
3342 done on two different PEs. The customer also wants to implement two
3343 subVPNs on those multihomed accesses.
3345 +-----------------+ Site +------+
3346 | |---------------------------------/ +-----+
3347 | |****(site-network-access#1)*****| VPN B / \
3348 | New York Office |****(site-network-access#2)************| VPN C |
3349 | | +-----\ /
3350 | | +-----+
3351 | |
3352 | | +------+
3353 | | / +-----+
3354 | |****(site-network-access#3)*****| VPN B / \
3355 | |****(site-network-access#4)************| VPN C |
3356 | | +-----\ /
3357 | |----------------------------------- +-----+
3358 +-----------------+
3360 This scenario can be expressed as follows:
3362 o The site will have four site network accesses (two subVPNs coupled
3363 via dual-homing).
3365 o Site-network-access#1 and site-network-access#3 will correspond to
3366 the multihoming of subVPN B. A PE-diverse constraint is required
3367 between them.
3369 o Site-network-access#2 and site-network-access#4 will correspond to
3370 the multihoming of subVPN C. A PE-diverse constraint is required
3371 between them.
3373 o To ensure proper usage of the same bearer for the subVPN, site-
3374 network-access#1 and site-network-access#2 must share the same
3375 bearer as site-network-access#3 and site-network-access#4.
3377
3378
3379
3380
3381 VPNB
3382
3383
3384 VPNC
3385
3386
3387
3388
3389 SITE1
3390
3391
3392 L1
3393
3394
3395
3396 customer-managed
3397
3398
3399
3400 layer3
3401
3402
3403
3404
3405 1
3406
3407
3408 provider-dhcp
3409
3410
3411 provider-dhcp
3412
3413
3414
3415 1514
3416 10000000
3417 10000000
3418
3419
3420
3421 layer3
3422
3423
3424 L1
3425
3426
3427
3428 dualhomed-1
3429
3430
3431
3432
3433 pe-diverse
3434
3435
3436 dualhomed-2
3437
3438
3439
3440
3441 same-bearer
3442
3443
3444 dualhomed-1
3445
3446
3447
3448
3449
3450
3451 VPNB
3452 spoke-role
3453
3454
3455
3456 2
3457
3458
3459
3460 dualhomed-1
3461
3462
3463
3464
3465 pe-diverse
3466
3467
3468 dualhomed-2
3469
3470
3471
3472
3473 same-bearer
3474
3475
3476 dualhomed-1
3477
3478
3479
3480
3481
3482
3483 VPNC
3484 spoke-role
3485
3486
3487
3488 3
3489
3490
3491 provider-dhcp
3492
3493
3494 provider-dhcp
3495
3496
3497
3498 1514
3499 10000000
3500 10000000
3501
3502
3503
3504 layer3
3505
3506
3507 L1
3508
3509
3510
3511 dualhomed-2
3512
3513
3514
3515
3516 pe-diverse
3517
3518
3519 dualhomed-1
3520
3521
3522
3523
3524 same-bearer
3525
3526
3527 dualhomed-2
3528
3529
3530
3531
3532
3533
3534 VPNB
3535 spoke-role
3537
3538
3539
3540 4
3541
3542
3543 provider-dhcp
3544
3545
3546 provider-dhcp
3547
3548
3549
3550 1514
3551 10000000
3552 10000000
3553
3554
3555
3556 layer3
3557
3558
3559 L1
3560
3561
3562
3563 dualhomed-2
3564
3565
3566
3567
3568 pe-diverse
3569
3570
3571 dualhomed-1
3572
3573
3574
3575
3576 same-bearer
3577
3578
3579 dualhomed-2
3580
3581
3582
3583
3584
3585
3586 VPNC
3587 spoke-role
3588
3589
3590
3591
3592
3593
3595 6.6.7. Route Distinguisher and VRF Allocation
3597 The route distinguisher (RD) is a critical parameter of PE-based
3598 L3VPNs as described in [RFC4364] that provides the ability to
3599 distinguish common addressing plans in different VPNs. As for route
3600 targets (RTs), a management system is expected to allocate a VRF on
3601 the target PE and an RD for this VRF.
3603 If a VRF already exists on the target PE and the VRF fulfills the
3604 connectivity constraints for the site, there is no need to recreate
3605 another VRF, and the site MAY be meshed within this existing VRF.
3606 How the management system checks that an existing VRF fulfills the
3607 connectivity constraints for a site is out of scope for this
3608 document.
3610 If no such VRF exists on the target PE, the management system has to
3611 initiate the creation of a new VRF on the target PE and has to
3612 allocate a new RD for this new VRF.
3614 The management system MAY apply a per-VPN or per-VRF allocation
3615 policy for the RD, depending on the SP's policy. In a per-VPN
3616 allocation policy, all VRFs (dispatched on multiple PEs) within a VPN
3617 will share the same RD value. In a per-VRF model, all VRFs should
3618 always have a unique RD value. Some other allocation policies are
3619 also possible, and this document does not restrict the allocation
3620 policies to be used.
3622 The allocation of RDs MAY be done in the same way as RTs. The
3623 examples provided in Section 6.2.1.1 could be reused in this
3624 scenario.
3626 Note that an SP MAY configure a target PE for an automated allocation
3627 of RDs. In this case, there will be no need for any backend system
3628 to allocate an RD value.
3630 6.7. Site Network Access Availability
3632 A site may be multihomed, meaning that it has multiple site-network-
3633 access points. Placement constraints defined in previous sections
3634 will help ensure physical diversity.
3636 When the site-network-accesses are placed on the network, a customer
3637 may want to use a particular routing policy on those accesses.
3639 The "site-network-access/availability" container defines parameters
3640 for site redundancy. The "access-priority" leaf defines a preference
3641 for a particular access. This preference is used to model load-
3642 balancing or primary/backup scenarios. The higher the access-
3643 priority value, the higher the preference will be.
3645 The figure below describes how the access-priority attribute can be
3646 used.
3648 Hub#1 LAN (Primary/backup) Hub#2 LAN (Load-sharing)
3649 | |
3650 | access-priority 1 access-priority 1 |
3651 |--- CE1 ------- PE1 PE3 --------- CE3 --- |
3652 | |
3653 | |
3654 |--- CE2 ------- PE2 PE4 --------- CE4 --- |
3655 | access-priority 2 access-priority 1 |
3657 PE5
3658 |
3659 |
3660 |
3661 CE5
3662 |
3663 Spoke#1 site (Single-homed)
3665 In the figure above, Hub#2 requires load-sharing, so all the site-
3666 network-accesses must use the same access-priority value. On the
3667 other hand, as Hub#1 requires a primary site-network-access and a
3668 backup site-network-access, a higher access-priority setting will be
3669 configured on the primary site-network-access.
3671 Scenarios that are more complex can be modeled. Let's consider a Hub
3672 site with five accesses to the network (A1,A2,A3,A4,A5). The
3673 customer wants to load-share its traffic on A1,A2 in the nominal
3674 situation. If A1 and A2 fail, the customer wants to load-share its
3675 traffic on A3 and A4; finally, if A1 to A4 are down, he wants to use
3676 A5. We can model this easily by configuring the following access-
3677 priority values: A1=100, A2=100, A3=50, A4=50, A5=10.
3679 The access-priority scenario has some limitations. An access-
3680 priority scenario like the previous one with five accesses but with
3681 the constraint of having traffic load-shared between A3 and A4 in the
3682 case where A1 OR A2 is down is not achievable. But the authors
3683 believe that using the access-priority attribute will cover most of
3684 the deployment use cases and that the model can still be extended via
3685 augmentation to support additional use cases.
3687 6.8. Traffic Protection
3689 The service model supports the ability to protect the traffic for a
3690 site. Such protection provides a better level of availability in
3691 multihoming scenarios by, for example, using local-repair techniques
3692 in case of failures. The associated level of service guarantee would
3693 be based on an agreement between the customer and the SP and is out
3694 of scope for this document.
3696 Site#1 Site#2
3697 CE1 ----- PE1 -- P1 P3 -- PE3 ---- CE3
3698 | | |
3699 | | |
3700 CE2 ----- PE2 -- P2 P4 -- PE4 ---- CE4
3701 /
3702 /
3703 CE5 ----+
3704 Site#3
3706 In the figure above, we consider an IP VPN service with three sites,
3707 including two dual-homed sites (Site#1 and Site#2). For dual-homed
3708 sites, we consider PE1-CE1 and PE3-CE3 as primary and PE2-CE2,PE4-CE4
3709 as backup for the example (even if protection also applies to load-
3710 sharing scenarios).
3712 In order to protect Site#2 against a failure, a user may set the
3713 "traffic-protection/enabled" leaf to true for Site#2. How the
3714 traffic protection will be implemented is out of scope for this
3715 document. However, in such a case, we could consider traffic coming
3716 from a remote site (Site#1 or Site#3), where the primary path would
3717 use PE3 as the egress PE. PE3 may have preprogrammed a backup
3718 forwarding entry pointing to the backup path (through PE4-CE4) for
3719 all prefixes going through the PE3-CE3 link. How the backup path is
3720 computed is out of scope for this document. When the PE3-CE3 link
3721 fails, traffic is still received by PE3, but PE3 automatically
3722 switches traffic to the backup entry; the path will therefore be
3723 PE1-P1-(...)-P3-PE3-PE4-CE4 until the remote PEs reconverge and use
3724 PE4 as the egress PE.
3726 6.9. Security
3728 The "security" container defines customer-specific security
3729 parameters for the site. The security options supported in the model
3730 are limited but may be extended via augmentation.
3732 6.9.1. Authentication
3734 The current model does not support any authentication parameters for
3735 the site connection, but such parameters may be added in the
3736 "authentication" container through augmentation.
3738 6.9.2. Encryption
3740 Traffic encryption can be requested on the connection. It may be
3741 performed at Layer 2 or Layer 3 by selecting the appropriate
3742 enumeration in the "layer" leaf. For example, an SP may use IPsec
3743 when a customer requests Layer 3 encryption. The encryption profile
3744 can be SP defined or customer specific.
3746 When an SP profile is used and a key (e.g., a pre-shared key) is
3747 allocated by the provider to be used by a customer, the SP should
3748 provide a way to communicate the key in a secured way to the
3749 customer.
3751 When a customer profile is used, the model supports only a pre-shared
3752 key for authentication, with the pre-shared key provided through the
3753 NETCONF or RESTCONF request. A secure channel must be used to ensure
3754 that the pre-shared key cannot be intercepted.
3756 For security reasons, it may be necessary for the customer to change
3757 the pre-shared key on a regular basis. To perform a key change, the
3758 user can ask the SP to change the pre-shared key by submitting a new
3759 pre-shared key for the site configuration (as shown below with a
3760 corresponding XML snippet). This mechanism might not be hitless.
3762
3763
3764
3765
3766 VPNA
3767
3768
3769
3770
3771 SITE1
3772
3773
3774 1
3775
3776
3777
3778 MY_NEW_KEY
3779
3780
3781
3782
3783
3784
3785
3786
3788 A hitless key change mechanism may be added through augmentation.
3790 Other key-management methodologies (e.g., PKI) may be added through
3791 augmentation.
3793 6.10. Management
3795 The model defines three types of common management options:
3797 o provider-managed: The CE router is managed only by the provider.
3798 In this model, the responsibility boundary between the SP and the
3799 customer is between the CE and the customer network.
3801 o customer-managed: The CE router is managed only by the customer.
3802 In this model, the responsibility boundary between the SP and the
3803 customer is between the PE and the CE.
3805 o co-managed: The CE router is primarily managed by the provider; in
3806 addition, the SP allows customers to access the CE for
3807 configuration/monitoring purposes. In the co-managed mode, the
3808 responsibility boundary is the same as the responsibility boundary
3809 for the provider-managed model.
3811 Based on the management model, different security options MAY be
3812 derived.
3814 In the co-managed case, the model defines options for the management
3815 address family (IPv4 or IPv6) and the associated management address.
3817 6.11. Routing Protocols
3819 "routing-protocol" defines which routing protocol must be activated
3820 between the provider and the customer router. The current model
3821 supports the following settings: bgp, rip, ospf, static, direct, and
3822 vrrp.
3824 The routing protocol defined applies at the provider-to-customer
3825 boundary. Depending on how the management model is administered, it
3826 may apply to the PE-CE boundary or the CE-to-customer boundary. In
3827 the case of a customer-managed site, the routing protocol defined
3828 will be activated between the PE and the CE router managed by the
3829 customer. In the case of a provider-managed site, the routing
3830 protocol defined will be activated between the CE managed by the SP
3831 and the router or LAN belonging to the customer. In this case, we
3832 expect the PE-CE routing to be configured based on the SP's rules, as
3833 both are managed by the same entity.
3835 Rtg protocol
3836 192.0.2.0/24 ----- CE ----------------- PE1
3838 Customer-managed site
3840 Rtg protocol
3841 Customer router ----- CE ----------------- PE1
3843 Provider-managed site
3845 All the examples below will refer to a scenario for a customer-
3846 managed site.
3848 6.11.1. Handling of Dual Stack
3850 All routing protocol types support dual stack by using the "address-
3851 family" leaf-list.
3853 Example of a corresponding XML snippet with dual stack using the same
3854 routing protocol:
3856
3857
3858
3859
3860 VPNA
3861
3862
3863
3864
3865 SITE1
3866
3867
3868 static
3869
3870
3871
3872 192.0.2.0/24
3873 203.0.113.1
3874
3875
3876
3877
3878
3879
3880
3881
3883 Example of a corresponding XML snippet with dual stack using two
3884 different routing protocols:
3886
3887
3888
3889
3890 VPNA
3891
3892
3893
3894
3895 SITE1
3896
3897
3898 rip
3899
3900 ipv4
3901
3902
3903
3904 ospf
3905
3906 ipv6
3907 4.4.4.4
3908
3909
3910
3911
3912
3913
3915 6.11.2. LAN Directly Connected to SP Network
3917 The routing protocol type "direct" SHOULD be used when a customer LAN
3918 is directly connected to the provider network and must be advertised
3919 in the IP VPN.
3921 LAN attached directly to provider network:
3923 192.0.2.0/24 ----- PE1
3925 In this case, the customer has a default route to the PE address.
3927 6.11.3. LAN Directly Connected to SP Network with Redundancy
3929 The routing protocol type "vrrp" SHOULD be used and advertised in the
3930 IP VPN when
3931 o the customer LAN is directly connected to the provider network,
3932 and
3934 o LAN redundancy is expected.
3936 LAN attached directly to provider network with LAN redundancy:
3938 192.0.2.0/24 ------ PE1
3939 |
3940 +--- PE2
3942 In this case, the customer has a default route to the SP network.
3944 6.11.4. Static Routing
3946 The routing protocol type "static" MAY be used when a customer LAN is
3947 connected to the provider network through a CE router and must be
3948 advertised in the IP VPN. In this case, the static routes give next
3949 hops (nh) to the CE and to the PE. The customer has a default route
3950 to the SP network.
3952 Static rtg
3953 192.0.2.0/24 ------ CE -------------- PE
3954 | |
3955 | Static route 192.0.2.0/24 nh CE
3956 Static route 0.0.0.0/0 nh PE
3958 6.11.5. RIP Routing
3960 The routing protocol type "rip" MAY be used when a customer LAN is
3961 connected to the provider network through a CE router and must be
3962 advertised in the IP VPN. For IPv4, the model assumes that RIP
3963 version 2 is used.
3965 In the case of dual-stack routing requested through this model, the
3966 management system will be responsible for configuring RIP (including
3967 the correct version number) and associated address families on
3968 network elements.
3970 RIP rtg
3971 192.0.2.0/24 ------ CE -------------- PE
3973 6.11.6. OSPF Routing
3975 The routing protocol type "ospf" MAY be used when a customer LAN is
3976 connected to the provider network through a CE router and must be
3977 advertised in the IP VPN.
3979 It can be used to extend an existing OSPF network and interconnect
3980 different areas. See [RFC4577] for more details.
3982 +---------------------+
3983 | |
3984 OSPF | | OSPF
3985 area 1 | | area 2
3986 (OSPF | | (OSPF
3987 area 1) --- CE ---------- PE PE ----- CE --- area 2)
3988 | |
3989 +---------------------+
3991 The model also defines an option to create an OSPF sham link between
3992 two sites sharing the same area and having a backdoor link. The sham
3993 link is created by referencing the target site sharing the same OSPF
3994 area. The management system will be responsible for checking to see
3995 if there is already a sham link configured for this VPN and area
3996 between the same pair of PEs. If there is no existing sham link, the
3997 management system will provision one. This sham link MAY be reused
3998 by other sites.
4000 +------------------------+
4001 | |
4002 | |
4003 | PE (--sham link--)PE |
4004 | | | |
4005 +----|----------------|--+
4006 | OSPF area 1 | OSPF area 1
4007 | |
4008 CE1 CE2
4009 | |
4010 (OSPF area 1) (OSPF area 1)
4011 | |
4012 +----------------+
4014 Regarding dual-stack support, the user MAY specify both IPv4 and IPv6
4015 address families, if both protocols should be routed through OSPF.
4016 As OSPF uses separate protocol instances for IPv4 and IPv6, the
4017 management system will need to configure both OSPF version 2 and OSPF
4018 version 3 on the PE-CE link.
4020 Other OSPF parameters, such as timers, are typically set by the SP
4021 and communicated to the customer outside the scope of this model.
4023 Example of a corresponding XML snippet with OSPF routing parameters
4024 in the service model:
4026
4027
4028
4029
4030 VPNA
4031
4032
4033
4034
4035 SITE1
4036
4037
4038 ospf
4039
4040 0.0.0.1
4041 ipv4
4042 ipv6
4043
4044
4045
4046
4047
4048
4050 Example of PE configuration done by the management system:
4052 router ospf 10
4053 area 0.0.0.1
4054 interface Ethernet0/0
4055 !
4056 router ospfv3 10
4057 area 0.0.0.1
4058 interface Ethernet0/0
4059 !
4061 6.11.7. BGP Routing
4063 The routing protocol type "bgp" MAY be used when a customer LAN is
4064 connected to the provider network through a CE router and must be
4065 advertised in the IP VPN.
4067 BGP rtg
4068 192.0.2.0/24 ------ CE -------------- PE
4070 The session addressing will be derived from connection parameters as
4071 well as the SP's knowledge of the addressing plan that is in use.
4073 In the case of dual-stack access, the user MAY request BGP routing
4074 for both IPv4 and IPv6 by specifying both address families. It will
4075 be up to the SP and management system to determine how to describe
4076 the configuration (two BGP sessions, single, multi-session, etc.).
4077 This, along with other BGP parameters such as timers, is communicated
4078 to the customer outside the scope of this model.
4080 The service configuration below activates BGP on the PE-CE link for
4081 both IPv4 and IPv6.
4083 BGP activation requires the SP to know the address of the customer
4084 peer. If the site-network-access connection addresses are used for
4085 BGP peering, the "static-address" allocation type for the IP
4086 connection MUST be used. Other peering mechanisms are outside the
4087 scope of this model. An example of a corresponding XML snippet is
4088 described as follows:
4090
4091
4092
4093
4094 VPNA
4095
4096
4097
4098
4099 SITE1
4100
4101
4102 bgp
4103
4104 65000
4105 ipv4
4106 ipv6
4107
4108
4109
4110
4111
4112
4114 Depending on the SP flavor, a management system can divide this
4115 service configuration into different flavors, as shown by the
4116 following examples.
4118 Example of PE configuration done by the management system (single
4119 IPv4 transport session):
4121 router bgp 100
4122 neighbor 203.0.113.2 remote-as 65000
4123 address-family ipv4 vrf Cust1
4124 neighbor 203.0.113.2 activate
4125 address-family ipv6 vrf Cust1
4126 neighbor 203.0.113.2 activate
4127 neighbor 203.0.113.2 route-map SET-NH-IPV6 out
4129 Example of PE configuration done by the management system (two
4130 sessions):
4132 router bgp 100
4133 neighbor 203.0.113.2 remote-as 65000
4134 neighbor 2001::2 remote-as 65000
4135 address-family ipv4 vrf Cust1
4136 neighbor 203.0.113.2 activate
4137 address-family ipv6 vrf Cust1
4138 neighbor 2001::2 activate
4140 Example of PE configuration done by the management system (multi-
4141 session):
4143 router bgp 100
4144 neighbor 203.0.113.2 remote-as 65000
4145 neighbor 203.0.113.2 multisession per-af
4146 address-family ipv4 vrf Cust1
4147 neighbor 203.0.113.2 activate
4148 address-family ipv6 vrf Cust1
4149 neighbor 203.0.113.2 activate
4150 neighbor 203.0.113.2 route-map SET-NH-IPV6 out
4152 6.12. Service
4154 The service defines service parameters associated with the site.
4156 6.12.1. Bandwidth
4158 The service bandwidth refers to the bandwidth requirement between the
4159 PE and the CE (WAN link bandwidth). The requested bandwidth is
4160 expressed as svc-input-bandwidth and svc-output-bandwidth in bits per
4161 second. The input/output direction uses the customer site as a
4162 reference: "input bandwidth" means download bandwidth for the site,
4163 and "output bandwidth" means upload bandwidth for the site.
4165 The service bandwidth is only configurable at the site-network-access
4166 level.
4168 Using a different input and output bandwidth will allow the SP to
4169 determine if the customer allows for asymmetric bandwidth access,
4170 such as ADSL. It can also be used to set rate-limiting in a
4171 different way for uploading and downloading on a symmetric bandwidth
4172 access.
4174 The bandwidth is a service bandwidth expressed primarily as IP
4175 bandwidth, but if the customer enables MPLS for Carriers' Carriers
4176 (CsC), this becomes MPLS bandwidth.
4178 6.12.2. MTU
4180 The service MTU refers to the maximum PDU size that the customer may
4181 use. If the customer sends packets which are longer than the
4182 requested service MTU, the network may discard it (or for IPv4,
4183 fragmented).
4185 6.12.3. QoS
4187 The model defines QoS parameters in an abstracted way:
4189 o qos-classification-policy: policy that defines a set of ordered
4190 rules to classify customer traffic.
4192 o qos-profile: QoS scheduling profile to be applied.
4194 6.12.3.1. QoS Classification
4196 QoS classification rules are handled by the "qos-classification-
4197 policy" container. The qos-classification-policy container is an
4198 ordered list of rules that match a flow or application and set the
4199 appropriate target class of service (target-class-id). The user can
4200 define the match using an application reference or a flow definition
4201 that is more specific (e.g., based on Layer 3 source and destination
4202 addresses, Layer 4 ports, and Layer 4 protocol). When a flow
4203 definition is used, the user can employ a "target-sites" leaf-list to
4204 identify the destination of a flow rather than using destination IP
4205 addresses. In such a case, an association between the site
4206 abstraction and the IP addresses used by this site must be done
4207 dynamically. How this association is done is out of scope for this
4208 document. The association of a site to an IP VPN is done through the
4209 "vpn-attachment" container. Therefore the user can also employ
4210 "target-sites" leaf-list and "vpn-attachment" to identify the
4211 destination of a flow targeted to specific vpn service. A rule that
4212 does not have a match statement is considered a match-all rule. An
4213 SP may implement a default terminal classification rule if the
4214 customer does not provide it. It will be up to the SP to determine
4215 its default target class. The current model defines some
4216 applications, but new application identities may be added through
4217 augmentation. The exact meaning of each application identity is up
4218 to the SP, so it will be necessary for the SP to advise the customer
4219 on the usage of application matching.
4221 Where the classification is done depends on the SP's implementation
4222 of the service, but classification concerns the flow coming from the
4223 customer site and entering the network.
4225 Provider network
4226 +-----------------------+
4227 192.0.2.0/24
4228 198.51.100.0/24 ---- CE --------- PE
4230 Traffic flow
4231 ---------->
4233 In the figure above, the management system should implement the
4234 classification rule:
4236 o in the ingress direction on the PE interface, if the CE is
4237 customer-managed.
4239 o in the ingress direction on the CE interface connected to the
4240 customer LAN, if the CE is provider-managed.
4242 The figure below describes a sample service description of QoS
4243 classification for a site:
4245
4246
4247
4248
4249 VPNA
4250
4252
4253
4254
4255 SITE1
4256
4257
4258
4259
4260 SvrA-http
4261
4262 192.0.2.0/24
4263 203.0.113.1/32
4264 80
4265 tcp
4266
4267 DATA2
4268
4269
4270 SvrA-ftp
4271
4272 192.0.2.0/24
4273 203.0.113.1/32
4274 21
4275 tcp
4276
4277 DATA2
4278
4279
4280 p2p
4281 p2p
4282 DATA3
4283
4284
4285 any
4286 DATA1
4287
4288
4289
4290
4291
4292
4293
4295 In the example above:
4297 o HTTP traffic from the 192.0.2.0/24 LAN destined for 203.0.113.1/32
4298 will be classified in DATA2.
4300 o FTP traffic from the 192.0.2.0/24 LAN destined for 203.0.113.1/32
4301 will be classified in DATA2.
4303 o Peer-to-peer traffic will be classified in DATA3.
4305 o All other traffic will be classified in DATA1.
4307 The order of rule list entries is defined by the user. The
4308 management system responsible for translating those rules in network
4309 element configuration MUST keep the same processing order in network
4310 element configuration.
4312 6.12.3.2. QoS Profile
4314 The user can choose either a standard profile provided by the
4315 operator or a custom profile. The "qos-profile" container defines
4316 the traffic-scheduling policy to be used by the SP.
4318 Provider network
4319 +-----------------------+
4320 192.0.2.0/24
4321 198.51.100.0/24 ---- CE --------- PE
4322 \ /
4323 qos-profile
4325 A custom QoS profile is defined as a list of classes of services and
4326 associated properties. The properties are:
4328 o direction: used to specify the direction to which the qos profile
4329 is applied. This model supports three direction settings: "Site-
4330 to-WAN", "WAN-to-Site", and "both". By default, the "both"
4331 direction value is used. In case of "both" direction, the
4332 provider should ensure scheduling according to the requested
4333 policy in both traffic directions (SP to customer and customer to
4334 SP). As an example, a device-scheduling policy may be implemented
4335 on both the PE side and the CE side of the WAN link. In case of
4336 "WAN-to-Site" direction, the provider should ensure scheduling
4337 from the SP network to the customer site. As an example, a
4338 device- scheduling policy may be implemented only on the PE side
4339 of the WAN link towards the customer.
4341 o rate-limit: used to rate-limit the class of service. The value is
4342 expressed as a percentage of the global service bandwidth. When
4343 the qos-profile container is implemented on the CE side, svc-
4344 output-bandwidth is taken into account as a reference. When it is
4345 implemented on the PE side, svc-input-bandwidth is used.
4347 o latency: used to define the latency constraint of the class. The
4348 latency constraint can be expressed as the lowest possible latency
4349 or a latency boundary expressed in milliseconds. How this latency
4350 constraint will be fulfilled is up to the SP's implementation of
4351 the service: a strict priority queuing may be used on the access
4352 and in the core network, and/or a low-latency routing
4353 configuration may be created for this traffic class.
4355 o jitter: used to define the jitter constraint of the class. The
4356 jitter constraint can be expressed as the lowest possible jitter
4357 or a jitter boundary expressed in microseconds. How this jitter
4358 constraint will be fulfilled is up to the SP's implementation of
4359 the service: a strict priority queuing may be used on the access
4360 and in the core network, and/or a jitter-aware routing
4361 configuration may be created for this traffic class.
4363 o bandwidth: used to define a guaranteed amount of bandwidth for the
4364 class of service. It is expressed as a percentage. The
4365 "guaranteed-bw-percent" parameter uses available bandwidth as a
4366 reference. When the qos-profile container is implemented on the
4367 CE side, svc-output-bandwidth is taken into account as a
4368 reference. When it is implemented on the PE side, svc-input-
4369 bandwidth is used. By default, the bandwidth reservation is only
4370 guaranteed at the access level. The user can use the "end-to-end"
4371 leaf to request an end-to-end bandwidth reservation, including
4372 across the MPLS transport network. (In other words, the SP will
4373 activate something in the MPLS core to ensure that the bandwidth
4374 request from the customer will be fulfilled by the MPLS core as
4375 well.) How this is done (e.g., RSVP reservation, controller
4376 reservation) is out of scope for this document.
4378 In addition, due to network conditions, some constraints may not be
4379 completely fulfilled by the SP; in this case, the SP should advise
4380 the customer about the limitations. How this communication is done
4381 is out of scope for this document.
4383 Example of service configuration using a standard QoS profile with
4384 the following corresponding XML snippet:
4386
4387
4388
4389
4390
4391 GOLD
4392
4393
4394 PLATINUM
4396
4397
4398
4399
4400
4401 VPNA
4402
4403
4404
4405
4406 SITE1
4407
4408
4409 L1
4410
4411
4412
4413
4414 1245HRTFGJGJ154654
4415
4416 VPNA
4417 spoke-role
4418
4419
4420
4421 provider-dhcp
4422
4423
4424 provider-dhcp
4425
4426
4427
4428
4429 layer3
4430
4431
4432 L1
4433
4434 100000000
4435 100000000
4436 1514
4437
4438
4439 PLATINUM
4440
4441
4442
4443 L1
4445
4446
4447 555555AAAA2344
4448
4449 VPNA
4450 spoke-role
4451
4452
4453
4454 provider-dhcp
4455
4456
4457 provider-dhcp
4458
4459
4460
4461
4462 layer3
4463
4464
4465 L1
4466
4467 2000000
4468 2000000
4469 1514
4470
4471
4472 GOLD
4473
4474
4475
4476
4477
4478
4479
4480
4482 Example of service configuration using a custom QoS profile with the
4483 following corresponding XML snippet:
4485
4486
4487
4488
4489
4490 GOLD
4492
4493
4494 PLATINUM
4495
4496
4497
4498
4499
4500 VPNA
4501
4502
4503
4504
4505 SITE1
4506
4507
4508 L1
4509
4510
4511
4512
4513 Site1
4514 L1
4515
4516
4517 provider-dhcp
4518
4519
4520 provider-dhcp
4521
4522
4523
4524 1514
4525 10000000
4526 10000000
4527
4528
4529
4530 layer3
4531
4532
4533 L1
4534
4535 VPNA
4536 spoke-role
4537
4538
4539 100000000
4540 100000000
4541
4542
4543
4544
4545 REAL_TIME
4546 both
4547 10
4548
4549
4550
4551
4552 80
4553
4554
4555
4556 DATA1
4557
4558 70
4559
4560
4561 80
4562
4563
4564
4565 DATA2
4566
4567 200
4568
4569
4570 5
4571
4572
4573
4574
4575
4576
4577
4578
4579
4580
4581
4582
4584 The custom QoS profile for Site1 defines a REAL_TIME class with a
4585 latency constraint expressed as the lowest possible latency. It also
4586 defines two data classes -- DATA1 and DATA2. The two classes express
4587 a latency boundary constraint as well as a bandwidth reservation, as
4588 the REAL_TIME class is rate-limited to 10% of the service bandwidth
4589 (10% of 100 Mbps = 10 Mbps). In cases where congestion occurs, the
4590 REAL_TIME traffic can go up to 10 Mbps (let's assume that only 5 Mbps
4591 are consumed). DATA1 and DATA2 will share the remaining bandwidth
4592 (95 Mbps) according to their percentage. So, the DATA1 class will be
4593 served with at least 76 Mbps of bandwidth, while the DATA2 class will
4594 be served with at least 4.75 Mbps. The latency boundary information
4595 of the data class may help the SP define a specific buffer tuning or
4596 a specific routing within the network. The maximum percentage to be
4597 used is not limited by this model but MUST be limited by the
4598 management system according to the policies authorized by the SP.
4600 6.12.4. Multicast
4602 The "multicast" container defines the type of site in the customer
4603 multicast service topology: source, receiver, or both. These
4604 parameters will help the management system optimize the multicast
4605 service. Users can also define the type of multicast relationship
4606 with the customer: router (requires a protocol such as PIM), host
4607 (IGMP or MLD), or both. An address family (IPv4, IPv6, or both) can
4608 also be defined.
4610 6.13. Enhanced VPN Features
4612 6.13.1. Carriers' Carriers
4614 In the case of CsC [RFC4364], a customer may want to build an MPLS
4615 service using an IP VPN to carry its traffic.
4617 LAN customer1
4618 |
4619 |
4620 CE1
4621 |
4622 | -------------
4623 (vrf_cust1)
4624 CE1_ISP1
4625 | ISP1 POP
4626 | MPLS link
4627 | -------------
4628 |
4629 (vrf ISP1)
4630 PE1
4632 (...) Provider backbone
4634 PE2
4635 (vrf ISP1)
4636 |
4637 | ------------
4638 |
4639 | MPLS link
4640 | ISP1 POP
4641 CE2_ISP1
4642 (vrf_cust1)
4643 | ------------
4644 |
4645 CE2
4646 |
4647 LAN customer1
4649 In the figure above, ISP1 resells an IP VPN service but has no core
4650 network infrastructure between its POPs. ISP1 uses an IP VPN as the
4651 core network infrastructure (belonging to another provider) between
4652 its POPs.
4654 In order to support CsC, the VPN service must indicate MPLS support
4655 by setting the "carrierscarrier" leaf to true in the vpn-service
4656 list. The link between CE1_ISP1/PE1 and CE2_ISP1/PE2 must also run
4657 an MPLS signalling protocol. This configuration is done at the site
4658 level.
4660 In the proposed model, LDP or BGP can be used as the MPLS signalling
4661 protocol. In the case of LDP, an IGP routing protocol MUST also be
4662 activated. In the case of BGP signalling, BGP MUST also be
4663 configured as the routing protocol.
4665 If CsC is enabled, the requested "svc-mtu" leaf will refer to the
4666 MPLS MTU and not to the IP MTU.
4668 6.14. External ID References
4670 The service model sometimes refers to external information through
4671 identifiers. As an example, to order a cloud-access to a particular
4672 cloud service provider (CSP), the model uses an identifier to refer
4673 to the targeted CSP. If a customer is directly using this service
4674 model as an API (through REST or NETCONF, for example) to order a
4675 particular service, the SP should provide a list of authorized
4676 identifiers. In the case of cloud-access, the SP will provide the
4677 associated identifiers for each available CSP. The same applies to
4678 other identifiers, such as std-qos-profile, OAM profile-name, and
4679 provider-profile for encryption.
4681 How an SP provides the meanings of those identifiers to the customer
4682 is out of scope for this document.
4684 6.15. Defining NNIs
4686 An autonomous system (AS) is a single network or group of networks
4687 that is controlled by a common system administration group and that
4688 uses a single, clearly defined routing protocol. In some cases, VPNs
4689 need to span different ASes in different geographic areas or span
4690 different SPs. The connection between ASes is established by the SPs
4691 and is seamless to the customer. Examples include
4693 o a partnership between SPs (e.g., carrier, cloud) to extend their
4694 VPN service seamlessly.
4696 o an internal administrative boundary within a single SP (e.g.,
4697 backhaul versus core versus data center).
4699 NNIs (network-to-network interfaces) have to be defined to extend the
4700 VPNs across multiple ASes.
4702 [RFC4364] defines multiple flavors of VPN NNI implementations. Each
4703 implementation has pros and cons; this topic is outside the scope of
4704 this document. For example, in an Inter-AS option A, autonomous
4705 system border router (ASBR) peers are connected by multiple
4706 interfaces with at least one of those interfaces spanning the two
4707 ASes while being present in the same VPN. In order for these ASBRs
4708 to signal unlabeled IP prefixes, they associate each interface with a
4709 VPN routing and forwarding (VRF) instance and a Border Gateway
4710 Protocol (BGP) session. As a result, traffic between the back-to-
4711 back VRFs is IP. In this scenario, the VPNs are isolated from each
4712 other, and because the traffic is IP, QoS mechanisms that operate on
4713 IP traffic can be applied to achieve customer service level
4714 agreements (SLAs).
4716 -------- -------------- -----------
4717 / \ / \ / \
4718 | Cloud | | | | |
4719 | Provider |-----NNI-----| |----NNI---| Data Center |
4720 | #1 | | | | |
4721 \ / | | \ /
4722 -------- | | -----------
4723 | |
4724 -------- | My network | -----------
4725 / \ | | / \
4726 | Cloud | | | | |
4727 | Provider |-----NNI-----| |---NNI---| L3VPN |
4728 | #2 | | | | Partner |
4729 \ / | | | |
4730 -------- | | | |
4731 \ / | |
4732 -------------- \ /
4733 | -----------
4734 |
4735 NNI
4736 |
4737 |
4738 -------------------
4739 / \
4740 | |
4741 | |
4742 | |
4743 | L3VPN Partner |
4744 | |
4745 \ /
4746 -------------------
4748 The figure above describes an SP network called "My network" that has
4749 several NNIs. This network uses NNIs to:
4751 o increase its footprint by relying on L3VPN partners.
4753 o connect its own data center services to the customer IP VPN.
4755 o enable the customer to access its private resources located in a
4756 private cloud owned by some CSPs.
4758 6.15.1. Defining an NNI with the Option A Flavor
4760 AS A AS B
4761 ------------------- -------------------
4762 / \ / \
4763 | | | |
4764 | ++++++++ Inter-AS link ++++++++ |
4765 | + +_______________+ + |
4766 | + (VRF1)---(VPN1)----(VRF1) + |
4767 | + ASBR + + ASBR + |
4768 | + (VRF2)---(VPN2)----(VRF2) + |
4769 | + +_______________+ + |
4770 | ++++++++ ++++++++ |
4771 | | | |
4772 | | | |
4773 | | | |
4774 | ++++++++ Inter-AS link ++++++++ |
4775 | + +_______________+ + |
4776 | + (VRF1)---(VPN1)----(VRF1) + |
4777 | + ASBR + + ASBR + |
4778 | + (VRF2)---(VPN2)----(VRF2) + |
4779 | + +_______________+ + |
4780 | ++++++++ ++++++++ |
4781 | | | |
4782 | | | |
4783 \ / \ /
4784 ------------------- -------------------
4786 In option A, the two ASes are connected to each other with physical
4787 links on ASBRs. For resiliency purposes, there may be multiple
4788 physical connections between the ASes. A VPN connection -- physical
4789 or logical (on top of physical) -- is created for each VPN that needs
4790 to cross the AS boundary, thus providing a back-to-back VRF model.
4792 From a service model's perspective, this VPN connection can be seen
4793 as a site. Let's say that AS B wants to extend some VPN connections
4794 for VPN C on AS A. The administrator of AS B can use this service
4795 model to order a site on AS A. All connection scenarios could be
4796 realized using the features of the current model. As an example, the
4797 figure above shows two physical connections that have logical
4798 connections per VPN overlaid on them. This could be seen as a dual-
4799 homed subVPN scenario. Also, the administrator of AS B will be able
4800 to choose the appropriate routing protocol (e.g., E-BGP) to
4801 dynamically exchange routes between ASes.
4803 This document assumes that the option A NNI flavor SHOULD reuse the
4804 existing VPN site modeling.
4806 Example: a customer wants its CSP A to attach its virtual network N
4807 to an existing IP VPN (VPN1) that he has from L3VPN SP B.
4809 CSP A L3VPN SP B
4811 ----------------- -------------------
4812 / \ / \
4813 | | | | |
4814 | VM --| ++++++++ NNI ++++++++ |--- VPN1
4815 | | + +_________+ + | Site#1
4816 | |--------(VRF1)---(VPN1)--(VRF1)+ |
4817 | | + ASBR + + ASBR + |
4818 | | + +_________+ + |
4819 | | ++++++++ ++++++++ |
4820 | VM --| | | |--- VPN1
4821 | |Virtual | | | Site#2
4822 | |Network | | |
4823 | VM --| | | |--- VPN1
4824 | | | | | Site#3
4825 \ / \ /
4826 ----------------- -------------------
4827 |
4828 |
4829 VPN1
4830 Site#4
4832 To create the VPN connectivity, the CSP or the customer may use the
4833 L3VPN service model that SP B exposes. We could consider that, as
4834 the NNI is shared, the physical connection (bearer) between CSP A and
4835 SP B already exists. CSP A may request through a service model the
4836 creation of a new site with a single site-network-access (single-
4837 homing is used in the figure). As a placement constraint, CSP A may
4838 use the existing bearer reference it has from SP A to force the
4839 placement of the VPN NNI on the existing link. The XML snippet below
4840 illustrates a possible configuration request to SP B:
4842
4843
4844
4845
4846
4847 GOLD
4848
4849
4850 PLATINUM
4851
4852
4854
4855
4856
4857 VPN1
4858
4859
4860
4861
4862 CSP_A_attachment
4863
4864
4865 layer3
4866
4867
4868
4869
4870 L1
4871
4872
4873
4874
4875 1
4876 NY
4877 US
4878
4879
4880 site-vpn-flavor-nni
4881
4882
4883 bgp
4884
4885 500
4886 ipv4
4887
4888
4889
4890
4891
4892 CSP_A_VN1
4893 L1
4894
4895
4896 provider-dhcp
4897
4898
4899 provider-dhcp
4900
4901
4902
4903
4904
4905 static-address
4906
4907
4908 203.0.113.1
4909 203.0.113.2
4910 30
4911
4912
4913
4914
4915 450000000
4916 450000000
4917 1514
4918
4919
4920
4921 layer3
4922
4923
4924
4925 VPN1
4926 any-to-any-role
4927
4928
4929
4930
4931 customer-managed
4932
4933
4934
4935
4937 The case described above is different from a scenario using the
4938 cloud-accesses container, as the cloud-access provides a public cloud
4939 access while this example enables access to private resources located
4940 in a CSP network.
4942 6.15.2. Defining an NNI with the Option B Flavor
4943 AS A AS B
4944 ------------------- -------------------
4945 / \ / \
4946 | | | |
4947 | ++++++++ Inter-AS link ++++++++ |
4948 | + +_______________+ + |
4949 | + + + + |
4950 | + ASBR +<---MP-BGP---->+ ASBR + |
4951 | + + + + |
4952 | + +_______________+ + |
4953 | ++++++++ ++++++++ |
4954 | | | |
4955 | | | |
4956 | | | |
4957 | ++++++++ Inter-AS link ++++++++ |
4958 | + +_______________+ + |
4959 | + + + + |
4960 | + ASBR +<---MP-BGP---->+ ASBR + |
4961 | + + + + |
4962 | + +_______________+ + |
4963 | ++++++++ ++++++++ |
4964 | | | |
4965 | | | |
4966 \ / \ /
4967 ------------------- -------------------
4969 In option B, the two ASes are connected to each other with physical
4970 links on ASBRs. For resiliency purposes, there may be multiple
4971 physical connections between the ASes. The VPN "connection" between
4972 ASes is done by exchanging VPN routes through MP-BGP [RFC4760].
4974 There are multiple flavors of implementations of such an NNI. For
4975 example:
4977 1. The NNI is internal to the provider and is situated between a
4978 backbone and a data center. There is enough trust between the
4979 domains to not filter the VPN routes. So, all the VPN routes are
4980 exchanged. RT filtering may be implemented to save some
4981 unnecessary route states.
4983 2. The NNI is used between providers that agreed to exchange VPN
4984 routes for specific RTs only. Each provider is authorized to use
4985 the RT values from the other provider.
4987 3. The NNI is used between providers that agreed to exchange VPN
4988 routes for specific RTs only. Each provider has its own RT
4989 scheme. So, a customer spanning the two networks will have
4990 different RTs in each network for a particular VPN.
4992 Case 1 does not require any service modeling, as the protocol enables
4993 the dynamic exchange of necessary VPN routes.
4995 Case 2 requires that an RT-filtering policy on ASBRs be maintained.
4996 From a service modeling point of view, it is necessary to agree on
4997 the list of RTs to authorize.
4999 In Case 3, both ASes need to agree on the VPN RT to exchange, as well
5000 as how to map a VPN RT from AS A to the corresponding RT in AS B (and
5001 vice versa).
5003 Those modelings are currently out of scope for this document.
5005 CSP A L3VPN SP B
5007 ----------------- ------------------
5008 / \ / \
5009 | | | | |
5010 | VM --| ++++++++ NNI ++++++++ |--- VPN1
5011 | | + +__________+ + | Site#1
5012 | |-------+ + + + |
5013 | | + ASBR +<-MP-BGP->+ ASBR + |
5014 | | + +__________+ + |
5015 | | ++++++++ ++++++++ |
5016 | VM --| | | |--- VPN1
5017 | |Virtual | | | Site#2
5018 | |Network | | |
5019 | VM --| | | |--- VPN1
5020 | | | | | Site#3
5021 \ / | |
5022 ----------------- | |
5023 \ /
5024 ------------------
5025 |
5026 |
5027 VPN1
5028 Site#4
5030 The example above describes an NNI connection between CSP A and SP
5031 network B. Both SPs do not trust themselves and use a different RT
5032 allocation policy. So, in terms of implementation, the customer VPN
5033 has a different RT in each network (RT A in CSP A and RT B in SP
5034 network B). In order to connect the customer virtual network in CSP
5035 A to the customer IP VPN (VPN1) in SP network B, CSP A should request
5036 that SP network B open the customer VPN on the NNI (accept the
5037 appropriate RT). Who does the RT translation depends on the
5038 agreement between the two SPs: SP B may permit CSP A to request VPN
5039 (RT) translation.
5041 6.15.3. Defining an NNI with the Option C Flavor
5043 AS A AS B
5044 ------------------- -------------------
5045 / \ / \
5046 | | | |
5047 | | | |
5048 | | | |
5049 | ++++++++ Multihop E-BGP ++++++++ |
5050 | + + + + |
5051 | + + + + |
5052 | + RGW +<----MP-BGP---->+ RGW + |
5053 | + + + + |
5054 | + + + + |
5055 | ++++++++ ++++++++ |
5056 | | | |
5057 | | | |
5058 | | | |
5059 | | | |
5060 | | | |
5061 | ++++++++ Inter-AS link ++++++++ |
5062 | + +_______________+ + |
5063 | + + + + |
5064 | + ASBR + + ASBR + |
5065 | + + + + |
5066 | + +_______________+ + |
5067 | ++++++++ ++++++++ |
5068 | | | |
5069 | | | |
5070 | | | |
5071 | ++++++++ Inter-AS link ++++++++ |
5072 | + +_______________+ + |
5073 | + + + + |
5074 | + ASBR + + ASBR + |
5075 | + + + + |
5076 | + +_______________+ + |
5077 | ++++++++ ++++++++ |
5078 | | | |
5079 | | | |
5080 \ / \ /
5081 ------------------- -------------------
5083 From a VPN service's perspective, the option C NNI is very similar to
5084 option B, as an MP-BGP session is used to exchange VPN routes between
5085 the ASes. The difference is that the forwarding plane and the
5086 control plane are on different nodes, so the MP-BGP session is
5087 multihop between routing gateway (RGW) nodes.
5089 From a VPN service's point of view, modeling options B and C will be
5090 identical.
5092 7. Service Model Usage Example
5094 As explained in Section 5, this service model is intended to be
5095 instantiated at a management layer and is not intended to be used
5096 directly on network elements. The management system serves as a
5097 central point of configuration of the overall service.
5099 This section provides an example of how a management system can use
5100 this model to configure an IP VPN service on network elements.
5102 In this example, we want to achieve the provisioning of a VPN service
5103 for three sites using a Hub-and-Spoke VPN service topology. One of
5104 the sites will be dual-homed, and load-sharing is expected.
5106 +-------------------------------------------------------------+
5107 | Hub_Site ------ PE1 PE2 ------ Spoke_Site1 |
5108 | | +----------------------------------+
5109 | | |
5110 | | +----------------------------------+
5111 | Hub_Site ------ PE3 PE4 ------ Spoke_Site2 |
5112 +-------------------------------------------------------------+
5114 The following XML snippet describes the overall simplified service
5115 configuration of this VPN.
5117
5118
5119
5120
5121
5122 GOLD
5123
5124
5125 PLATINUM
5126
5127
5128
5129
5130
5131 12456487
5132 hub-spoke
5133
5134
5135
5137 When receiving the request for provisioning the VPN service, the
5138 management system will internally (or through communication with
5139 another OSS component) allocate VPN RTs. In this specific case, two
5140 RTs will be allocated (100:1 for Hub and 100:2 for Spoke). The
5141 output of corresponding XML snippet below describes the configuration
5142 of Spoke_Site1.
5144
5145
5146
5147
5148
5149 GOLD
5150
5151
5152 PLATINUM
5153
5154
5155
5156
5157
5158 12456487
5159 hub-spoke
5160
5161
5162
5163
5164 Spoke_Site1
5165
5166
5167 D1
5168
5169
5170
5171
5172 1
5173 NY
5174 US
5175
5176
5177
5178
5179 layer3
5180
5181
5182
5183
5184 bgp
5185
5186 500
5187 ipv4
5188 ipv6
5189
5190
5191
5192
5193
5194 Spoke_Site1
5195 D1
5196
5197
5198
5199 20
5200
5201
5202
5203
5204 pe-diverse
5205
5206
5207 10
5208
5209
5210
5211
5213
5214
5215
5216
5217 static-address
5218
5219
5220 203.0.113.254
5221 203.0.113.2
5222 24
5223
5224
5225
5226
5227 static-address
5228
5229
5230 2001:db8::1
5231 2001:db8::2
5232 64
5233
5234
5235
5236
5237 450000000
5238 450000000
5239 1514
5240
5241
5242
5243 layer3
5244
5245
5246
5247 12456487
5248 spoke-role
5249
5250
5251
5252
5253 provider-managed
5254
5255
5256
5257
5258 When receiving the request for provisioning Spoke_Site1, the
5259 management system MUST allocate network resources for this site. It
5260 MUST first determine the target network elements to provision the
5261 access, particularly the PE router (and perhaps also an aggregation
5262 switch). As described in Section 6.6, the management system SHOULD
5263 use the location information and MUST use the access-diversity
5264 constraint to find the appropriate PE. In this case, we consider
5265 that Spoke_Site1 requires PE diversity with the Hub and that the
5266 management system allocates PEs based on the least distance. Based
5267 on the location information, the management system finds the
5268 available PEs in the area nearest the customer and picks one that
5269 fits the access-diversity constraint.
5271 When the PE is chosen, the management system needs to allocate
5272 interface resources on the node. One interface is selected from the
5273 pool of available PEs. The management system can start provisioning
5274 the chosen PE node via whatever means the management system prefers
5275 (e.g., NETCONF, CLI). The management system will check to see if a
5276 VRF that fits its needs is already present. If not, it will
5277 provision the VRF: the RD will be derived from the internal
5278 allocation policy model, and the RTs will be derived from the VPN
5279 policy configuration of the site (the management system allocated
5280 some RTs for the VPN). As the site is a Spoke site (site-role), the
5281 management system knows which RTs must be imported and exported. As
5282 the site is provider-managed, some management RTs may also be added
5283 (100:5000). Standard provider VPN policies MAY also be added in the
5284 configuration.
5286 Example of generated PE configuration:
5288 ip vrf Customer1
5289 export-map STD-CUSTOMER-EXPORT <---- Standard SP configuration
5290 route-distinguisher 100:3123234324
5291 route-target import 100:1
5292 route-target import 100:5000 <---- Standard SP configuration
5293 route-target export 100:2 for provider-managed CE
5294 !
5296 When the VRF has been provisioned, the management system can start
5297 configuring the access on the PE using the allocated interface
5298 information. IP addressing is chosen by the management system. One
5299 address will be picked from an allocated subnet for the PE, and
5300 another will be used for the CE configuration. Routing protocols
5301 will also be configured between the PE and CE; because this model is
5302 provider-managed, the choices are left to the SP. BGP was chosen for
5303 this example. This choice is independent of the routing protocol
5304 chosen by the customer. BGP will be used to configure the CE-to-LAN
5305 connection as requested in the service model. Peering addresses will
5306 be derived from those of the connection. As the CE is provider-
5307 managed, the CE's AS number can be automatically allocated by the
5308 management system. Standard configuration templates provided by the
5309 SP may also be added.
5311 Example of generated PE configuration:
5313 interface Ethernet1/1/0.10
5314 encapsulation dot1q 10
5315 ip vrf forwarding Customer1
5316 ip address 198.51.100.1 255.255.255.252 <---- Comes from
5317 automated allocation
5318 ipv6 address 2001:db8::10:1/64
5319 ip access-group STD-PROTECT-IN <---- Standard SP config
5320 !
5321 router bgp 100
5322 address-family ipv4 vrf Customer1
5323 neighbor 198.51.100.2 remote-as 65000 <---- Comes from
5324 automated allocation
5325 neighbor 198.51.100.2 route-map STD in <---- Standard SP config
5326 neighbor 198.51.100.2 filter-list 10 in <---- Standard SP config
5327 !
5328 address-family ipv6 vrf Customer1
5329 neighbor 2001:db8::0a10:2 remote-as 65000 <---- Comes from
5330 automated allocation
5331 neighbor 2001:db8::0a10:2 route-map STD in <---- Standard SP
5332 config
5333 neighbor 2001:db8::0a10:2 filter-list 10 in <---- Standard SP
5334 config
5335 !
5336 ip route vrf Customer1 192.0.2.1 255.255.255.255 198.51.100.2
5337 ! Static route for provider administration of CE
5338 !
5340 As the CE router is not reachable at this stage, the management
5341 system can produce a complete CE configuration that can be manually
5342 uploaded to the node before sending the CE configuration to the
5343 customer premises. The CE configuration will be built in the same
5344 way as the PE would be configured. Based on the CE type (vendor/
5345 model) allocated to the customer as well as the bearer information,
5346 the management system knows which interface must be configured on the
5347 CE. PE-CE link configuration is expected to be handled automatically
5348 using the SP OSS, as both resources are managed internally. CE-to-
5349 LAN-interface parameters such as IP addressing are derived from the
5350 ip-connection container, taking into account how the management
5351 system distributes addresses between the PE and CE within the subnet.
5353 This will allow a plug-and-play configuration for the CE to be
5354 created.
5356 Example of generated CE configuration:
5358 interface Loopback10
5359 description "Administration"
5360 ip address 192.0.2.1 255.255.255.255
5361 !
5362 interface FastEthernet10
5363 description "WAN"
5364 ip address 198.51.100.2 255.255.255.252 <---- Comes from
5365 automated allocation
5366 ipv6 address 2001:db8::0a10:2/64
5367 !
5368 interface FastEthernet11
5369 description "LAN"
5370 ip address 203.0.113.254 255.255.255.0 <---- Comes from the
5371 ip-connection container
5372 ipv6 address 2001:db8::1/64
5373 !
5374 router bgp 65000
5375 address-family ipv4
5376 redistribute static route-map STATIC2BGP <---- Standard SP
5377 configuration
5378 neighbor 198.51.100.1 remote-as 100 <---- Comes from
5379 automated allocation
5380 neighbor 203.0.113.2 remote-as 500 <---- Comes from the
5381 ip-connection container
5382 address-family ipv6
5383 redistribute static route-map STATIC2BGP <---- Standard SP
5384 configuration
5385 neighbor 2001:db8::0a10:1 remote-as 100 <---- Comes from
5386 automated allocation
5387 neighbor 2001:db8::2 remote-as 500 <---- Comes from the
5388 ip-connection container
5389 !
5390 route-map STATIC2BGP permit 10
5391 match tag 10
5392 !
5394 8. Interaction with Other YANG Modules
5396 As expressed in Section 5, this service model is intended to be
5397 instantiated in a management system and not directly on network
5398 elements.
5400 The management system's role will be to configure the network
5401 elements. The management system may be modular, so the component
5402 instantiating the service model (let's call it "service component")
5403 and the component responsible for network element configuration
5404 (let's call it "configuration component") may be different.
5406 l3vpn-svc |
5407 Model |
5408 |
5409 +---------------------+
5410 | Service component | Service datastore
5411 +---------------------+
5412 |
5413 |
5414 +---------------------+
5415 +----| Config component |------+
5416 / +---------------------+ \ Network
5417 / / \ \ Configuration
5418 / / \ \ models
5419 / / \ \
5420 ++++++++ ++++++++ ++++++++ ++++++++
5421 + CE A + ------- + PE A + + PE B + ----- + CE B + Config
5422 ++++++++ ++++++++ ++++++++ ++++++++ datastore
5424 Site A Site B
5426 In the previous sections, we provided some examples of the
5427 translation of service provisioning requests to router configuration
5428 lines. In the NETCONF/YANG ecosystem, we expect NETCONF/YANG to be
5429 used between the configuration component and network elements to
5430 configure the requested services on those elements.
5432 In this framework, specifications are expected to provide specific
5433 YANG modeling of service components on network elements. There will
5434 be a strong relationship between the abstracted view provided by this
5435 service model and the detailed configuration view that will be
5436 provided by specific configuration models for network elements.
5438 The authors of this document anticipate definitions of YANG models
5439 for the network elements listed below. Note that this list is not
5440 exhaustive:
5442 o VRF definition, including VPN policy expression.
5444 o Physical interface.
5446 o IP layer (IPv4, IPv6).
5448 o QoS: classification, profiles, etc.
5450 o Routing protocols: support of configuration of all protocols
5451 listed in the document, as well as routing policies associated
5452 with those protocols.
5454 o Multicast VPN.
5456 o Network address translation.
5458 Example of a corresponding XML snippet with a VPN site request at the
5459 service level, using this model:
5461
5462
5463
5464
5465
5466 GOLD
5467
5468
5469 PLATINUM
5470
5471
5472
5473
5474
5475 VPN1
5476 hub-spoke
5477
5478
5479
5480
5481 Site A
5482
5483
5484 layer3
5485
5486
5487
5488
5489 L1
5490
5491
5492
5493
5494 1
5495
5496
5497
5498 static-address
5499
5500
5501 203.0.113.254
5502 203.0.113.2
5503 24
5504
5505
5506
5507 provider-dhcp
5508
5509
5510
5511 1514
5512 10000000
5513 10000000
5514
5515 L1
5516
5517 VPNPOL1
5518
5519
5520
5521
5522
5523 static
5524
5525
5526
5527 198.51.100.0/30
5528 203.0.113.2
5529
5530
5531
5532
5533
5534
5535 customer-managed
5536
5537
5538
5539 VPNPOL1
5540
5541 1
5542
5543 VPN1
5544 any-to-any-role
5545
5546
5547
5548
5549
5550
5551
5553 In the service example above, the service component is expected to
5554 request that the configuration component of the management system
5555 provide the configuration of the service elements. If we consider
5556 that the service component selected a PE (PE A) as the target PE for
5557 the site, the configuration component will need to push the
5558 configuration to PE A. The configuration component will use several
5559 YANG data models to define the configuration to be applied to PE A.
5560 The XML snippet configuration of PE A might look like this:
5562
5563
5564 eth0
5565 ianaift:ethernetCsmacd
5566
5567 Link to CE A.
5568
5569
5570
5571 203.0.113.254
5572 24
5573
5574 true
5575
5576
5577
5578
5579
5580 VRF_CustA
5581 l3vpn-network:vrf
5582 VRF for Customer A
5583
5584 100:1546542343
5585
5586 100:1
5587 100:1
5588
5589
5590 eth0
5592
5593
5594
5595
5596 rt:static
5597 st0
5598
5599
5600
5601
5602 198.51.100.0/30
5603
5604
5605
5606 203.0.113.2
5607
5608
5609
5610
5611
5612
5613
5614
5615
5617 9. YANG Module
5619 file "ietf-l3vpn-svc@2017-10-11.yang"
5620 module ietf-l3vpn-svc {
5621 yang-version 1.1;
5622 namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
5623 prefix l3vpn-svc;
5624 import ietf-inet-types {
5625 prefix inet;
5626 }
5627 import ietf-yang-types {
5628 prefix yang;
5629 }
5630 import ietf-netconf-acm {
5631 prefix nacm;
5632 }
5633 organization
5634 "IETF L3SM Working Group";
5635 contact
5636 "WG List:
5637 Editor:
5638 L3SM WG
5640 Chairs:
5641 Adrian Farrel, Qin Wu
5642 ";
5643 description
5644 "This YANG module defines a generic service configuration
5645 model for Layer 3 VPNs. This model is common across all
5646 vendor implementations.";
5647 revision 2017-10-11 {
5648 description
5649 "First revision of RFC8049.";
5650 reference
5651 "RFC xxxx: YANG Data Model for L3VPN Service Delivery";
5652 }
5653 /* Features */
5654 feature cloud-access {
5655 description
5656 "Allows the VPN to connect to a CSP.";
5657 }
5658 feature multicast {
5659 description
5660 "Enables multicast capabilities in a VPN.";
5661 }
5662 feature ipv4 {
5663 description
5664 "Enables IPv4 support in a VPN.";
5665 }
5666 feature ipv6 {
5667 description
5668 "Enables IPv6 support in a VPN.";
5669 }
5670 feature lan-tag {
5671 description
5672 "Enables LAN Tag support in a VPN Policy Filter.";
5673 }
5674 feature carrierscarrier {
5675 description
5676 "Enables support of CsC.";
5677 }
5678 feature extranet-vpn {
5679 description
5680 "Enables support of extranet VPNs.";
5681 }
5682 feature site-diversity {
5683 description
5684 "Enables support of site diversity constraints.";
5685 }
5686 feature encryption {
5687 description
5688 "Enables support of encryption.";
5689 }
5690 feature qos {
5691 description
5692 "Enables support of classes of services.";
5693 }
5694 feature qos-custom {
5696 description
5697 "Enables support of the custom QoS profile.";
5698 }
5699 feature rtg-bgp {
5700 description
5701 "Enables support of the BGP routing protocol.";
5702 }
5703 feature rtg-rip {
5704 description
5705 "Enables support of the RIP routing protocol.";
5706 }
5707 feature rtg-ospf {
5708 description
5709 "Enables support of the OSPF routing protocol.";
5710 }
5711 feature rtg-ospf-sham-link {
5712 description
5713 "Enables support of OSPF sham links.";
5714 }
5715 feature rtg-vrrp {
5716 description
5717 "Enables support of the VRRP routing protocol.";
5718 }
5719 feature fast-reroute {
5720 description
5721 "Enables support of Fast Reroute.";
5722 }
5723 feature bfd {
5724 description
5725 "Enables support of BFD.";
5726 }
5727 feature always-on {
5728 description
5729 "Enables support of the 'always-on' access constraint.";
5730 }
5731 feature requested-type {
5732 description
5733 "Enables support of the 'requested-type' access constraint.";
5734 }
5735 feature bearer-reference {
5736 description
5737 "Enables support of the 'bearer-reference' access constraint.";
5738 }
5739 feature target-sites {
5740 description
5741 "Enables support of the 'target-sites' match flow parameter.";
5742 }
5743 /* Typedefs */
5744 typedef svc-id {
5745 type string;
5746 description
5747 "Defines a type of service component identifier.";
5748 }
5749 typedef template-id {
5750 type string;
5751 description
5752 "Defines a type of service template identifier.";
5753 }
5754 typedef address-family {
5755 type enumeration {
5756 enum ipv4 {
5757 description
5758 "IPv4 address family.";
5759 }
5760 enum ipv6 {
5761 description
5762 "IPv6 address family.";
5763 }
5764 }
5765 description
5766 "Defines a type for the address family.";
5767 }
5768 /* Identities */
5769 identity site-network-access-type {
5770 description
5771 "Base identity for site-network-access type.";
5772 }
5773 identity point-to-point {
5774 base site-network-access-type;
5775 description
5776 "Identity for point-to-point connection.";
5777 }
5778 identity multipoint {
5779 base site-network-access-type;
5780 description
5781 "Identity for multipoint connection.
5782 Example: Ethernet broadcast segment.";
5783 }
5784 identity placement-diversity {
5785 description
5786 "Base identity for site placement constraints.";
5787 }
5788 identity bearer-diverse {
5789 base placement-diversity;
5790 description
5791 "Identity for bearer diversity.
5792 The bearers should not use common elements.";
5793 }
5794 identity pe-diverse {
5795 base placement-diversity;
5796 description
5797 "Identity for PE diversity.";
5798 }
5799 identity pop-diverse {
5800 base placement-diversity;
5801 description
5802 "Identity for POP diversity.";
5803 }
5804 identity linecard-diverse {
5805 base placement-diversity;
5806 description
5807 "Identity for linecard diversity.";
5808 }
5809 identity same-pe {
5810 base placement-diversity;
5811 description
5812 "Identity for having sites connected on the same PE.";
5813 }
5814 identity same-bearer {
5815 base placement-diversity;
5816 description
5817 "Identity for having sites connected using the same bearer.";
5818 }
5819 identity customer-application {
5820 description
5821 "Base identity for customer application.";
5822 }
5823 identity web {
5824 base customer-application;
5825 description
5826 "Identity for Web application (e.g., HTTP, HTTPS).";
5827 }
5828 identity mail {
5829 base customer-application;
5830 description
5831 "Identity for mail application.";
5833 }
5834 identity file-transfer {
5835 base customer-application;
5836 description
5837 "Identity for file transfer application (e.g., FTP, SFTP).";
5838 }
5839 identity database {
5840 base customer-application;
5842 description
5843 "Identity for database application.";
5844 }
5845 identity social {
5846 base customer-application;
5847 description
5848 "Identity for social-network application.";
5849 }
5850 identity games {
5851 base customer-application;
5852 description
5853 "Identity for gaming application.";
5854 }
5855 identity p2p {
5856 base customer-application;
5857 description
5858 "Identity for peer-to-peer application.";
5859 }
5860 identity network-management {
5861 base customer-application;
5862 description
5863 "Identity for management application
5864 (e.g., Telnet, syslog, SNMP).";
5865 }
5866 identity voice {
5867 base customer-application;
5868 description
5869 "Identity for voice application.";
5870 }
5871 identity video {
5872 base customer-application;
5873 description
5874 "Identity for video conference application.";
5875 }
5876 identity embb {
5877 base customer-application;
5878 description
5879 "Identity for enhanced Mobile Broadband(eMBB)
5880 application. Note that eMBB application demands
5881 the network performance with wide variety of
5882 characteristics such as data rate, latency,
5883 loss rate, reliability and many other parameters.";
5884 }
5885 identity urllc {
5886 base customer-application;
5887 description
5888 "Identity for Ultra-Reliable and Low Latency
5889 Communications (URLLC) application. Note that
5890 URLLC application demands the network performance
5891 with wide variety of characteristics such as latency,
5892 reliability and many other parameters.";
5893 }
5894 identity mmtc {
5895 base customer-application;
5896 description
5897 "Identity for massive Machine Type
5898 Communications (mMTC) application. Note that
5899 mMTC application demands the network performance
5900 with wide variety of characteristics such as data
5901 rate, latency, loss rate, reliability and many
5902 other parameters.";
5903 }
5904 identity site-vpn-flavor {
5905 description
5906 "Base identity for the site VPN service flavor.";
5907 }
5908 identity site-vpn-flavor-single {
5909 base site-vpn-flavor;
5910 description
5911 "Base identity for the site VPN service flavor.
5912 Used when the site belongs to only one VPN.";
5913 }
5914 identity site-vpn-flavor-multi {
5915 base site-vpn-flavor;
5916 description
5917 "Base identity for the site VPN service flavor.
5918 Used when a logical connection of a site
5919 belongs to multiple VPNs.";
5920 }
5921 identity site-vpn-flavor-sub {
5922 base site-vpn-flavor;
5923 description
5924 "Base identity for the site VPN service flavor.
5925 Used when a site has multiple logical connections.
5926 Each connection may belong to different multiple VPNs.";
5927 }
5928 identity site-vpn-flavor-nni {
5929 base site-vpn-flavor;
5930 description
5931 "Base identity for the site VPN service flavor.
5932 Used to describe an NNI option A connection.";
5933 }
5934 identity management {
5935 description
5936 "Base identity for site management scheme.";
5937 }
5938 identity co-managed {
5939 base management;
5940 description
5941 "Base identity for co-managed site.";
5942 }
5943 identity customer-managed {
5944 base management;
5945 description
5946 "Base identity for customer-managed site.";
5947 }
5948 identity provider-managed {
5949 base management;
5950 description
5951 "Base identity for provider-managed site.";
5952 }
5953 identity address-allocation-type {
5954 description
5955 "Base identity for address-allocation-type for PE-CE link.";
5956 }
5957 identity provider-dhcp {
5958 base address-allocation-type;
5959 description
5960 "Provider network provides DHCP service to customer.";
5961 }
5962 identity provider-dhcp-relay {
5963 base address-allocation-type;
5964 description
5965 "Provider network provides DHCP relay service to customer.";
5967 }
5968 identity provider-dhcp-slaac {
5969 base address-allocation-type;
5970 description
5971 "Provider network provides DHCP service to customer,
5972 as well as SLAAC.";
5973 }
5974 identity static-address {
5975 base address-allocation-type;
5976 description
5977 "Provider-to-customer addressing is static.";
5978 }
5979 identity slaac {
5980 base address-allocation-type;
5981 description
5982 "Use IPv6 SLAAC.";
5983 }
5984 identity site-role {
5985 description
5986 "Base identity for site type.";
5987 }
5988 identity any-to-any-role {
5989 base site-role;
5990 description
5991 "Site in an any-to-any IP VPN.";
5992 }
5993 identity spoke-role {
5994 base site-role;
5995 description
5996 "Spoke site in a Hub-and-Spoke IP VPN.";
5997 }
5998 identity hub-role {
5999 base site-role;
6000 description
6001 "Hub site in a Hub-and-Spoke IP VPN.";
6002 }
6003 identity vpn-topology {
6004 description
6005 "Base identity for VPN topology.";
6006 }
6007 identity any-to-any {
6008 base vpn-topology;
6009 description
6010 "Identity for any-to-any VPN topology.";
6011 }
6012 identity hub-spoke {
6013 base vpn-topology;
6014 description
6016 "Identity for Hub-and-Spoke VPN topology.";
6017 }
6018 identity hub-spoke-disjoint {
6019 base vpn-topology;
6020 description
6021 "Identity for Hub-and-Spoke VPN topology
6022 where Hubs cannot communicate with each other.";
6023 }
6024 identity multicast-tree-type {
6025 description
6026 "Base identity for multicast tree type.";
6027 }
6028 identity ssm-tree-type {
6029 base multicast-tree-type;
6030 description
6031 "Identity for SSM tree type.";
6032 }
6033 identity asm-tree-type {
6034 base multicast-tree-type;
6035 description
6036 "Identity for ASM tree type.";
6037 }
6038 identity bidir-tree-type {
6039 base multicast-tree-type;
6040 description
6041 "Identity for bidirectional tree type.";
6042 }
6043 identity multicast-rp-discovery-type {
6044 description
6045 "Base identity for RP discovery type.";
6046 }
6047 identity auto-rp {
6048 base multicast-rp-discovery-type;
6049 description
6050 "Base identity for Auto-RP discovery type.";
6051 }
6052 identity static-rp {
6053 base multicast-rp-discovery-type;
6054 description
6055 "Base identity for static type.";
6056 }
6057 identity bsr-rp {
6058 base multicast-rp-discovery-type;
6059 description
6060 "Base identity for BSR discovery type.";
6061 }
6062 identity routing-protocol-type {
6063 description
6065 "Base identity for routing protocol type.";
6066 }
6067 identity ospf {
6068 base routing-protocol-type;
6069 description
6070 "Identity for OSPF protocol type.";
6071 }
6072 identity bgp {
6073 base routing-protocol-type;
6074 description
6075 "Identity for BGP protocol type.";
6076 }
6077 identity static {
6078 base routing-protocol-type;
6079 description
6080 "Identity for static routing protocol type.";
6081 }
6082 identity rip {
6083 base routing-protocol-type;
6084 description
6085 "Identity for RIP protocol type.";
6086 }
6087 identity vrrp {
6088 base routing-protocol-type;
6089 description
6090 "Identity for VRRP protocol type.
6091 This is to be used when LANs are directly connected
6092 to PE routers.";
6093 }
6094 identity direct {
6095 base routing-protocol-type;
6096 description
6097 "Identity for direct protocol type.";
6098 }
6099 identity protocol-type {
6100 description
6101 "Base identity for protocol field type.";
6102 }
6103 identity tcp {
6104 base protocol-type;
6105 description
6106 "TCP protocol type.";
6107 }
6108 identity udp {
6109 base protocol-type;
6110 description
6111 "UDP protocol type.";
6112 }
6114 identity icmp {
6115 base protocol-type;
6116 description
6117 "ICMP protocol type.";
6118 }
6119 identity icmp6 {
6120 base protocol-type;
6121 description
6122 "ICMPv6 protocol type.";
6123 }
6124 identity gre {
6125 base protocol-type;
6126 description
6127 "GRE protocol type.";
6128 }
6129 identity ipip {
6130 base protocol-type;
6131 description
6132 "IP-in-IP protocol type.";
6133 }
6134 identity hop-by-hop {
6135 base protocol-type;
6136 description
6137 "Hop-by-Hop IPv6 header type.";
6138 }
6139 identity routing {
6140 base protocol-type;
6141 description
6142 "Routing IPv6 header type.";
6143 }
6144 identity esp {
6145 base protocol-type;
6146 description
6147 "ESP header type.";
6148 }
6149 identity ah {
6150 base protocol-type;
6151 description
6152 "AH header type.";
6153 }
6154 identity vpn-policy-filter-type {
6155 description
6156 "Base identity for VPN Policy filter type.";
6157 }
6158 identity ipv4 {
6159 base vpn-policy-filter-type;
6160 description
6161 "Identity for ipv4 prefix filter type.";
6163 }
6164 identity ipv6 {
6165 base vpn-policy-filter-type;
6166 description
6167 "Identity for ipv6 prefix filter type.";
6168 }
6169 identity lan {
6170 base vpn-policy-filter-type;
6171 description
6172 "Identity for lan tag filter type.";
6173 }
6175 identity qos-profile-direction {
6176 description
6177 "Base identity for qos profile direction.";
6178 }
6180 identity site-to-wan {
6181 base qos-profile-direction;
6182 description
6183 "Identity for Site to WAN direction.";
6185 }
6186 identity wan-to-site {
6187 base qos-profile-direction;
6188 description
6189 "Identity for WAN to Site direction.";
6190 }
6191 identity both {
6192 base qos-profile-direction;
6193 description
6194 "Identity for both WAN to Site direction and Site to WAN direction.";
6195 }
6196 /* Groupings */
6197 grouping vpn-service-cloud-access {
6198 container cloud-accesses {
6199 if-feature cloud-access;
6200 list cloud-access {
6201 key cloud-identifier;
6202 leaf cloud-identifier {
6203 type leafref {
6204 path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers/"+
6205 "cloud-identifier/id";
6206 }
6207 description
6208 "Identification of cloud service.
6209 Local administration meaning.";
6210 }
6211 choice list-flavor {
6212 case permit-any {
6213 leaf permit-any {
6214 type empty;
6215 description
6216 "Allows all sites.";
6218 }
6219 }
6220 case deny-any-except {
6221 leaf-list permit-site {
6222 type leafref {
6223 path "/l3vpn-svc/sites/site/site-id";
6224 }
6225 description
6226 "Site ID to be authorized.";
6227 }
6228 }
6229 case permit-any-except {
6230 leaf-list deny-site {
6231 type leafref {
6232 path "/l3vpn-svc/sites/site/site-id";
6233 }
6234 description
6235 "Site ID to be denied.";
6236 }
6237 }
6238 description
6239 "Choice for cloud access policy. By default, all sites in the IP
6240 VPN MUST be authorized to access the cloud.";
6241 }
6242 container address-translation {
6243 container nat44 {
6244 leaf enabled {
6245 type boolean;
6246 default false;
6247 description
6248 "Controls whether or not Network address
6249 translation from IPv4 to IPv4 (NAT44)
6250 [RFC3022]is required.";
6251 }
6252 leaf nat44-customer-address {
6253 type inet:ipv4-address;
6254 description
6255 "Address to be used for network address
6256 translation from IPv4 to IPv4. This is
6257 to be used if the customer is providing
6258 the IPv4 address. If customer address
6259 is not set, the model assumes that the
6260 provider will allocate the address.";
6261 }
6262 description
6263 "IPv4-to-IPv4 translation.";
6264 }
6265 description
6266 "Container for NAT.";
6268 }
6269 description
6270 "Cloud access configuration.";
6271 }
6272 description
6273 "Container for cloud access configurations.";
6274 }
6275 description
6276 "Grouping for VPN cloud definition.";
6277 }
6278 grouping multicast-rp-group-cfg {
6279 choice group-format {
6280 mandatory true;
6281 case singleaddress {
6282 leaf group-address {
6283 type inet:ip-address;
6285 description
6286 "A Single Multicast Group address.";
6287 }
6288 }
6289 case startend {
6290 leaf group-start {
6291 type inet:ip-address;
6292 description
6293 "The first Multicast group address in
6294 the multicast group address range.";
6295 }
6296 leaf group-end {
6297 type inet:ip-address;
6298 description
6299 "The last Multicast group address in
6300 the multicast group address range.";
6301 }
6302 }
6303 description
6304 "Choice for Multicast group format.";
6305 }
6306 description
6307 "This Grouping defines Multicast Group or
6308 Multicast Groups for RP-to-group mapping.";
6309 }
6310 grouping vpn-service-multicast {
6311 container multicast {
6312 if-feature multicast;
6313 leaf enabled {
6314 type boolean;
6315 default false;
6317 description
6318 "Enables multicast.";
6319 }
6320 container customer-tree-flavors {
6321 leaf-list tree-flavor {
6322 type identityref {
6323 base multicast-tree-type;
6324 }
6325 description
6326 "Type of tree to be used.";
6327 }
6328 description
6329 "Type of trees used by customer.";
6330 }
6331 container rp {
6332 container rp-group-mappings {
6333 list rp-group-mapping {
6335 key id;
6336 leaf id {
6337 type uint16;
6338 description
6339 "Unique identifier for the mapping.";
6340 }
6341 container provider-managed {
6342 leaf enabled {
6343 type boolean;
6344 default false;
6345 description
6346 "Set to true if the Rendezvous Point (RP)
6347 must be a provider-managed node. Set to false
6348 if it is a customer-managed node.";
6349 }
6350 leaf rp-redundancy {
6351 type boolean;
6352 default false;
6353 description
6354 "If true, a redundancy mechanism for the RP
6355 is required.";
6356 }
6357 leaf optimal-traffic-delivery {
6358 type boolean;
6359 default false;
6360 description
6361 "If true, the SP must ensure that
6362 traffic uses an optimal path, an SP may use
6363 Anycast RP or RP tree to SPT switchover
6364 architectures.";
6366 }
6367 description
6368 "Parameters for a provider-managed RP.";
6369 }
6370 leaf rp-address {
6371 when "../provider-managed/enabled = 'false'" {
6372 description
6373 "Relevant when the RP is not provider-managed.";
6374 }
6375 type inet:ip-address;
6376 mandatory true;
6377 description
6378 "Defines the address of the RP.
6379 Used if the RP is customer-managed.";
6380 }
6381 container groups {
6382 list group {
6383 key id;
6385 leaf id {
6386 type uint16;
6387 description
6388 "Identifier for the group.";
6389 }
6390 uses multicast-rp-group-cfg;
6391 description
6392 "List of Multicast groups.";
6393 }
6394 description
6395 "Multicast groups associated with the RP.";
6396 }
6397 description
6398 "List of RP to group mappings.";
6399 }
6400 description
6401 "RP to group mappings parameters.";
6402 }
6403 container rp-discovery {
6404 leaf rp-discovery-type {
6405 type identityref {
6406 base multicast-rp-discovery-type;
6407 }
6408 default static-rp;
6409 description
6410 "Type of RP discovery used.";
6411 }
6412 container bsr-candidates {
6413 when "derived-from-or-self(../rp-discovery-type, 'l3vpn-svc:bsr-rp')" {
6415 description
6416 "Only applicable if discovery type is BSR-RP.";
6417 }
6418 leaf-list bsr-candidate-address {
6419 type inet:ip-address;
6420 description
6421 "Address of BSR candidate.";
6422 }
6423 description
6424 "Container for List of Customer BSR candidate's addresses.";
6425 }
6426 description
6427 "RP discovery parameters.";
6428 }
6429 description
6430 "RP parameters.";
6431 }
6432 description
6433 "Multicast global parameters for the VPN service.";
6434 }
6435 description
6436 "Grouping for multicast VPN definition.";
6437 }
6438 grouping vpn-service-mpls {
6439 leaf carrierscarrier {
6440 if-feature carrierscarrier;
6441 type boolean;
6442 default false;
6443 description
6444 "The VPN is using CsC, and so MPLS is required.";
6445 }
6446 description
6447 "Grouping for MPLS CsC definition.";
6448 }
6449 grouping customer-location-info {
6450 container locations {
6451 list location {
6452 key location-id;
6453 leaf location-id {
6454 type svc-id;
6455 description
6456 "Identifier for a particular location.";
6457 }
6458 leaf address {
6459 type string;
6460 description
6461 "Address (number and street) of the site.";
6463 }
6464 leaf postal-code {
6465 type string;
6466 description
6467 "Postal code of the site.";
6468 }
6469 leaf state {
6470 type string;
6471 description
6472 "State of the site. This leaf can also be used to describe
6473 a region for a country that does not have states.";
6474 }
6475 leaf city {
6476 type string;
6477 description
6478 "City of the site.";
6479 }
6480 leaf country-code {
6481 type string {
6482 pattern '[A-Z]{2}';
6484 }
6485 description
6486 "Country of the site.
6487 Expressed as ISO ALPHA-2 code.";
6488 }
6489 description
6490 "Location of the site.";
6491 }
6492 description
6493 "List of locations for the site.";
6494 }
6495 description
6496 "This grouping defines customer location parameters.";
6497 }
6498 grouping site-group {
6499 container groups {
6500 list group {
6501 key group-id;
6502 leaf group-id {
6503 type string;
6504 description
6505 "Group-id the site belongs to.";
6507 }
6508 description
6509 "List of group-ids.";
6510 }
6511 description
6513 "Groups the site or site-network-access belongs to.";
6514 }
6515 description
6516 "Grouping definition to assign
6517 group-ids to site or site-network-access.";
6518 }
6519 grouping site-diversity {
6520 container site-diversity {
6521 if-feature site-diversity;
6522 uses site-group;
6523 description
6524 "Diversity constraint type.
6525 All site-network-accesses will inherit the group values
6526 defined here.";
6527 }
6528 description
6529 "This grouping defines site diversity parameters.";
6530 }
6531 grouping access-diversity {
6532 container access-diversity {
6533 if-feature site-diversity;
6535 uses site-group;
6536 container constraints {
6537 list constraint {
6538 key constraint-type;
6539 leaf constraint-type {
6540 type identityref {
6541 base placement-diversity;
6542 }
6543 description
6544 "Diversity constraint type.";
6545 }
6546 container target {
6547 choice target-flavor {
6548 default id;
6549 case id {
6550 list group {
6551 key group-id;
6552 leaf group-id {
6553 type string;
6554 description
6555 "The constraint will be applied against
6556 this particular group-id for this site network access level.";
6557 }
6558 description
6559 "List of group-ids associated with one specific
6560 constraint for this site network access level.";
6562 }
6563 }
6564 case all-accesses {
6565 leaf all-other-accesses {
6566 type empty;
6567 description
6568 "The constraint will be applied against
6569 all other site network accesses of this site.";
6570 }
6571 }
6572 case all-groups {
6573 leaf all-other-groups {
6574 type empty;
6575 description
6576 "The constraint will be applied against
6577 all other groups managed by the customer.";
6578 }
6579 }
6580 description
6581 "Choice for the target flavor definition.";
6582 }
6583 description
6585 "The constraint will be applied against
6586 Specific target, and the target can be a list
6587 of group-ids,all other site network accesses of
6588 this site or all other groups managed by the
6589 customer.";
6590 }
6591 description
6592 "List of constraints.";
6593 }
6594 description
6595 "Placement constraints for this site network access.";
6596 }
6597 description
6598 "Diversity parameters.";
6599 }
6600 description
6601 "This grouping defines access diversity parameters.";
6602 }
6603 grouping operational-requirements {
6604 leaf requested-site-start {
6605 type yang:date-and-time;
6606 description
6607 "Optional leaf indicating requested date and time when the
6608 service at a particular site is expected to start.";
6609 }
6611 leaf requested-site-stop {
6612 type yang:date-and-time;
6613 description
6614 "Optional leaf indicating requested date and time when the
6615 service at a particular site is expected to stop.";
6616 }
6617 description
6618 "This grouping defines some operational parameters.";
6619 }
6620 grouping operational-requirements-ops {
6621 leaf actual-site-start {
6622 type yang:date-and-time;
6623 config false;
6624 description
6625 "Optional leaf indicating actual date and time when the
6626 service at a particular site actually started.";
6627 }
6628 leaf actual-site-stop {
6629 type yang:date-and-time;
6630 config false;
6631 description
6632 "Optional leaf indicating actual date and time when the
6633 service at a particular site actually stopped.";
6635 }
6636 description
6637 "This grouping defines some operational parameters.";
6638 }
6639 grouping flow-definition {
6640 container match-flow {
6641 leaf dscp {
6642 type inet:dscp;
6643 description
6644 "DSCP value.";
6645 }
6646 leaf dot1p {
6647 type uint8 {
6648 range "0..7";
6649 }
6650 description
6651 "802.1p matching.";
6652 }
6653 leaf ipv4-src-prefix {
6654 type inet:ipv4-prefix;
6655 description
6656 "Match on IPv4 src address.";
6657 }
6658 leaf ipv6-src-prefix {
6659 type inet:ipv6-prefix;
6660 description
6661 "Match on IPv6 src address.";
6662 }
6663 leaf ipv4-dst-prefix {
6664 type inet:ipv4-prefix;
6665 description
6666 "Match on IPv4 dst address.";
6667 }
6668 leaf ipv6-dst-prefix {
6669 type inet:ipv6-prefix;
6670 description
6671 "Match on IPv6 dst address.";
6672 }
6673 leaf l4-src-port {
6674 type inet:port-number;
6675 must "current() < ../l4-src-port-range/lower-port or "+
6676 "current() > ../l4-src-port-range/upper-port" {
6677 description
6678 "If l4-src-port and l4-src-port-range/lower-port and
6679 upper-port are set at the same time, l4-src-port
6680 should not overlap with l4-src-port-range. ";
6681 }
6682 description
6683 "Match on Layer 4 src port.";
6684 }
6685 leaf-list target-sites {
6686 if-feature target-sites;
6687 type svc-id;
6688 description
6689 "Identify a site as traffic destination.";
6690 }
6691 container l4-src-port-range {
6692 leaf lower-port {
6693 type inet:port-number;
6694 description
6695 "Lower boundary for port.";
6696 }
6697 leaf upper-port {
6698 type inet:port-number;
6699 must ". >= ../lower-port" {
6700 description
6701 " Upper boundary for port. If it
6702 exists, upper boundary must be
6703 higher than lower boundary.";
6704 }
6705 description
6706 "Upper boundary for port.";
6707 }
6708 description
6709 "Match on Layer 4 src port range. When only lower-port
6710 is present, it represents a single port. When both
6711 lower-port and upper-port are specified, it implies
6712 a range inclusive of both values.";
6713 }
6714 leaf l4-dst-port {
6715 type inet:port-number;
6716 must "current() < ../l4-dst-port-range/lower-port or "+
6717 "current() > ../l4-dst-port-range/upper-port" {
6718 description
6719 " If l4-dst-port and l4-dst-port-range/lower-port and
6720 upper-port are set at the same time, l4-dst-port
6721 should not overlap with l4-src-port-range. ";
6722 }
6723 description
6724 "Match on Layer 4 dst port.";
6725 }
6726 container l4-dst-port-range {
6727 leaf lower-port {
6728 type inet:port-number;
6729 description
6730 "Lower boundary for port.";
6731 }
6732 leaf upper-port {
6733 type inet:port-number;
6734 must ". >= ../lower-port" {
6735 description
6736 "Upper boundary must be
6737 higher than lower boundary.";
6738 }
6739 description
6740 "Upper boundary for port. If it exists, upper boundary
6741 must be higher than lower boundary.";
6742 }
6743 description
6744 "Match on Layer 4 dst port range. When only lower-port is
6745 present, it represents a single port. When both lower-port
6746 and upper-port are specified, it implies a range inclusive
6747 of both values.";
6748 }
6749 leaf protocol-field {
6750 type union {
6751 type uint8;
6752 type identityref {
6753 base protocol-type;
6754 }
6755 }
6756 description
6757 "Match on IPv4 protocol or IPv6 Next Header field.";
6758 }
6759 description
6760 "Describes flow-matching criteria.";
6761 }
6762 description
6763 "Flow definition based on criteria.";
6764 }
6765 grouping site-service-basic {
6766 leaf svc-input-bandwidth {
6767 type uint64;
6768 units bps;
6769 mandatory true;
6770 description
6771 "From the customer site's perspective, the service
6772 input bandwidth of the connection or download
6773 bandwidth from the SP to the site.";
6774 }
6775 leaf svc-output-bandwidth {
6776 type uint64;
6778 units bps;
6779 mandatory true;
6780 description
6781 "From the customer site's perspective, the service
6782 output bandwidth of the connection or upload
6783 bandwidth from the site to the SP.";
6784 }
6785 leaf svc-mtu {
6786 type uint16;
6787 units bytes;
6788 mandatory true;
6789 description
6790 "MTU at service level. If the service is IP,
6791 it refers to the IP MTU. If CsC is enabled,
6792 the requested 'svc-mtu' leaf will refer to the
6793 MPLS MTU and not to the IP MTU. ";
6794 }
6795 description
6796 "Defines basic service parameters for a site.";
6797 }
6798 grouping site-protection {
6799 container traffic-protection {
6800 if-feature fast-reroute;
6801 leaf enabled {
6802 type boolean;
6803 default false;
6805 description
6806 "Enables traffic protection of access link.";
6807 }
6808 description
6809 "Fast Reroute service parameters for the site.";
6810 }
6811 description
6812 "Defines protection service parameters for a site.";
6813 }
6814 grouping site-service-mpls {
6815 container carrierscarrier {
6816 if-feature carrierscarrier;
6817 leaf signalling-type {
6818 type enumeration {
6819 enum ldp {
6820 description
6821 "Use LDP as the signalling protocol
6822 between the PE and the CE. In this case,
6823 an IGP routing protocol must also be activated. ";
6824 }
6825 enum bgp {
6827 description
6828 "Use BGP (as per RFC 3107) as the signalling protocol
6829 between the PE and the CE.
6830 In this case, BGP must also be configured as
6831 the routing protocol.";
6832 }
6833 }
6834 default bgp;
6835 description
6836 "MPLS signalling type.";
6837 }
6838 description
6839 "This container is used when the customer provides
6840 MPLS-based services. This is only used in the case
6841 of CsC(i.e., a customer builds an MPLS service using
6842 an IP VPN to carry its traffic.";
6844 }
6845 description
6846 "Defines MPLS service parameters for a site.";
6847 }
6848 grouping site-service-qos-profile {
6849 container qos {
6850 if-feature qos;
6851 container qos-classification-policy {
6852 list rule {
6853 key id;
6854 ordered-by user;
6855 leaf id {
6856 type string;
6857 description
6858 "A description identifying qos classification
6859 policy rule.";
6860 }
6861 choice match-type {
6862 default match-flow;
6863 case match-flow {
6864 uses flow-definition;
6865 }
6866 case match-application {
6867 leaf match-application {
6868 type identityref {
6869 base customer-application;
6870 }
6871 description
6872 "Defines the application to match.";
6873 }
6874 }
6876 description
6877 "Choice for classification.";
6878 }
6879 leaf target-class-id {
6880 type string;
6881 description
6882 "Identification of the class of service.
6883 This identifier is internal to the administration.";
6884 }
6885 description
6886 "List of marking rules.";
6887 }
6888 description
6889 "Configuration of the traffic classification policy.";
6890 }
6891 container qos-profile {
6892 choice qos-profile {
6893 description
6894 "Choice for QoS profile.
6895 Can be standard profile or customized profile.";
6896 case standard {
6897 description "Standard QoS profile.";
6898 leaf profile {
6899 type leafref {
6900 path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers/qos-profile-identifier/id";
6901 }
6902 description
6904 "QoS profile to be used.";
6905 }
6906 }
6907 case custom {
6908 description "Customized QoS profile.";
6909 container classes {
6910 if-feature qos-custom;
6911 list class {
6912 key class-id;
6913 leaf class-id {
6914 type string;
6915 description
6916 "Identification of the class of service.
6917 This identifier is internal to the administration.";
6918 }
6919 leaf direction {
6920 type identityref {
6921 base qos-profile-direction;
6922 }
6923 default both;
6924 description
6925 "The direction which QoS profile is applied to";
6926 }
6928 leaf rate-limit {
6929 type uint8 {
6930 range "0..100";
6931 }
6932 units percent;
6933 description
6934 "To be used if the class must be rate-limited.
6935 Expressed as percentage of the service bandwidth.";
6936 }
6937 container latency {
6938 choice flavor {
6939 case lowest {
6940 leaf use-lowest-latency {
6941 type empty;
6942 description
6943 "The traffic class should use the path with the
6944 lowest latency.";
6945 }
6946 }
6947 case boundary {
6948 leaf latency-boundary {
6949 type uint16;
6950 units msec;
6951 default 400;
6952 description
6953 "The traffic class should use a path with a
6954 defined maximum latency.";
6955 }
6956 }
6957 description
6958 "Latency constraint on the traffic class.";
6959 }
6960 description
6961 "Latency constraint on the traffic class.";
6962 }
6964 container jitter {
6965 choice flavor {
6966 case lowest {
6967 leaf use-lowest-jitter {
6968 type empty;
6969 description
6970 "The traffic class should use the path with the
6971 lowest jitter.";
6972 }
6973 }
6974 case boundary {
6975 leaf latency-boundary {
6976 type uint32;
6977 units usec;
6978 default 40000;
6979 description
6980 "The traffic class should use a path with a
6981 defined maximum jitter.";
6982 }
6983 }
6984 description
6985 "Jitter constraint on the traffic class.";
6986 }
6987 description
6988 "Jitter constraint on the traffic class.";
6989 }
6990 container bandwidth {
6991 leaf guaranteed-bw-percent {
6992 type uint8 {
6993 range "0..100";
6994 }
6995 units percent;
6996 mandatory true;
6997 description
6998 "To be used to define the guaranteed bandwidth
6999 as a percentage of the available service bandwidth.";
7000 }
7001 leaf end-to-end {
7002 type empty;
7003 description
7004 "Used if the bandwidth reservation
7005 must be done on the MPLS network too.";
7006 }
7007 description
7008 "Bandwidth constraint on the traffic class.";
7009 }
7010 description
7011 "List of classes of services.";
7012 }
7013 description
7014 "Container for list of classes of services.";
7015 }
7016 }
7017 }
7018 description
7019 "QoS profile configuration.";
7020 }
7021 description
7022 "QoS configuration.";
7023 }
7024 description
7025 "This grouping defines QoS parameters for a site.";
7026 }
7027 grouping site-security-authentication {
7028 container authentication {
7029 description
7030 "Authentication parameters.";
7031 }
7032 description
7033 "This grouping defines authentication parameters for a site.";
7034 }
7035 grouping site-security-encryption {
7036 container encryption {
7037 if-feature encryption;
7038 leaf enabled {
7039 type boolean;
7040 default false;
7041 description
7042 "If true, traffic encryption on the connection is required.";
7043 }
7044 leaf layer {
7045 when "../enabled = 'true'" {
7046 description
7047 " Require a value for layer when enabled is true.";
7048 }
7049 type enumeration {
7050 enum layer2 {
7051 description
7052 "Encryption will occur at Layer 2.";
7053 }
7054 enum layer3 {
7055 description
7056 "Encryption will occur at Layer 3.
7057 For example, IPsec may be used when a customer requests Layer 3 encryption.";
7058 }
7059 }
7060 description
7061 "Layer on which encryption is applied.";
7062 }
7063 container encryption-profile {
7064 choice profile {
7065 case provider-profile {
7066 leaf profile-name {
7067 type leafref {
7068 path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers/encryption-profile-identifier/id";
7069 }
7070 description
7071 "Name of the SP profile to be applied.";
7073 }
7074 }
7075 case customer-profile {
7076 leaf algorithm {
7077 type string;
7078 description
7079 "Encryption algorithm to be used.";
7080 }
7081 choice key-type {
7082 default psk;
7083 case psk {
7084 leaf preshared-key {
7085 type string;
7086 description
7087 " Pre-Shared Key(PSK) coming from customer.";
7088 }
7089 }
7090 description
7091 "Type of keys to be used.";
7092 }
7093 }
7094 description
7095 "Choice of encryption profile, the encryption
7096 profile can be provider profile or customer profile.";
7097 }
7098 description
7099 "Profile of encryption to be applied.";
7100 }
7101 description
7102 "Encryption parameters.";
7103 }
7104 description
7105 "This grouping defines encryption parameters for a site.";
7106 }
7107 grouping site-attachment-bearer {
7108 container bearer {
7109 container requested-type {
7110 if-feature requested-type;
7111 leaf requested-type {
7112 type string;
7114 description
7115 "Type of requested bearer: Ethernet, DSL,
7116 Wireless, etc. Operator specific.";
7117 }
7118 leaf strict {
7119 type boolean;
7120 default false;
7122 description
7123 "Defines whether requested-type is a preference
7124 or a strict requirement.";
7125 }
7126 description
7127 "Container for requested-type.";
7128 }
7129 leaf always-on {
7130 if-feature always-on;
7131 type boolean;
7132 default true;
7133 description
7134 "Request for an always-on access type.
7135 For example, this could mean no dial access type.";
7136 }
7137 leaf bearer-reference {
7138 if-feature bearer-reference;
7139 type string;
7140 description
7141 "This is an internal reference for the SP.";
7142 }
7143 description
7144 "Bearer-specific parameters.
7145 To be augmented.";
7146 }
7147 description
7148 "Defines physical properties of a site attachment.";
7149 }
7150 grouping site-routing {
7151 container routing-protocols {
7152 list routing-protocol {
7153 key type;
7154 leaf type {
7155 type identityref {
7156 base routing-protocol-type;
7157 }
7158 description
7159 "Type of routing protocol.";
7160 }
7161 container ospf {
7162 when "derived-from-or-self(../type, 'l3vpn-svc:ospf')" {
7163 description
7164 "Only applies when protocol is OSPF.";
7165 }
7166 if-feature rtg-ospf;
7167 leaf-list address-family {
7168 type address-family;
7170 min-elements "1";
7171 description
7172 "If OSPF is used on this site, this node
7173 contains configured value. This node
7174 contains at least one address family
7175 to be activated.";
7176 }
7177 leaf area-address {
7178 type yang:dotted-quad;
7179 mandatory true;
7180 description
7181 "Area address.";
7182 }
7183 leaf metric {
7184 type uint16;
7185 default 1;
7186 description
7187 "Metric of the PE-CE link. It is used
7188 in the routing state calculation and
7189 path selection. The default value is
7190 set to 1 assigned to the PE-CE link.";
7191 }
7192 container sham-links {
7193 if-feature rtg-ospf-sham-link;
7194 list sham-link {
7195 key target-site;
7196 leaf target-site {
7197 type svc-id;
7198 description
7199 "Target site for the sham link connection.
7200 The site is referred to by its ID.";
7201 }
7202 leaf metric {
7203 type uint16;
7204 default 1;
7205 description
7206 "Metric of the sham link. It is used in
7207 the routing state calculation and path
7208 selection. The default value is set
7209 to 1.";
7210 }
7211 description
7212 "Creates a sham link with another site.";
7213 }
7214 description
7215 "List of sham links.";
7216 }
7218 description
7219 "OSPF-specific configuration.";
7220 }
7221 container bgp {
7222 when "derived-from-or-self(../type, 'l3vpn-svc:bgp')" {
7223 description
7224 "Only applies when protocol is BGP.";
7225 }
7226 if-feature rtg-bgp;
7227 leaf autonomous-system {
7228 type uint32;
7229 mandatory true;
7230 description
7231 "Customer AS number in case the customer
7232 requests BGP routing.";
7233 }
7234 leaf-list address-family {
7235 type address-family;
7236 min-elements "1";
7237 description
7238 "If BGP is used on this site, this node
7239 contains configured value. This node
7240 contains at least one address family
7241 to be activated.";
7242 }
7243 description
7244 "BGP-specific configuration.";
7245 }
7246 container static {
7247 when "derived-from-or-self(../type, 'l3vpn-svc:static')" {
7248 description
7249 "Only applies when protocol is static.
7250 BGP activation requires the SP to know
7251 the address of the customer peer. When
7252 BGP is enabled, the 'static-address'
7253 allocation type for the IP connection
7254 MUST be used.";
7255 }
7256 container cascaded-lan-prefixes {
7257 list ipv4-lan-prefixes {
7258 if-feature ipv4;
7259 key "lan next-hop";
7260 leaf lan {
7262 type inet:ipv4-prefix;
7263 description
7264 "LAN prefixes.";
7265 }
7267 leaf lan-tag {
7268 type string;
7269 description
7270 "Internal tag to be used in VPN policies.";
7271 }
7272 leaf next-hop {
7273 type inet:ipv4-address;
7274 description
7275 "Next-hop address to use on the customer side.";
7277 }
7278 description
7279 "List of LAN prefixes for the site.";
7280 }
7281 list ipv6-lan-prefixes {
7282 if-feature ipv6;
7283 key "lan next-hop";
7284 leaf lan {
7285 type inet:ipv6-prefix;
7286 description
7287 "LAN prefixes.";
7288 }
7289 leaf lan-tag {
7290 type string;
7291 description
7292 "Internal tag to be used in VPN policies.";
7293 }
7294 leaf next-hop {
7295 type inet:ipv6-address;
7296 description
7297 "Next-hop address to use on the customer side.";
7298 }
7299 description
7300 "List of LAN prefixes for the site.";
7301 }
7302 description
7303 "LAN prefixes from the customer.";
7304 }
7305 description
7306 "Configuration specific to static routing.";
7307 }
7308 container rip {
7309 when "derived-from-or-self(../type, 'l3vpn-svc:rip')" {
7310 description
7311 "Only applies when protocol is RIP. For IPv4,
7312 the model assumes that RIP version 2 is used.";
7313 }
7314 if-feature rtg-rip;
7316 leaf-list address-family {
7317 type address-family;
7318 min-elements "1";
7319 description
7320 "If RIP is used on this site, this node
7321 contains configured value.This node
7322 contains at least one address family
7323 to be activated.";
7324 }
7325 description
7326 "Configuration specific to RIP routing.";
7327 }
7328 container vrrp {
7329 when "derived-from-or-self(../type, 'l3vpn-svc:vrrp')" {
7330 description
7331 "Only applies when protocol is VRRP.";
7332 }
7333 if-feature rtg-vrrp;
7334 leaf-list address-family {
7335 type address-family;
7336 min-elements "1";
7337 description
7338 "If VRRP is used on this site, this node
7339 contains configured value. This node contains
7340 at least one address family to be activated. ";
7341 }
7342 description
7343 "Configuration specific to VRRP routing.";
7344 }
7345 description
7346 "List of routing protocols used on
7347 the site. This list can be augmented.";
7348 }
7349 description
7350 "Defines routing protocols.";
7351 }
7352 description
7353 "Grouping for routing protocols.";
7354 }
7355 grouping site-attachment-ip-connection {
7356 container ip-connection {
7357 container ipv4 {
7358 if-feature ipv4;
7359 leaf address-allocation-type {
7360 type identityref {
7361 base address-allocation-type;
7362 }
7363 must "not(derived-from-or-self(current(), 'l3vpn-svc:slaac') or "+
7364 "derived-from-or-self(current(), 'l3vpn-svc:provider-dhcp-slaac'))" {
7365 error-message "SLAAC is only applicable to IPv6";
7366 }
7367 description
7368 "Defines how addresses are allocated.
7369 If there is no value for address
7370 allocation type, then the ipv4 is not enabled.";
7371 }
7372 container provider-dhcp {
7373 when "derived-from-or-self(../address-allocation-type, 'l3vpn-svc:provider-dhcp')" {
7374 description
7375 "Only applies when addresses are allocated by DHCP.";
7376 }
7377 leaf provider-address {
7378 type inet:ipv4-address;
7379 description
7380 "Address of provider side. If provider-address is not specified,
7381 then mask should not be specified as well,it also implies
7382 provider-dhcp allocation is not enabled. If provider address
7383 is specified, then mask may or may not be specified. ";
7384 }
7385 leaf mask {
7386 type uint8 {
7387 range "0..31";
7388 }
7389 must "(../provider-address)" {
7390 error-message
7391 "if mask is specified, provider-address must also be specified.";
7392 description
7393 "if mask is specified, provider-address must also be specified.";
7394 }
7395 description
7396 "Subnet mask expressed in bits. If not specified, or specified as zero,
7397 this means the customer leaves the actual mask value to the provider.";
7398 }
7399 choice address-assign {
7400 default number;
7401 case number {
7402 leaf number-of-dynamic-address {
7403 type uint16;
7404 default 1;
7405 description
7406 "Describes the number of IP addresses the customer requires.";
7407 }
7408 }
7409 case explicit {
7410 container customer-addresses {
7411 list address-group {
7412 key "group-id";
7413 leaf group-id {
7414 type string;
7415 description
7416 "Group-id for the address range from start-address to end-address.";
7417 }
7418 leaf start-address {
7419 type inet:ipv4-address;
7420 description
7421 "First address.";
7422 }
7424 leaf end-address {
7425 type inet:ipv4-address;
7426 description
7427 "Last address.";
7428 }
7429 description
7430 "Describes IP addresses allocated by DHCP. When only start-address
7431 or only end-address is present, it represents a single address.
7432 When both start-address and end-address are specified, it implies
7433 a range inclusive of both addresses. If no address is specified,
7434 it implies customer addresses group is not supported. ";
7435 }
7436 description
7437 "Container for customer addresses allocated by DHCP.";
7438 }
7439 }
7440 description
7441 "Choice for the way to assign addresses.";
7442 }
7443 description
7444 "DHCP allocated addresses related parameters.";
7445 }
7446 container dhcp-relay {
7447 when "derived-from-or-self(../address-allocation-type, 'l3vpn-svc:provider-dhcp-relay')" {
7448 description
7449 "Only applies when provider is required to implement
7450 DHCP relay function.";
7451 }
7452 leaf provider-address {
7453 type inet:ipv4-address;
7454 description
7455 "Address of provider side. If provider-address is not specified,
7456 then mask should not be specified as well,it also implies
7457 provider-dhcp allocation is not enabled. If provider address
7458 is specified, then mask may or may not be specified.";
7459 }
7460 leaf mask {
7461 type uint8 {
7462 range "0..31";
7463 }
7464 must "(../provider-address)" {
7465 error-message
7466 "if mask is specified, provider-address must also be specified.";
7467 description
7468 "if mask is specified, provider-address must also be specified.";
7470 }
7471 description
7472 "Subnet mask expressed in bits. If not specified, or specified as zero,
7473 this means the customer leaves the actual mask value to the provider.";
7474 }
7476 container customer-dhcp-servers {
7477 leaf-list server-ip-address {
7478 type inet:ipv4-address;
7479 description
7480 "IP address of customer DHCP server.";
7481 }
7482 description
7483 "Container for list of customer DHCP servers.";
7484 }
7485 description
7486 "DHCP relay provided by operator.";
7487 }
7489 container addresses {
7490 when "derived-from-or-self(../address-allocation-type, 'l3vpn-svc:static-address')" {
7491 description
7492 "Only applies when protocol allocation type is static.";
7493 }
7494 leaf provider-address {
7495 type inet:ipv4-address;
7496 description
7497 "IPv4 Address List of provider side. When protocol
7498 allocation type is static, provider address must be configured.";
7499 }
7500 leaf customer-address {
7501 type inet:ipv4-address;
7502 description
7503 "IPv4 Address of customer side.";
7504 }
7505 leaf mask {
7506 type uint8 {
7507 range "0..31";
7508 }
7509 description
7510 "Subnet mask expressed in bits. It is applied to both
7511 provider-address and customer-address.";
7512 }
7513 description
7514 "Describes IPv4 addresses used.";
7515 }
7516 description
7517 "IPv4-specific parameters.";
7519 }
7520 container ipv6 {
7521 if-feature ipv6;
7522 leaf address-allocation-type {
7523 type identityref {
7524 base address-allocation-type;
7525 }
7526 description
7527 "Defines how addresses are allocated.
7528 If there is no value for address
7529 allocation type, then the ipv6 is
7530 not enabled.";
7531 }
7533 container provider-dhcp {
7534 when "derived-from-or-self(../address-allocation-type, 'l3vpn-svc:provider-dhcp') "+
7535 "or derived-from-or-self(../address-allocation-type, 'l3vpn-svc:provider-dhcp-slaac')" {
7536 description
7537 "Only applies when addresses are allocated by DHCP.";
7538 }
7539 leaf provider-address {
7540 type inet:ipv6-address;
7541 description
7542 "Address of provider side. If provider-address is not specified,
7543 then mask should not be specified as well,it also implies
7544 provider-dhcp allocation is not enabled. If provider address
7545 is specified, then mask may or may not be specified.";
7546 }
7547 leaf mask {
7548 type uint8 {
7549 range "0..127";
7550 }
7551 must "(../provider-address)" {
7552 error-message
7553 "if mask is specified, provider-address must also be specified.";
7554 description
7555 "if mask is specified, provider-address must also be specified.";
7556 }
7557 description
7558 "Subnet mask expressed in bits. If not specified, or specified as zero,
7559 this means the customer leaves the actual mask value to the provider.";
7560 }
7562 choice address-assign {
7563 default number;
7564 case number {
7565 leaf number-of-dynamic-address {
7566 type uint16;
7567 default 1;
7568 description
7569 "Describes the number of IP addresses the customer requires.";
7570 }
7571 }
7572 case explicit {
7573 container customer-addresses {
7574 list address-group {
7575 key "group-id";
7576 leaf group-id {
7577 type string;
7578 description
7579 "Group-id for the address range from start-address
7580 to end-address.";
7581 }
7582 leaf start-address {
7583 type inet:ipv6-address;
7584 description
7585 "First address.";
7586 }
7588 leaf end-address {
7589 type inet:ipv6-address;
7590 description
7591 "Last address.";
7592 }
7593 description
7594 "Describes IP addresses allocated by DHCP. When only
7595 start-address or only end-address is present, it
7596 represents a single address. When both start-address
7597 and end-address are specified, it implies a range
7598 inclusive of both addresses. If no address is specified,
7599 it implies customer addresses group is not supported.";
7600 }
7601 description
7602 "Container for customer addresses allocated by DHCP.";
7603 }
7604 }
7605 description
7606 "Choice for the way to assign addresses.";
7607 }
7608 description
7609 "DHCP allocated addresses related parameters.";
7610 }
7611 container dhcp-relay {
7612 when "derived-from-or-self(../address-allocation-type, 'l3vpn-svc:provider-dhcp-relay')" {
7613 description
7614 "Only applies when provider is required to implement
7615 DHCP relay function.";
7616 }
7617 leaf provider-address {
7618 type inet:ipv6-address;
7619 description
7620 "Address of provider side. If provider-address is not specified,
7621 then mask should not be specified as well,it also implies
7622 provider-dhcp allocation is not enabled. If provider address
7623 is specified, then mask may or may not be specified.";
7624 }
7625 leaf mask {
7626 type uint8 {
7627 range "0..127";
7628 }
7629 must "(../provider-address)" {
7630 error-message
7631 "if mask is specified, provider-address must also be specified.";
7632 description
7633 "if mask is specified, provider-address must also be specified.";
7634 }
7635 description
7636 "Subnet mask expressed in bits. If not specified, or specified as zero,
7637 this means the customer leaves the actual mask value to the provider.";
7638 }
7640 container customer-dhcp-servers {
7641 leaf-list server-ip-address {
7642 type inet:ipv6-address;
7643 description
7644 "This node contains IP address of
7645 customer DHCP server.If DHCP relay
7646 function is implemented by the
7647 provider, this node contains the
7648 configured value.";
7649 }
7650 description
7651 "Container for list of customer DHCP servers.";
7652 }
7653 description
7654 "DHCP relay provided by operator.";
7655 }
7657 container addresses {
7658 when "derived-from-or-self(../address-allocation-type, 'l3vpn-svc:static-address')" {
7659 description
7660 "Only applies when protocol allocation type is static.";
7661 }
7662 leaf provider-address {
7663 type inet:ipv6-address;
7664 description
7665 "IPv6 Address of provider side. When protocol
7666 allocation type is static, provider address must be configured.";
7667 }
7668 leaf customer-address {
7669 type inet:ipv6-address;
7670 description
7671 "IPv6 Address of customer side.";
7672 }
7673 leaf mask {
7674 type uint8 {
7675 range "0..127";
7676 }
7677 description
7678 "Subnet mask expressed in bits. It is applied to both provider-address and customer-address.";
7679 }
7680 description
7681 "Describes IPv6 addresses used.";
7682 }
7683 description
7684 "IPv6-specific parameters.";
7685 }
7686 container oam {
7687 container bfd {
7688 if-feature bfd;
7689 leaf enabled {
7690 type boolean;
7691 default false;
7692 description
7693 "If true, BFD activation is required.";
7694 }
7695 choice holdtime {
7696 default fixed;
7697 case fixed {
7698 leaf fixed-value {
7699 type uint32;
7700 units msec;
7701 description
7702 "Expected BFD holdtime expressed in msec. The customer
7703 may impose Some fixed values for the holdtime period if the
7704 provider allows the customer use this function.If the
7705 provider doesn't allow the customer use this function,
7706 the fixed-value will not be set.";
7707 }
7708 }
7709 case profile {
7710 leaf profile-name {
7711 type leafref {
7712 path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers/bfd-profile-identifier/id";
7713 }
7714 description
7715 "Well-known SP profile Name. The provider can propose some profiles
7716 to the customer, depending on the service level the customer wants
7717 to achieve. Profile names must be communicated to the customer";
7718 }
7719 description
7720 "Well-known SP profile.";
7721 }
7722 description
7723 "Choice for holdtime flavor.";
7724 }
7725 description
7726 "Container for BFD.";
7727 }
7728 description
7729 "Defines the OAM mechanisms used on the connection.
7730 BFD is set as a fault detection mechanism, but the 'oam' container
7731 can easily be augmented by other mechanisms";
7732 }
7733 description
7734 "Defines connection parameters.";
7735 }
7736 description
7737 "This grouping defines IP connection parameters.";
7738 }
7739 grouping site-service-multicast {
7740 container multicast {
7741 if-feature multicast;
7742 leaf multicast-site-type {
7743 type enumeration {
7745 enum receiver-only {
7746 description
7747 "The site only has receivers.";
7748 }
7749 enum source-only {
7750 description
7751 "The site only has sources.";
7752 }
7754 enum source-receiver {
7755 description
7756 "The site has both sources and receivers.";
7757 }
7758 }
7759 default source-receiver;
7760 description
7761 "Type of multicast site.";
7762 }
7763 container multicast-address-family {
7764 leaf ipv4 {
7765 if-feature ipv4;
7766 type boolean;
7767 default false;
7768 description
7769 "Enables IPv4 multicast.";
7770 }
7771 leaf ipv6 {
7772 if-feature ipv6;
7773 type boolean;
7774 default false;
7775 description
7776 "Enables IPv6 multicast.";
7777 }
7778 description
7779 "Defines protocol to carry multicast.";
7780 }
7781 leaf protocol-type {
7782 type enumeration {
7783 enum host {
7784 description
7785 "Hosts are directly connected to the provider network.
7786 Host protocols such as IGMP or MLD are required.";
7787 }
7788 enum router {
7789 description
7790 "Hosts are behind a customer router.
7791 PIM will be implemented.";
7792 }
7793 enum both {
7794 description
7795 "Some hosts are behind a customer router, and some others
7796 are directly connected to the provider network.
7797 Both host and routing protocols must be used.
7798 Typically, IGMP and PIM will be implemented.";
7799 }
7800 }
7801 default "both";
7803 description
7804 "Multicast protocol type to be used with the customer site.";
7805 }
7806 description
7807 "Multicast parameters for the site.";
7808 }
7809 description
7810 "Multicast parameters for the site.";
7811 }
7812 grouping site-management {
7813 container management {
7814 leaf type {
7815 type identityref {
7816 base management;
7817 }
7818 mandatory true;
7819 description
7820 "Management type of the connection.";
7821 }
7822 description
7823 "Management configuration.";
7824 }
7825 description
7826 "Management parameters for the site.";
7827 }
7828 grouping site-devices {
7829 container devices {
7830 when "derived-from-or-self(../management/type, 'l3vpn-svc:provider-managed') or "+
7831 "derived-from-or-self(../management/type, 'l3vpn-svc:co-managed')" {
7832 description
7833 "Applicable only for provider-managed or co-managed device.";
7834 }
7835 list device {
7836 key device-id;
7837 leaf device-id {
7838 type svc-id;
7839 description
7840 "Identifier for the device.";
7841 }
7842 leaf location {
7844 type leafref {
7845 path "../../../locations/"+
7846 "location/location-id";
7847 }
7848 mandatory true;
7849 description
7850 "Location of the device.";
7852 }
7853 container management {
7854 when "derived-from-or-self(../../../management/type,"+
7855 "'l3vpn-svc:co-managed')" {
7856 description
7857 "Applicable only for co-managed device.";
7858 }
7859 leaf address-family {
7860 type address-family;
7861 description
7862 "Address family used for management.";
7863 }
7864 leaf address {
7865 when "(../address-family)" {
7866 description
7867 "If address-family is specified, then address should
7868 also be specified.If address-family is not specified,
7869 then address should also not be specified.";
7870 }
7871 type inet:ip-address;
7872 mandatory true;
7873 description
7874 "Management address.";
7875 }
7876 description
7877 "Management configuration. Applicable only for
7878 co-managed device.";
7879 }
7880 description
7881 "Device configuration.";
7882 }
7883 description
7884 "List of devices requested by customer.";
7885 }
7886 description
7887 "Grouping for device allocation.";
7888 }
7889 grouping site-vpn-flavor {
7890 leaf site-vpn-flavor {
7891 type identityref {
7892 base site-vpn-flavor;
7893 }
7894 default site-vpn-flavor-single;
7895 description
7896 "Defines the way the VPN multiplexing is done ,e.g.,whether
7897 the site belongs to a single VPN site or a multiVPN; In case
7898 of multiVPN, whether the logical accesses of the sites belong
7899 to the same set of VPNs or each logical accesses map to
7900 different VPNs. ";
7901 }
7902 description
7903 "Grouping for site VPN flavor.";
7904 }
7905 grouping site-vpn-policy {
7906 container vpn-policies {
7907 list vpn-policy {
7908 key vpn-policy-id;
7909 leaf vpn-policy-id {
7910 type svc-id;
7911 description
7912 "Unique identifier for the VPN policy.";
7913 }
7914 list entries {
7915 key id;
7916 leaf id {
7917 type svc-id;
7918 description
7919 "Unique identifier for the policy entry.";
7920 }
7921 container filters {
7922 list filter {
7923 key type;
7924 ordered-by user;
7925 leaf type {
7926 type identityref {
7927 base vpn-policy-filter-type;
7928 }
7929 description
7930 "Type of VPN Policy filter.";
7931 }
7932 leaf-list lan-tag {
7933 when "derived-from-or-self(../type, 'l3vpn-svc:lan')" {
7934 description
7935 "Only applies when VPN Policy filter is LAN Tag filter.";
7936 }
7937 if-feature lan-tag;
7938 type string;
7939 description
7940 "List of 'lan-tag' items to be matched. Lan-tag
7941 is Internal tag to be used in VPN policies ";
7942 }
7943 leaf-list ipv4-lan-prefix {
7944 when "derived-from-or-self(../type, 'l3vpn-svc:ipv4')" {
7945 description
7946 "Only applies when VPN Policy filter is IPv4 Prefix filter.";
7947 }
7948 if-feature ipv4;
7949 type inet:ipv4-prefix;
7950 description
7951 "List of IPv4 prefixes as LAN Prefixes to be matched.";
7952 }
7953 leaf-list ipv6-lan-prefix {
7954 when "derived-from-or-self(../type, 'l3vpn-svc:ipv6')" {
7955 description
7956 "Only applies when VPN Policy filter is IPv6 Prefix filter.";
7957 }
7958 if-feature ipv6;
7959 type inet:ipv6-prefix;
7960 description
7961 "List of IPv6 prefixes as LAN prefixes to be matched.";
7962 }
7963 description
7964 "List of filters used on the site. This list can
7965 be augmented.";
7966 }
7967 description
7968 "If a more-granular VPN attachment is necessary, filtering can
7969 be used. If used, it permits the splitting of site LANs among
7970 multiple VPNs.The Site LAN can be split based on either LAN-tag
7971 or LAN prefix. If no filter is used, all the LANs will be
7972 part of the same VPNs with the same role.";
7973 }
7974 list vpn {
7975 key vpn-id;
7976 leaf vpn-id {
7977 type leafref {
7978 path "/l3vpn-svc/vpn-services/"+
7979 "vpn-service/vpn-id";
7980 }
7981 mandatory true;
7982 description
7983 "Reference to an IP VPN.";
7984 }
7985 leaf site-role {
7986 type identityref {
7987 base site-role;
7988 }
7989 default any-to-any-role;
7990 description
7991 "Role of the site in the IP VPN.";
7992 }
7993 description
7994 "List of VPNs the LAN is associated with.";
7995 }
7996 description
7997 "List of entries for export policy.";
7998 }
7999 description
8000 "List of VPN policies.";
8001 }
8002 description
8003 "VPN policy.";
8004 }
8005 description
8006 "VPN policy parameters for the site.";
8007 }
8008 grouping site-maximum-routes {
8009 container maximum-routes {
8010 list address-family {
8012 key af;
8013 leaf af {
8014 type address-family;
8015 description
8016 "Address family.";
8017 }
8018 leaf maximum-routes {
8019 type uint32;
8020 description
8021 "Maximum prefixes the VRF can accept for this address family.";
8022 }
8023 description
8024 "List of address families.";
8025 }
8026 description
8027 "Defines 'maximum-routes' for the VRF.";
8028 }
8029 description
8030 "Defines 'maximum-routes' for the site.";
8031 }
8032 grouping site-security {
8033 container security {
8034 uses site-security-authentication;
8035 uses site-security-encryption;
8036 description
8037 "Site-specific security parameters.";
8038 }
8039 description
8040 "Grouping for security parameters.";
8041 }
8042 grouping site-service {
8043 container service {
8044 uses site-service-qos-profile;
8045 uses site-service-mpls;
8046 uses site-service-multicast;
8047 description
8048 "Service parameters on the attachment.";
8049 }
8050 description
8051 "Grouping for service parameters.";
8052 }
8053 grouping site-network-access-service {
8054 container service {
8055 uses site-service-basic;
8056 uses site-service-qos-profile;
8057 uses site-service-mpls;
8058 uses site-service-multicast;
8059 description
8061 "Service parameters on the attachment.";
8062 }
8063 description
8064 "Grouping for service parameters.";
8065 }
8066 grouping vpn-extranet {
8067 container extranet-vpns {
8068 if-feature extranet-vpn;
8069 list extranet-vpn {
8070 key vpn-id;
8071 leaf vpn-id {
8072 type svc-id;
8073 description
8074 "Identifies the target VPN the local VPN want to access.";
8075 }
8076 leaf local-sites-role {
8077 type identityref {
8078 base site-role;
8079 }
8080 default any-to-any-role;
8081 description
8082 "This describes the role of the
8083 local sites in the target VPN topology. In the any-to-any VPN
8084 service topology, the local sites must have the same role, which
8085 will be 'any-to-any-role '.In the Hub-and-Spoke VPN service
8086 topology or the Hub and Spoke disjoint VPN service topology,
8087 the local sites must have a Hub role or a Spoke role.";
8088 }
8089 description
8090 "List of extranet VPNs or target VPNs the local VPN is attached to.";
8091 }
8092 description
8093 "Container for extranet VPN configuration.";
8094 }
8095 description
8096 "Grouping for extranet VPN configuration.
8097 This provides an easy way to interconnect
8098 all sites from two VPNs.";
8099 }
8100 grouping site-attachment-availability {
8101 container availability {
8102 leaf access-priority {
8103 type uint32;
8104 default 100;
8105 description
8106 "Defines the priority for the access.
8108 The higher the access-priority value,
8110 the higher the preference of the
8111 access will be.";
8112 }
8113 description
8114 "Availability parameters (used for multihoming).";
8115 }
8116 description
8117 "Defines availability parameters for a site.";
8118 }
8119 grouping access-vpn-policy {
8120 container vpn-attachment {
8121 choice attachment-flavor {
8122 case vpn-policy-id {
8123 leaf vpn-policy-id {
8124 type leafref {
8125 path "../../../../"+
8126 "vpn-policies/vpn-policy/"+
8127 "vpn-policy-id";
8128 }
8129 description
8130 "Reference to a VPN policy. When referencing VPN
8131 policy for attachment, the vpn-policy-id must be
8132 configured.";
8133 }
8134 }
8135 case vpn-id {
8136 leaf vpn-id {
8137 type leafref {
8138 path "/l3vpn-svc/vpn-services"+
8139 "/vpn-service/vpn-id";
8140 }
8141 description
8142 "Reference to a IP VPN. Referencing a vpn-id provides
8143 an easy way to attach a particular logical access to
8144 a VPN. In this case, vpn-id must be configured.";
8145 }
8146 leaf site-role {
8147 type identityref {
8148 base site-role;
8149 }
8150 default any-to-any-role;
8151 description
8152 "Role of the site in the IP VPN. When referencing a vpn-id,
8153 the site-role setting must be added to express the role of
8154 the site in the target VPN service topology.";
8155 }
8156 }
8158 mandatory true;
8159 description
8160 "Choice for VPN attachment flavor. A choice is implemented
8161 to allow the user to choose the flavor that provides the
8162 best fit.";
8163 }
8164 description
8165 "Defines VPN attachment of a site.";
8166 }
8167 description
8168 "Defines the VPN attachment rules for
8169 a site's logical access.";
8170 }
8171 grouping vpn-profile-cfg {
8172 container valid-provider-identifiers {
8173 list cloud-identifier {
8174 if-feature cloud-access;
8175 key id;
8176 leaf id {
8177 type string;
8178 description
8179 "Identification of cloud service.
8180 Local administration meaning.";
8181 }
8182 description
8183 "List for Cloud Identifiers.";
8184 }
8185 list encryption-profile-identifier {
8186 key id;
8187 leaf id {
8188 type string;
8189 description
8190 "Identification of the SP encryption profile
8191 to be used. Local administration meaning.";
8192 }
8193 description
8194 "List for encryption profile identifiers.";
8195 }
8196 list qos-profile-identifier {
8197 key id;
8198 leaf id {
8199 type string;
8200 description
8201 "Identification of the QoS Profile to be used.
8202 Local administration meaning.";
8203 }
8204 description
8205 "List for QoS Profile Identifiers.";
8207 }
8209 list bfd-profile-identifier {
8210 key id;
8211 leaf id {
8212 type string;
8213 description
8214 "Identification of the SP BFD Profile to be used.
8215 Local administration meaning.";
8216 }
8217 description
8218 "List for BFD profile Identifiers.";
8219 }
8220 nacm:default-deny-write;
8221 description
8222 "Container for Valid Provider Identifies.";
8223 }
8224 description
8225 "Grouping for VPN Profile configuration.";
8226 }
8227 grouping vpn-svc-cfg {
8228 leaf vpn-id {
8229 type svc-id;
8230 description
8231 "VPN identifier. Local administration meaning.";
8232 }
8233 leaf customer-name {
8234 type string;
8235 description
8236 "Name of the customer which actually uses vpn service.
8237 In the case that any intermediary (e.g. Tier-2 provider
8238 or partner) sells the vpn service to their enduser
8239 on behalf of the original service provider (e.g. Tier-1
8240 provider), the original service provider may require the
8241 customer name to provide smooth activation/commitioning
8242 and operation for the service.";
8243 }
8244 leaf vpn-service-topology {
8245 type identityref {
8246 base vpn-topology;
8247 }
8248 default any-to-any;
8249 description
8250 "VPN service topology.";
8251 }
8252 uses vpn-service-cloud-access;
8253 uses vpn-service-multicast;
8254 uses vpn-service-mpls;
8256 uses vpn-extranet;
8257 description
8259 "Grouping for VPN service configuration.";
8260 }
8261 grouping site-top-level-cfg {
8262 uses operational-requirements;
8263 uses customer-location-info;
8264 uses site-devices;
8265 uses site-diversity;
8266 uses site-management;
8267 uses site-vpn-policy;
8268 uses site-vpn-flavor;
8269 uses site-maximum-routes;
8270 uses site-security;
8271 uses site-service;
8272 uses site-protection;
8273 uses site-routing;
8274 description
8275 "Grouping for site top-level configuration.";
8276 }
8277 grouping site-network-access-top-level-cfg {
8278 leaf site-network-access-type {
8279 type identityref {
8280 base site-network-access-type;
8281 }
8282 default point-to-point;
8283 description
8284 "Describes the type of connection, e.g.,
8285 point-to-point or multipoint.";
8286 }
8287 choice location-flavor {
8288 case location {
8289 when "derived-from-or-self(../../management/type, "+
8290 "'l3vpn-svc:customer-managed')" {
8291 description
8292 "Applicable only for customer-managed device.";
8293 }
8294 leaf location-reference {
8295 type leafref {
8296 path "../../../locations/location/location-id";
8297 }
8298 description
8299 "Location of the site-network-access.";
8300 }
8301 }
8302 case device {
8303 when "derived-from-or-self(../../management/type, "+
8305 "'l3vpn-svc:provider-managed') or "+
8306 "derived-from-or-self(../../management/type, "+
8307 "'l3vpn-svc:co-managed')" {
8309 description
8310 "Applicable only for provider-managed or co-managed device.";
8311 }
8312 leaf device-reference {
8313 type leafref {
8314 path "../../../devices/device/device-id";
8315 }
8316 description
8317 "Identifier of CE to use.";
8318 }
8319 }
8320 mandatory true;
8321 description
8322 "Choice of how to describe the site's location.";
8323 }
8324 uses access-diversity;
8325 uses site-attachment-bearer;
8326 uses site-attachment-ip-connection;
8327 uses site-security;
8328 uses site-network-access-service;
8329 uses site-routing;
8330 uses site-attachment-availability;
8331 uses access-vpn-policy;
8332 description
8333 "Grouping for site network access top-level configuration.";
8334 }
8335 /* Main blocks */
8336 container l3vpn-svc {
8337 container vpn-profiles {
8338 uses vpn-profile-cfg;
8339 description
8340 "Container for VPN Profiles.";
8341 }
8342 container vpn-services {
8343 list vpn-service {
8344 key vpn-id;
8345 uses vpn-svc-cfg;
8346 description
8347 "List of VPN services.";
8348 }
8349 description
8350 "Top-level container for the VPN services.";
8351 }
8352 container sites {
8354 list site {
8355 key site-id;
8356 leaf site-id {
8357 type svc-id;
8359 description
8360 "Identifier of the site.";
8361 }
8362 uses site-top-level-cfg;
8363 uses operational-requirements-ops;
8364 container site-network-accesses {
8365 list site-network-access {
8366 key site-network-access-id;
8367 leaf site-network-access-id {
8368 type svc-id;
8369 description
8370 "Identifier for the access.";
8371 }
8372 uses site-network-access-top-level-cfg;
8373 description
8374 "List of accesses for a site.";
8375 }
8376 description
8377 "List of accesses for a site.";
8378 }
8379 description
8380 "List of sites.";
8381 }
8382 description
8383 "Container for sites.";
8384 }
8385 description
8386 "Main container for L3VPN service configuration.";
8387 }
8388 }
8389
8391 10. Security Considerations
8393 The YANG module defined in this document MAY be accessed via the
8394 RESTCONF protocol [RFC8040] or the NETCONF protocol [RFC6241]. The
8395 lowest RESTCONF or NETCONF layer requires that the transport-layer
8396 protocol provide both data integrity and confidentiality; see
8397 Section 2 in [RFC8040] and Section 2 in [RFC6241]. The client MUST
8398 carefully examine the certificate presented by the server to
8399 determine if it meets the client's expectations, and the server MUST
8400 authenticate client and authorize access to any protected resource.
8401 The client identity derived from the authentication mechanism used is
8402 subject to the NETCONF Access Control Model (NACM) [RFC6536]. Other
8403 protocols that are used to access this YANG module are also required
8404 to support similar security mechanisms.
8406 The data nodes defined in the "ietf-l3vpn-svc" YANG module MUST be
8407 carefully created, read, updated, or deleted as appropriate. The
8408 entries in the lists below include customer-proprietary or
8409 confidential information; therefore, access to confidential
8410 information MUST be limited to authorized clients, and other clients
8411 MUST NOT be permitted to access the information.
8413 o /l3vpn-svc/vpn-services/vpn-service
8415 o /l3vpn-svc/sites/site
8417 The data model defines some security parameters than can be extended
8418 via augmentation as part of the customer service request; those
8419 parameters are described in Section 6.9.
8421 11. IANA Considerations
8423 IANA has assigned a new URI from the "IETF XML Registry" [RFC3688].
8425 URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
8426 Registrant Contact: The IESG
8427 XML: N/A; the requested URI is an XML namespace.
8429 IANA has recorded a YANG module name in the "YANG Module Names"
8430 registry [RFC7950] as follows:
8432 Name: ietf-l3vpn-svc
8433 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
8434 Prefix: l3vpn-svc
8435 Reference: RFC 8049
8437 IANA is requested to update this registry to reference this document
8438 on publication as an RFC.
8440 12. References
8442 12.1. Normative References
8444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
8445 Requirement Levels", BCP 14, RFC 2119,
8446 DOI 10.17487/RFC2119, March 1997,
8447 .
8449 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
8450 DOI 10.17487/RFC3688, January 2004,
8451 .
8453 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
8454 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
8455 2006, .
8457 [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the
8458 Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
8459 Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577,
8460 June 2006, .
8462 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
8463 Address Autoconfiguration", RFC 4862,
8464 DOI 10.17487/RFC4862, September 2007,
8465 .
8467 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
8468 and A. Bierman, Ed., "Network Configuration Protocol
8469 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
8470 .
8472 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
8473 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
8474 2012, .
8476 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
8477 Protocol (NETCONF) Access Control Model", RFC 6536,
8478 DOI 10.17487/RFC6536, March 2012,
8479 .
8481 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
8482 RFC 7950, DOI 10.17487/RFC7950, August 2016,
8483 .
8485 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
8486 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
8487 .
8489 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data
8490 Model for L3VPN Service Delivery", RFC 8049,
8491 DOI 10.17487/RFC8049, February 2017,
8492 .
8494 12.2. Informative References
8496 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
8497 Private Network (VPN) Terminology", RFC 4026,
8498 DOI 10.17487/RFC4026, March 2005,
8499 .
8501 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
8502 Provider-Provisioned Virtual Private Networks (PPVPNs)",
8503 RFC 4110, DOI 10.17487/RFC4110, July 2005,
8504 .
8506 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
8507 "Multiprotocol Extensions for BGP-4", RFC 4760,
8508 DOI 10.17487/RFC4760, January 2007,
8509 .
8511 Appendix A. Acknowledgements
8513 Maxim Klyus, Luis Miguel Contreras, Gregory Mirsky, Zitao Wang, Jing
8514 Zhao, Kireeti Kompella, Eric Rosen, Aijun Wang,Michael Scharf, Xufeng
8515 Liu, David Ball, Lucy Yong, Jean-Philippe Landry, and Andrew Leu
8516 provided useful review to this document.
8518 Jan Lindblad reviewed the first release of RFC8049 and found some
8519 bugs and His thorough YANG Doctor review on the YANG Model is
8520 valuable input to revision of RFC8049. David ball also provided a
8521 second review on published RFC8049.
8523 Many thanks to these people.
8525 Appendix B. Contributors
8527 The authors would like to thank Rob Shakir for his major
8528 contributions to the initial modeling and use cases.
8530 Adrian Farrel prepared the editorial revisions for this bis.
8532 Authors' Addresses
8534 Qin Wu (editor)
8535 Huawei Technologies
8537 Email: bill.wu@huawei.com
8539 Stephane Litkowski
8540 Orange Business Services
8542 Email: stephane.litkowski@orange.com
8544 Luis Tomotaki
8545 Verizon
8547 Email: luis.tomotaki@verizon.com
8549 Kenichi Ogaki
8550 KDDI Corporation
8552 Email: ke-oogaki@kddi.com