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