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