RFC 8299
YANG Data Model for L3VPN Service Delivery
RFC 8299: YANG Data Model for L3VPN Service Delivery 🎀
Part 1 of 31 🌸 More parts coming, bestie!
Internet Engineering Task Force (IETF) 🌈 Request for Comments: 8299, published January 2018 🗓️ Obsoletes: RFC 8049 🔁 (updates: none listed) Category: Standards Track ✅ ISSN: 2070-1721
The authors are Q. Wu, Ed. (Huawei), S. Litkowski (Orange), L. Tomotaki (Verizon), and K. Ogaki (KDDI Corporation). 👑
Abstract 💜
okay so this doc defines a YANG data model 🧚 that customers and network operators can use to talk about, and deliver, a Layer 3 provider-provisioned VPN service. it's limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. 💅
the model is meant to be instantiated at the management system to deliver the overall service. it is not a configuration model for network elements to use directly 🙅♀️. it gives an abstracted view of the Layer 3 IP VPN service configuration components, and it's up to the management system to take this model as input and use specific configuration models to configure the different network elements. how the configuration of network elements gets done is out of scope for this document. 🫶
this document obsoletes RFC 8049 🔁. it replaces the unimplementable module from that RFC with a new module of the same name that is not backward compatible 😭. the changes are a bunch of small fixes to the YANG module plus some clarifications to the text. ✨
Status of This Memo 🌙
this is an Internet Standards Track document. 🏆
it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 7841. 📚
info about the current status of this document, any errata, and how to give feedback on it lives at https://www.rfc-editor.org/info/rfc8299 🔗
Copyright Notice ©️
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 🌷
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. please read these carefully, because they spell out your rights and restrictions with respect to this document 🧾. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License. 💖
Table of Contents 🗂️
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Requirements Language ......................................5
1.3. Tree Diagrams ..............................................5
1.4. Summary of Changes from RFC 8049 ...........................5
1.4.1. Implementation Issues with RFC 8049 .................7
1.4.2. Impact Assessment ...................................7
2. Acronyms ........................................................8
3. Definitions ....................................................10
4. Layer 3 IP VPN Service Model ...................................10
5. Service Data Model Usage .......................................11
6. Design of the Data Model .......................................12
6.1. Features and Augmentation .................................22
6.2. VPN Service Overview ......................................22
6.2.1. VPN Service Topology ...............................23
6.2.2. Cloud Access .......................................26
6.2.3. Multicast Service ..................................29
6.2.4. Extranet VPNs ......................................30
6.3. Site Overview .............................................32
6.3.1. Devices and Locations ..............................33
6.3.2. Site Network Accesses ..............................34
6.4. Site Role .................................................36
6.5. Site Belonging to Multiple VPNs ...........................37
6.5.1. Site VPN Flavor ....................................37
6.5.2. Attaching a Site to a VPN ..........................41
6.6. Deciding Where to Connect the Site ........................47
6.6.1. Constraint: Device .................................48
6.6.2. Constraint/Parameter: Site Location ................48
6.6.3. Constraint/Parameter: Access Type ..................49
6.6.4. Constraint: Access Diversity .......................50
6.6.5. Infeasible Access Placement ........................59
6.6.6. Examples of Access Placement .......................60
6.6.7. Route Distinguisher and VRF Allocation .............80
6.7. Site Network Access Availability ..........................81
6.8. Traffic Protection ........................................82
6.9. Security ..................................................83
6.9.1. Authentication .....................................83
6.9.2. Encryption .........................................84
6.10. Management ...............................................85
6.11. Routing Protocols ........................................86
6.11.1. Handling of Dual Stack ............................87
6.11.2. LAN Directly Connected to SP Network ..............88
6.11.3. LAN Directly Connected to SP Network with
Redundancy ........................................89
6.11.4. Static Routing ....................................89
6.11.5. RIP Routing .......................................89
6.11.6. OSPF Routing ......................................90
6.11.7. BGP Routing .......................................92
6.12. Service ..................................................93
6.12.1. Bandwidth .........................................94
6.12.2. MTU ...............................................94
6.12.3. QoS ...............................................94
6.12.4. Multicast ........................................103
6.13. Enhanced VPN Features ...................................104
6.13.1. Carriers' Carriers ...............................104
6.14. External ID References ..................................105
6.15. Defining NNIs ...........................................105
6.15.1. Defining an NNI with the Option A Flavor .........107
6.15.2. Defining an NNI with the Option B Flavor .........111
6.15.3. Defining an NNI with the Option C Flavor .........113
7. Service Model Usage Example ...................................114
8. Interaction with Other YANG Models ............................120
9. YANG Module ...................................................125
10. Security Considerations ......................................184
11. IANA Considerations ..........................................185
12. References ...................................................185
12.1. Normative References ....................................185
12.2. Informative References ..................................187
Acknowledgements .................................................188
Contributors .....................................................188
Authors' Addresses ...............................................1881. Introduction ✨
okay bestie, so this document defines a Layer 3 VPN service data model written in YANG 🧁. the model defines service configuration elements that can be used in communication protocols between customers and network operators. those same elements can also be used as input to automated control and configuration applications 🤖.
this document obsoletes [RFC8049] 🔁. it creates a new module with the same name as the module defined in [RFC8049]. the changes from [RFC8049] are listed in full in Section 1.4. they're small in scope, but they include fixes to the module that make it possible to implement 🛠️.
the YANG module described in [RFC8049] cannot be implemented because of issues around the use of XPATH 💀. those issues are explained in Section 1.4.1.
Section 11 of [RFC7950] describes when it is permissible to reuse a module name 🧐. Section 1.4.2 gives an impact assessment in this context.
1.1. Terminology 📖
the following terms are defined in [RFC6241] and are not redefined here:
- client 🎀
- configuration data 🎀
- server 🎀
- state data 🎀
the following terms are defined in [RFC7950] and are not redefined here:
- augment 🌸
- data model 🌸
- data node 🌸
the terminology for describing YANG data models is found in [RFC7950] 💜.
this document presents some configuration examples using XML representation 🍓.
1.2. Requirements Language 🔑
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🔥 these are the only ones that count as the official key words, so lowercase versions don't carry that weight. 🙈
1.3. Tree Diagrams 🌳
a simplified graphical representation of the data model is presented in Section 6 🦋. here's what the symbols in those diagrams mean:
- Brackets
[and]enclose list keys. 🔑 - Curly braces
{and}contain names of optional features that make the corresponding node conditional. 🧩 - Abbreviations before data node names:
rwmeans configuration data (read-write), andromeans state data (read-only). 👀 - Symbols after data node names:
?means an optional node, and*denotes alistorleaf-list. 💅 - Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (
:). 🌈 - Ellipsis (
...) stands for contents of subtrees that are not shown. 🫶
1.4. Summary of Changes from RFC 8049 🎀
okay so this doc revises and obsoletes the L3VPN Service Model [RFC8049] 💅 It's built on what people learned from deploying L3VPN Service Models and on feedback from the community. Here's the glow-up list:
- Changed the type of the leaf id under
"qos-classification-policy"from a 16-bit integer to a string 🧚 - Stuck with
ordered-by userand got rid of the inefficient mapping from service model sequence number to device model sequence number ✨ - Stopped mandating deviations, and added
if-feature target-sitesunder the leaf-list target-sites in Section 6.12.2.1 of [RFC8049] 🌸 - Changed the keywords from [RFC2119] and [RFC8174] about how the management system operates, in the third paragraph of Section 6.6, Section 6.6.5, and Section 7 📚
- Fixed incomplete description statements 🫶
- Added a YANG statement to check that Stateless Address Autoconfiguration (SLAAC) parameters are only used for IPv6 🌈
- Fixed some strange wording in Section 6.11.7 🙈
- Switched from absolute paths to relative paths in the
mustorpathstatements for the vpn-policy-id leaf node, management container, location leaf node, devices container, location case, location-reference leaf, device case, and device-reference leaf. This way the configuration only applies to the current sites 🦋 - Changed a
muststatement to awhenstatement for the management container device container 💜 - Fixed optional parameter issues by adding a default or description to some, and making others mandatory 👑
- Defined the new grouping
vpn-profile-cfgfor all the identifiers the SP gives to the customer. Those identifiers are cloud-identifier, std-qos-profile, the OAM profile-name, and provider-profile for encryption 🔐 - Added the XPATH string representation of identityrefs and removed the unqualified name. Also moved from YANG 1.0 support to YANG 1.1 support 🍓
- Removed the
whenstatement from leaf nat44-customer-address 💅 - Fixed a broken example and added mandatory elements to the examples ✨
- Removed redundant parameters in the cloud access 🧹
- Specified the provider address and a list of start-end addresses from the provider address for the DHCP case 🌸
- Added some text in Section 6.3 to clarify what a site is 🫧
- Added multi-filter and multiVPN-per-entry support for VPN policy 🔥
- Modified the description for the svc-input-bandwidth leaf and svc-output-bandwidth leaf so it matches the text in Section 6.12.1 💖
- Clarified the rationale of the model in Section 5 🧠
- Added text explaining how to achieve Per-VPN QoS policy 🦋
1.4.1. Implementation Issues with RFC 8049 🔧
okay bestie, so [RFC8049] made the first attempt at a YANG data model for L3VPN services 🫶 Then people found out that, even though the YANG compiled, it was broken from an implementation point of view. Basically, nobody could build a working implementation of the module 😭
Section 1.4 has the full list of changes since [RFC8049]. Some of them clear up ambiguities in the YANG, and others fix the implementation issues 💅
- Several uses of
mustexpressions in the module were broken badly enough that the module couldn't be used in the form it was published. Some compilers and YANG checkers found no issues, since most YANG tools don't try to parse these expressions. But other tools that really understand the XPATH in those expressions refused to compile them 💀
The fixes needed for these expressions were small and local ✨
- The second issue is about how Access Control List (ACL) rules were sorted 🙈 In [RFC8049], the English text and the YANG definition contradicted each other. On top of that, the model used classic ACL rule numbering for something that was semantically very different (
ordered-by user) in the YANG, which made it easy to misunderstand 🌀 - Following on from point 2, the ACL modeling in [RFC8049] was incompatible with work going on in other IETF documents, such as [ACL-YANG] 🚫
1.4.2. Impact Assessment 🌸
when you change the content of a YANG module, you have to be careful that there are no interoperability issues caused by failing to enable backward compatibility. This is one of those "be careful, bestie" moments 🫶
Section 11 of [RFC7950] spells out the situations where it is not acceptable to keep a module name:
...changes to published modules are not allowed if they have any potential to cause interoperability problems between a client using an original specification and a server using an updated specification.
The module in this document is not backward compatible with the one defined in [RFC8049]. BUT there's no chance of an interoperability issue between this module and the one in [RFC8049], because that module couldn't be implemented for the reasons in Section 1.4.1 😭 So, following the rules in [RFC7950], it was decided to keep the module name in this document 💖
2. Acronyms ✨
- AAA: Authentication, Authorization, and Accounting.
- ACL: Access Control List.
- ADSL: Asymmetric DSL.
- AH: Authentication Header.
- AS: Autonomous System.
- ASBR: Autonomous System Border Router.
- ASM: Any-Source Multicast.
- BAS: Broadband Access Switch.
- BFD: Bidirectional Forwarding Detection.
- BGP: Border Gateway Protocol.
- BSR: Bootstrap Router.
- CE: Customer Edge.
- CLI: Command Line Interface.
- CsC: Carriers' Carriers.
- CSP: Cloud Service Provider.
- DHCP: Dynamic Host Configuration Protocol.
- DSLAM: Digital Subscriber Line Access Multiplexer.
- ESP: Encapsulating Security Payload.
- GRE: Generic Routing Encapsulation.
- IGMP: Internet Group Management Protocol.
- LAN: Local Area Network.
- MLD: Multicast Listener Discovery.
- MTU: Maximum Transmission Unit.
- NAT: Network Address Translation.
- NETCONF: Network Configuration Protocol.
- NNI: Network-to-Network Interface.
- OAM: Operations, Administration, and Maintenance.
- OSPF: Open Shortest Path First.
- OSS: Operations Support System.
- PE: Provider Edge.
- PIM: Protocol Independent Multicast.
- POP: Point of Presence.
- QoS: Quality of Service.
- RD: Route Distinguisher.
- RIP: Routing Information Protocol.
- RP: Rendezvous Point.
- RT: Route Target.
- SFTP: Secure FTP.
- SLA: Service Level Agreement.
- SLAAC: Stateless Address Autoconfiguration.
- SP: Service Provider.
- SPT: Shortest Path Tree.
- SSM: Source-Specific Multicast.
- VM: Virtual Machine.
- VPN: Virtual Private Network.
- VRF: VPN Routing and Forwarding.
- VRRP: Virtual Router Redundancy Protocol.
3. Definitions 🦋
Customer Edge (CE) Device: okay so a CE is equipment dedicated to one particular customer 💁♀️ It's directly connected (at Layer 3) to one or more PE devices through attachment circuits. CEs usually live at the customer premises and are usually dedicated to a single VPN. They can support multiple VPNs, but only if each one has its own separate attachment circuits 🌸
Provider Edge (PE) Device: a PE is equipment managed by the SP 🧚 It can support multiple VPNs for different customers, and it's directly connected (at Layer 3) to one or more CE devices through attachment circuits. PEs are usually at an SP point of presence (POP), and the SP is the one managing them 💅
PE-Based VPNs: the PE devices know which traffic is VPN traffic 🫶 They forward it (through tunnels) based on the destination IP address of the packet and, optionally, on other information in the packet's IP header. The PE devices are the tunnel endpoints themselves. The tunnels can use different encapsulations to send traffic across the SP network, such as (but not limited to) GRE, IP-in-IP, IPsec, or MPLS tunnels 🌈
4. Layer 3 IP VPN Service Model 💖
A Layer 3 IP VPN service is a collection of sites that are allowed to exchange traffic with each other over a shared IP infrastructure ✨ This Layer 3 VPN service model is all about giving everyone a shared understanding of how that IP VPN service gets deployed over the shared infrastructure. It's limited to BGP PE-based VPNs as described in [RFC4026], [RFC4110], and [RFC4364] 🎀
5. Service Data Model Usage 🌸
l3vpn-svc |
Model |
|
+------------------+ +-----+
| Orchestration | < --- > | OSS |
+------------------+ +-----+
| |
+----------------+ |
| Config manager | |
+----------------+ |
| |
| NETCONF/CLI ...
| |
+------------------------------------------------+
Network
+++++++
+ AAA +
+++++++
++++++++ Bearer ++++++++ ++++++++ ++++++++
+ CE A + ----------- + PE A + + PE B + ---- + CE B +
++++++++ Connection ++++++++ ++++++++ ++++++++
Site A Site Bokay the big idea of the L3 IP VPN service model is an abstracted interface between customers and network operators, so they can manage the configuration of L3VPN service components together 🦋 The model is meant to be used with the network operator's system as the server and the customer's system as the client 💜 A typical setup uses the model as input for an orchestration layer, which translates it into orchestrated configuration for the network elements that are part of the service ✨ Those network elements can be routers, but they can also be servers (like AAA). The network's configuration isn't limited to these examples 🌈 Configuration of network elements can happen through the CLI, or through NETCONF/RESTCONF [RFC6241] [RFC8040] together with YANG data models for specific configuration (BGP, VRF, BFD, etc.), or through some other technique, whatever the operator prefers 💅
This service model isn't limited to this example. Any component of the management system can use it, but network elements can't use it directly 🙈
6. Design of the Data Model 🧠
okay so the YANG module is split into two main containers: "vpn-services" and "sites" 💖
The "vpn-service" list under the "vpn-services" container defines the global parameters for a customer's VPN service 🎀
A "site" is made up of at least one "site-network-access". In the case of multihoming, it can have multiple site-network-access points 🌸 Site-network-access attachment happens through a "bearer", with an "ip-connection" on top of it 🧚 The bearer refers to the attachment properties that sit below Layer 3, while the connection refers to properties about the Layer 3 protocol 🫶 The SP can allocate the bearer dynamically, and the customer can provide some constraints or parameters to guide where the access is placed 💅
Traffic exchange is authorized through what we call a VPN policy, or VPN service topology, which defines the routing exchange rules between sites 🦋
The figure below describes the overall structure of the YANG module:
Okay bestie, the whole service model comes down to one big tree 🌸 Here it is, every branch and leaf exactly as it should be 🌳✨
module: ietf-l3vpn-svc
+--rw l3vpn-svc
+--rw vpn-profiles
| +--rw valid-provider-identifiers
| +--rw cloud-identifier* [id] {cloud-access}?
| | +--rw id string
| +--rw encryption-profile-identifier* [id]
| | +--rw id string
| +--rw qos-profile-identifier* [id]
| | +--rw id string
| +--rw bfd-profile-identifier* [id]
| +--rw id string
+--rw vpn-services
| +--rw vpn-service* [vpn-id]
| +--rw vpn-id svc-id
| +--rw customer-name? string
| +--rw vpn-service-topology? identityref
| +--rw cloud-accesses {cloud-access}?
| | +--rw cloud-access* [cloud-identifier]
| | +--rw cloud-identifier leafref
| | +--rw (list-flavor)?
| | | +--:(permit-any)
| | | | +--rw permit-any? empty
| | | +--:(deny-any-except)
| | | | +--rw permit-site*
| | | | -> /l3vpn-svc/sites/site/site-id
| | | +--:(permit-any-except)
| | | +--rw deny-site*
| | | -> /l3vpn-svc/sites/site/site-id
| | +--rw address-translation
| | +--rw nat44
| | +--rw enabled? boolean
| | +--rw nat44-customer-address?
| | inet:ipv4-address
| +--rw multicast {multicast}?
| | +--rw enabled? boolean
| | +--rw customer-tree-flavors
| | | +--rw tree-flavor* identityref
| | +--rw rp
| | +--rw rp-group-mappings
| | | +--rw rp-group-mapping* [id]
| | | +--rw id uint16
| | | +--rw provider-managed
| | | | +--rw enabled? boolean
| | | | +--rw rp-redundancy? boolean
| | | | +--rw optimal-traffic-delivery? boolean
| | | +--rw rp-address inet:ip-address
| | | +--rw groups
| | | +--rw group* [id]
| | | +--rw id uint16
| | | +--rw (group-format)
| | | +--:(singleaddress)
| | | | +--rw group-address?
| | | | inet:ip-address
| | | +--:(startend)
| | | +--rw group-start?
| | | | inet:ip-address
| | | +--rw group-end?
| | | inet:ip-address
| | +--rw rp-discovery
| | +--rw rp-discovery-type? identityref
| | +--rw bsr-candidates
| | +--rw bsr-candidate-address* inet:ip-address
| +--rw carrierscarrier? boolean {carrierscarrier}?
| +--rw extranet-vpns {extranet-vpn}?
| +--rw extranet-vpn* [vpn-id]
| +--rw vpn-id svc-id
| +--rw local-sites-role? identityref
+--rw sites
+--rw site* [site-id]
+--rw site-id svc-id
+--rw requested-site-start? yang:date-and-time
+--rw requested-site-stop? yang:date-and-time
+--rw locations
| +--rw location* [location-id]
| +--rw location-id svc-id
| +--rw address? string
| +--rw postal-code? string
| +--rw state? string
| +--rw city? string
| +--rw country-code? string
+--rw devices
| +--rw device* [device-id]
| +--rw device-id svc-id
| +--rw location
| | -> ../../../locations/location/location-id
| +--rw management
| +--rw address-family? address-family
| +--rw address inet:ip-address
+--rw site-diversity {site-diversity}?
| +--rw groups
| +--rw group* [group-id]
| +--rw group-id string
+--rw management
| +--rw type identityref
+--rw vpn-policies
| +--rw vpn-policy* [vpn-policy-id]
| +--rw vpn-policy-id svc-id
| +--rw entries* [id]
| +--rw id svc-id
| +--rw filters
| | +--rw filter* [type]
| | +--rw type identityref
| | +--rw lan-tag* string
| | | {lan-tag}?
| | +--rw ipv4-lan-prefix* inet:ipv4-prefix
| | | {ipv4}?
| | +--rw ipv6-lan-prefix* inet:ipv6-prefix
| | {ipv6}?
| +--rw vpn* [vpn-id]
| +--rw vpn-id leafref
| +--rw site-role? identityref
+--rw site-vpn-flavor? identityref
+--rw maximum-routes
| +--rw address-family* [af]
| +--rw af address-family
| +--rw maximum-routes? uint32
+--rw security
| +--rw authentication
| +--rw encryption {encryption}?
| +--rw enabled? boolean
| +--rw layer? enumeration
| +--rw encryption-profile
| +--rw (profile)?
| +--:(provider-profile)
| | +--rw profile-name? leafref
| +--:(customer-profile)
| +--rw algorithm? string
| +--rw (key-type)?
| +--:(psk)
| +--rw preshared-key? string
+--rw service
| +--rw qos {qos}?
| | +--rw qos-classification-policy
| | | +--rw rule* [id]
| | | +--rw id string
| | | +--rw (match-type)?
| | | | +--:(match-flow)
| | | | | +--rw match-flow
| | | | | +--rw dscp? inet:dscp
| | | | | +--rw dot1p? uint8
| | | | | +--rw ipv4-src-prefix?
| | | | | | inet:ipv4-prefix
| | | | | +--rw ipv6-src-prefix?
| | | | | | inet:ipv6-prefix
| | | | | +--rw ipv4-dst-prefix?
| | | | | | inet:ipv4-prefix
| | | | | +--rw ipv6-dst-prefix?
| | | | | | inet:ipv6-prefix
| | | | | +--rw l4-src-port?
| | | | | | inet:port-number
| | | | | +--rw target-sites* svc-id
| | | | | | {target-sites}?
| | | | | +--rw l4-src-port-range
| | | | | | +--rw lower-port? inet:port-number
| | | | | | +--rw upper-port? inet:port-number
| | | | | +--rw l4-dst-port?
| | | | | | inet:port-number
| | | | | +--rw l4-dst-port-range
| | | | | | +--rw lower-port? inet:port-number
| | | | | | +--rw upper-port? inet:port-number
| | | | | +--rw protocol-field? union
| | | | +--:(match-application)
| | | | +--rw match-application? identityref
| | | +--rw target-class-id? string
| | +--rw qos-profile
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile? leafref
| | +--:(custom)
| | +--rw classes {qos-custom}?
| | +--rw class* [class-id]
| | +--rw class-id string
| | +--rw direction? identityref
| | +--rw rate-limit? decimal64
| | +--rw latency
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-latency?
| | | | empty
| | | +--:(boundary)
| | | +--rw latency-boundary?
| | | uint16
| | +--rw jitter
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-jitter?
| | | | empty
| | | +--:(boundary)
| | | +--rw latency-boundary?
| | | uint32
| | +--rw bandwidth
| | +--rw guaranteed-bw-percent
| | | decimal64
| | +--rw end-to-end? empty
| +--rw carrierscarrier {carrierscarrier}?
| | +--rw signalling-type? enumeration
| +--rw multicast {multicast}?
| +--rw multicast-site-type? enumeration
| +--rw multicast-address-family
| | +--rw ipv4? boolean {ipv4}?
| | +--rw ipv6? boolean {ipv6}?
| +--rw protocol-type? enumeration
+--rw traffic-protection {fast-reroute}?
| +--rw enabled? boolean
+--rw routing-protocols
| +--rw routing-protocol* [type]
| +--rw type identityref
| +--rw ospf {rtg-ospf}?
| | +--rw address-family* address-family
| | +--rw area-address yang:dotted-quad
| | +--rw metric? uint16
| | +--rw sham-links {rtg-ospf-sham-link}?
| | +--rw sham-link* [target-site]
| | +--rw target-site svc-id
| | +--rw metric? uint16
| +--rw bgp {rtg-bgp}?
| | +--rw autonomous-system uint32
| | +--rw address-family* address-family
| +--rw static
| | +--rw cascaded-lan-prefixes
| | +--rw ipv4-lan-prefixes* [lan next-hop]
| | | {ipv4}?
| | | +--rw lan inet:ipv4-prefix
| | | +--rw lan-tag? string
| | | +--rw next-hop inet:ipv4-address
| | +--rw ipv6-lan-prefixes* [lan next-hop]
| | {ipv6}?
| | +--rw lan inet:ipv6-prefix
| | +--rw lan-tag? string
| | +--rw next-hop inet:ipv6-address
| +--rw rip {rtg-rip}?| +--rw address-family* address-family | |
|---|---|
| +--rw vrrp {rtg-vrrp}? | |
| +--rw address-family* address-family |
+--ro actual-site-start? yang:date-and-time +--ro actual-site-stop? yang:date-and-time +--rw site-network-accesses +--rw site-network-access* [site-network-access-id] +--rw site-network-access-id svc-id +--rw site-network-access-type? identityref +--rw (location-flavor)
| +--:(location) | |
|---|---|
| +--rw location-reference? leafref | |
| +--:(device) | |
| +--rw device-reference? | |
| -> ../../../devices/device/device-id |
+--rw access-diversity {site-diversity}?
| +--rw groups | |
|---|---|
| +--rw group* [group-id] | |
| +--rw group-id string | |
| +--rw constraints | |
| +--rw constraint* [constraint-type] | |
| +--rw constraint-type identityref | |
| +--rw target | |
| +--rw (target-flavor)? | |
| +--:(id) | |
| +--rw group* [group-id] | |
| +--rw group-id string | |
| +--:(all-accesses) | |
| +--rw all-other-accesses? empty | |
| +--:(all-groups) | |
| +--rw all-other-groups? empty |
+--rw bearer
| +--rw requested-type {requested-type}? | |
|---|---|
| +--rw requested-type? string | |
| +--rw strict? boolean | |
| +--rw always-on? boolean {always-on}? | |
| +--rw bearer-reference? string | |
| {bearer-reference}? |
+--rw ip-connection
| +--rw ipv4 {ipv4}? | |||
|---|---|---|---|
| +--rw address-allocation-type? identityref | |||
| +--rw provider-dhcp | |||
| +--rw provider-address? | |||
| inet:ipv4-address | |||
| +--rw prefix-length? uint8 | |||
| +--rw (address-assign)? | |||
| +--:(number) | |||
| +--rw number-of-dynamic-address? | |||
| uint16 | |||
| +--:(explicit) | |||
| +--rw customer-addresses | |||
| +--rw address-group* [group-id] | |||
| +--rw group-id string | |||
| +--rw start-address? | |||
| inet:ipv4-address | |||
| +--rw end-address? | |||
| inet:ipv4-address | |||
| +--rw dhcp-relay | |||
| +--rw provider-address? | |||
| inet:ipv4-address | |||
| +--rw prefix-length? uint8 | |||
| +--rw customer-dhcp-servers | |||
| +--rw server-ip-address* | |||
| inet:ipv4-address | |||
| +--rw addresses | |||
| +--rw provider-address? inet:ipv4-address | |||
| +--rw customer-address? inet:ipv4-address | |||
| +--rw prefix-length? uint8 | |||
| +--rw ipv6 {ipv6}? | |||
| +--rw address-allocation-type? identityref | |||
| +--rw provider-dhcp | |||
| +--rw provider-address? | |||
| inet:ipv6-address | |||
| +--rw prefix-length? uint8 | |||
| +--rw (address-assign)? | |||
| +--:(number) | |||
| +--rw number-of-dynamic-address? | |||
| uint16 | |||
| +--:(explicit) | |||
| +--rw customer-addresses | |||
| +--rw address-group* [group-id] | |||
| +--rw group-id string | |||
| +--rw start-address? | |||
| inet:ipv6-address | |||
| +--rw end-address? | |||
| inet:ipv6-address | |||
| +--rw dhcp-relay | |||
| +--rw provider-address? | |||
| inet:ipv6-address | |||
| +--rw prefix-length? uint8 | |||
| +--rw customer-dhcp-servers | |||
| +--rw server-ip-address* | |||
| inet:ipv6-address | |||
| +--rw addresses | |||
| +--rw provider-address? inet:ipv6-address | |||
| +--rw customer-address? inet:ipv6-address | |||
| +--rw prefix-length? uint8 | |||
| +--rw oam | |||
| +--rw bfd {bfd}? | |||
| +--rw enabled? boolean | |||
| +--rw (holdtime)? | |||
| +--:(fixed) | |||
| +--rw fixed-value? uint32 | |||
| +--:(profile) | |||
| +--rw profile-name? leafref |
+--rw security
| +--rw authentication | |
|---|---|
| +--rw encryption {encryption}? | |
| +--rw enabled? boolean | |
| +--rw layer? enumeration | |
| +--rw encryption-profile | |
| +--rw (profile)? | |
| +--:(provider-profile) | |
| +--rw profile-name? leafref | |
| +--:(customer-profile) | |
| +--rw algorithm? string | |
| +--rw (key-type)? | |
| +--:(psk) | |
| +--rw preshared-key? string |
+--rw service
| +--rw svc-input-bandwidth uint64 | ||||||
|---|---|---|---|---|---|---|
| +--rw svc-output-bandwidth uint64 | ||||||
| +--rw svc-mtu uint16 | ||||||
| +--rw qos {qos}? | ||||||
| +--rw qos-classification-policy | ||||||
| +--rw rule* [id] | ||||||
| +--rw id string | ||||||
| +--rw (match-type)? | ||||||
| +--:(match-flow) | ||||||
| +--rw match-flow | ||||||
| +--rw dscp? | ||||||
| inet:dscp | ||||||
| +--rw dot1p? uint8 | ||||||
| +--rw ipv4-src-prefix? | ||||||
| inet:ipv4-prefix | ||||||
| +--rw ipv6-src-prefix? | ||||||
| inet:ipv6-prefix | ||||||
| +--rw ipv4-dst-prefix? | ||||||
| inet:ipv4-prefix | ||||||
| +--rw ipv6-dst-prefix? | ||||||
| inet:ipv6-prefix | ||||||
| +--rw l4-src-port? | ||||||
| inet:port-number | ||||||
| +--rw target-sites* svc-id | ||||||
| {target-sites}? | ||||||
| +--rw l4-src-port-range | ||||||
| +--rw lower-port? | ||||||
| inet:port-number | ||||||
| +--rw upper-port? | ||||||
| inet:port-number | ||||||
| +--rw l4-dst-port? | ||||||
| inet:port-number | ||||||
| +--rw l4-dst-port-range | ||||||
| +--rw lower-port? | ||||||
| inet:port-number | ||||||
| +--rw upper-port? | ||||||
| inet:port-number | ||||||
| +--rw protocol-field? union | ||||||
| +--:(match-application) | ||||||
| +--rw match-application? | ||||||
| identityref | ||||||
| +--rw target-class-id? string | ||||||
| +--rw qos-profile | ||||||
| +--rw (qos-profile)? | ||||||
| +--:(standard) | ||||||
| +--rw profile? leafref | ||||||
| +--:(custom) | ||||||
| +--rw classes {qos-custom}? | ||||||
| +--rw class* [class-id] | ||||||
| +--rw class-id string | ||||||
| +--rw direction? identityref | ||||||
| +--rw rate-limit? decimal64 | ||||||
| +--rw latency | ||||||
| +-rw (flavor)? | ||||||
| +--:(lowest) | ||||||
| +-rw use-lowest-latency? | ||||||
| empty | ||||||
| +--:(boundary) | ||||||
| +-rw latency-boundary? | ||||||
| uint16 | ||||||
| +--rw jitter | ||||||
| +-rw (flavor)? | ||||||
| +--:(lowest) | ||||||
| +--rw use-lowest-jitter? | ||||||
| empty | ||||||
| +--:(boundary) | ||||||
| +--rw latency-boundary? | ||||||
| uint32 | ||||||
| +--rw bandwidth | ||||||
| +--rw guaranteed-bw-percent | ||||||
| decimal64 | ||||||
| +--rw end-to-end? | ||||||
| empty | ||||||
| +--rw carrierscarrier {carrierscarrier}? | ||||||
| +--rw signalling-type? enumeration | ||||||
| +--rw multicast {multicast}? | ||||||
| +--rw multicast-site-type? enumeration | ||||||
| +--rw multicast-address-family | ||||||
| +--rw ipv4? boolean {ipv4}? | ||||||
| +--rw ipv6? boolean {ipv6}? | ||||||
| +--rw protocol-type? enumeration |
+--rw routing-protocols
| +--rw routing-protocol* [type] | |
|---|---|
| +--rw type identityref | |
| +--rw ospf {rtg-ospf}? | |
| +--rw address-family* address-family | |
| +--rw area-address yang:dotted-quad | |
| +--rw metric? uint16 |
| | +--rw sham-links {rtg-ospf-sham-link}?
| | +--rw sham-link* [target-site]
| | +--rw target-site svc-id
| | +--rw metric? uint16
| +--rw bgp {rtg-bgp}?
| | +--rw autonomous-system uint32
| | +--rw address-family* address-family
| +--rw static
| | +--rw cascaded-lan-prefixes
| | +--rw ipv4-lan-prefixes*
| | | [lan next-hop] {ipv4}?
| | | +--rw lan inet:ipv4-prefix
| | | +--rw lan-tag? string
| | | +--rw next-hop inet:ipv4-address
| | +--rw ipv6-lan-prefixes*
| | [lan next-hop] {ipv6}?
| | +--rw lan inet:ipv6-prefix
| | +--rw lan-tag? string
| | +--rw next-hop inet:ipv6-address
| +--rw rip {rtg-rip}?
| | +--rw address-family* address-family
| +--rw vrrp {rtg-vrrp}?
| +--rw address-family* address-family
+--rw availability
| +--rw access-priority? uint32
+--rw vpn-attachment
+--rw (attachment-flavor)
+--:(vpn-policy-id)
| +--rw vpn-policy-id? leafref
+--:(vpn-id)
+--rw vpn-id? leafref
+--rw site-role? identityref6.1. Features and Augmentation ✨
okay so the model in this doc is built like a Lego set 🧱 with a bunch of features you can switch on or off, so implementations can be modular. 💖 For example, an implementation can do only IPv4 VPNs (the IPv4 feature), only IPv6 VPNs (the IPv6 feature), or both by advertising both features. 🌈 The routing protocols offered to the customer can also be turned on through features. 🔥 The model also has features for fancier stuff like extranet VPNs (Section 6.2.4), site diversity (Section 6.6), and QoS (Section 6.12.3). 💅
and literally, just like any YANG data model, this service model can be augmented to add new behaviors or specific features. 🦋 Like, this model gives you a few different options for IP address assignments. If those options don't cover everything you need, you can add new ones through augmentation. 🧚
6.2. VPN Service Overview 🌸
a vpn-service list item holds the generic info about the VPN service. 🎀 The "vpn-id" in that list is an internal reference for this VPN service, and the customer name is a more-explicit reference to the customer. 💜 This identifier is purely internal to the organization that runs the VPN service, so it's not for the customer to see. 🙈
6.2.1. VPN Service Topology 🦋
the VPN service topology type is required for configuration. 🫶 Our model supports any-to-any, Hub and Spoke (where Hubs can exchange traffic), and "Hub and Spoke disjoint" (where Hubs cannot exchange traffic). ✨ New topologies can be added via augmentation. By default, the any-to-any VPN service topology is used. 💖
6.2.1.1. Route Target Allocation 👑
okay this one is a whole thing 😭 A Layer 3 PE-based VPN is built using route targets (RTs), as described in [RFC4364]. The management system is expected to automatically allocate a set of RTs as soon as it gets a VPN service creation request. How the management system allocates RTs is out of scope for this document, but there are multiple ways it could be done, as shown below. 🧚
Management system
<------------------------------------------------->
Request RT
+-----------------------+ Topo a2a +----------+
RESTCONF | | -----> | |
User ------------- | Service Orchestration | | Network |
l3vpn-svc | | <----- | OSS |
Model +-----------------------+ Response +----------+
RT1, RT2in the example above, a service orchestration (the thing that owns the instantiation of this service model) requests RTs from the network OSS. 💅 Based on the requested VPN service topology, the network OSS replies with one or multiple RTs. 🌈 The interface between this service orchestration and the network OSS is out of scope for this document. 🙈
+---------------------------+
RESTCONF | |
User ------------- | Service Orchestration |
l3vpn-svc | |
Model | |
| RT pool: 10:1->10:10000 |
| RT pool: 20:50->20:5000 |
+---------------------------+in this one, the service orchestration (again, the owner of this service model instance) has one or more pools of RTs, specified by the SP, that can be handed out. 🍓 Based on the requested VPN service topology, it will allocate one or multiple RTs from the pool. ✨
the mechanisms shown above are just examples, so they should not be considered an exhaustive list of solutions. 💜
6.2.1.2. Any-to-Any 🌍
+------------------------------------------------------------+
| VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 |
| |
| VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 |
+------------------------------------------------------------+
Any-to-Any VPN Service Topologyin the any-to-any topology, all VPN sites can talk to each other with zero restrictions 🫶 The management system that gets an any-to-any IP VPN service request through this model is expected to assign and then configure the VRF and RTs on the right PEs. 🔥 In the any-to-any case, a single RT is generally required, and every VRF imports and exports this RT. 💖
6.2.1.3. Hub and Spoke 🌟
+-------------------------------------------------------------+
| Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
| +----------------------------------+
| |
| +----------------------------------+
| Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+
Hub-and-Spoke VPN Service Topologyin the Hub-and-Spoke topology, all Spoke sites can only talk to Hub sites, not to each other 🙈 but Hubs can also talk to each other 💜 The management system that owns an any-to-any IP VPN service request through this model is expected to assign and then configure the VRF and RTs on the appropriate PEs. 👑 In the Hub-and-Spoke case, two RTs are generally required: one RT for Hub routes and one RT for Spoke routes. 🎀 A Hub VRF (the one connecting Hub sites) exports Hub routes with the Hub RT and imports Spoke routes through the Spoke RT. It also imports the Hub RT so Hub-to-Hub communication works. 🦋 A Spoke VRF (the one connecting Spoke sites) exports Spoke routes with the Spoke RT and imports Hub routes through the Hub RT. ✨
⚠️ bestie, this is the important bit: the management system MUST take into account constraints on Hub-and-Spoke connections. 😭 For example, if it decides to mesh a Spoke site and a Hub site on the same PE, it needs to mesh the connections in different VRFs, as shown in the figure below. 💀
Hub_Site ------- (VRF_Hub) PE1
(VRF_Spoke)
/ |
Spoke_Site1 -------------------+ |
|
Spoke_Site2 -----------------------+6.2.1.4. Hub and Spoke Disjoint 🍓
+-------------------------------------------------------------+
| Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
+--------------------------+ +-------------------------------+
| |
+--------------------------+ +-------------------------------+
| Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+
Hub and Spoke Disjoint VPN Service Topologyin the Hub and Spoke disjoint topology, all Spoke sites can only talk to Hub sites, not to each other, and Hubs cannot talk to each other either 🌸 The management system that owns an any-to-any IP VPN service request through this model is expected to assign and then configure the VRF and RTs on the right PEs. 💅 In the Hub-and-Spoke case, two RTs are required: one RT for Hub routes and one RT for Spoke routes. 🎀 A Hub VRF that connects Hub sites exports Hub routes with the Hub RT and imports Spoke routes through the Spoke RT. 🦋 A Spoke VRF that connects Spoke sites exports Spoke routes with the Spoke RT and imports Hub routes through the Hub RT. 🫶
the management system MUST take into account constraints on Hub-and-Spoke connections, same as in the previous case. 👑
honestly, Hub and Spoke disjoint can also be seen as multiple Hub-and-Spoke VPNs (one per Hub) that share a common set of Spoke sites. 🧚✨
6.2.2. Cloud Access ☁️
okay bestie, cloud access is how a VPN gets to hang with the cloud 🌤️ The model handles it through the "cloud-accesses" container 💖. It's targeted at the public cloud, and ngl, Internet access counts as a public cloud access service too 🌐. The cloud-accesses container holds the parameters for network address translation and the authorization rules ✨.
Private cloud access goes through NNIs instead, as described in Section 6.15 🔗.
Every cloud gets a cloud identifier so the service can be referenced 🪪. That identifier is local to each administration, so it only needs to make sense inside the one doing the configuring 💅.
Now the translation part 🔄. The model lets you do source address translation before accessing the cloud. IPv4-to-IPv4 address translation (NAT44) is the only supported option, but other options can be added through augmentation 🧩. If IP source address translation is needed to reach the cloud, the "enabled" leaf MUST be set to true in the "nat44" container 🙌. You can put an IP address in the "customer-address" leaf if the customer is providing the address to use for the cloud access. If the SP is providing it, "customer-address" isn't necessary, since the address can be picked from a pool of SPs 🏊.
Authorization is next, and this is giving main character energy 👑. By default, all sites in the IP VPN MUST be authorized to access the cloud, periodt 💅. If you need restrictions, a user MAY configure the "permit-site" or "deny-site" leaf-list. The permit-site leaf-list is the list of sites authorized for cloud access 🫶. The deny-site leaf-list is the list of sites denied cloud access 🚫. The model supports both "deny-any-except" and "permit-any-except" authorization ✨.
How those restrictions get configured on network elements is out of scope for this doc 🙈.
IP VPN
++++++++++++++++++++++++++++++++ ++++++++++++
+ Site 3 + --- + Cloud 1 +
+ Site 1 + ++++++++++++
+ +
+ Site 2 + --- ++++++++++++
+ + + Internet +
+ Site 4 + ++++++++++++
++++++++++++++++++++++++++++++++
|
+++++++++++
+ Cloud 2 +
+++++++++++In the example above, we set up the global VPN to reach the Internet by creating a cloud-access that points at the cloud identifier for the Internet service 🌍. No authorized sites get configured here, because all sites are required to access the Internet. The "address-translation/nat44/enabled" leaf gets set to true 🎀.
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>INTERNET</cloud-identifier>
<address-translation>
<nat44>
<enabled>true</enabled>
</nat44>
</address-translation>
</cloud-access>
</cloud-accesses>
</vpn-service>
</vpn-services>
</l3vpn-svc>If Site 1 and Site 2 need access to Cloud 1, a new cloud-access gets created that points at the cloud identifier of Cloud 1 🦋. The permit-site leaf-list gets filled with references to Site 1 and Site 2 🌸.
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>Cloud1</cloud-identifier>
<permit-site>site1</permit-site>
<permit-site>site2</permit-site>
</cloud-access>
</cloud-accesses>
</vpn-service>
</vpn-services>
</l3vpn-svc>If every site except Site 1 needs Cloud 2, a new cloud-access pointing at the cloud identifier of Cloud 2 gets created 🧚. The deny-site leaf-list gets filled with a reference to Site 1 🙅♀️.
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>Cloud2</cloud-identifier>
<deny-site>site1</deny-site>
</cloud-access>
</cloud-accesses>
</vpn-service>
</vpn-services>
</l3vpn-svc>Here's the tea 🫖: a service with more than one cloud access is functionally identical to multiple services that each have a single cloud access, where the sites in each of those services match the authorized sites for each cloud access in the single service. That said, defining one service with multiple cloud accesses may be operationally simpler 🧠✨.
6.2.3. Multicast Service 📡
Multicast in IP VPNs is described in [RFC6513] 💜.
If an IP VPN needs multicast support, some global multicast parameters are required as input for the service request 🎶.
Users of this model need to provide the flavors of trees that customers within the IP VPN will use (the customer tree) 🌳. The model supports bidirectional, shared, and source-based trees, and it can be augmented. Multiple flavors of trees can be supported at the same time 🤩.
Operator network
______________
/ \
| |
(SSM tree) |
Recv (IGMPv3) -- Site2 ------- PE2 |
| PE1 --- Site1 --- Source1
| | \
| | -- Source2
| |
(ASM tree) |
Recv (IGMPv2) -- Site3 ------- PE3 |
| |
(SSM tree) |
Recv (IGMPv3) -- Site4 ------- PE4 |
| / |
Recv (IGMPv2) -- Site5 -------- |
(ASM tree) |
| |
\_______________/When an ASM flavor is requested, this model requires that the "rp" and "rp-discovery" parameters be filled 🔥. You can create multiple RP-to-group mappings using the "rp-group-mappings" container 🗺️. For each mapping, the SP can manage the RP service by setting the "provider-managed/enabled" leaf to true 🫡. For a provider-managed RP, the user can ask for RP redundancy and/or optimal traffic delivery 💫. Those parameters help the SP pick the right technology or architecture for the customer's needs. For example, if the customer asks for optimal traffic delivery, an SP may use Anycast-RP or RP-tree-to-SPT switchover architectures 🦋.
For a customer-managed RP, the RP address must be filled in the RP-to-group mappings using the "rp-address" leaf 📮. This leaf isn't needed for a provider-managed RP 🙅♀️.
Users can define a specific mechanism for RP discovery, like the "auto-rp", "static-rp", or "bsr-rp" modes 🔍. By default, the model uses "static-rp" if ASM is requested 🎀. A single rp-discovery mechanism is allowed for the VPN. The "rp-discovery" container can be used for both provider-managed and customer-managed RPs 🌈. For a provider-managed RP that wants "bsr-rp" as its discovery protocol, an SP should consider the provider-managed "rp-group-mappings" for the "bsr-rp" configuration. The SP will then configure its selected RPs to be "bsr-rp-candidates" 🧁. For a customer-managed RP using the "bsr-rp" discovery mechanism, the "rp-address" provided becomes the bsr-rp candidate 🫶.
6.2.4. Extranet VPNs 🌉
Sometimes a particular VPN needs access to resources like servers, hosts, etc. that live outside of it 🖥️. Those resources might be located in another VPN 👀.
+-----------+ +-----------+
/ \ / \
Site A -- | VPN A | --- | VPN B | --- Site B
\ / \ / (Shared
+-----------+ +-----------+ resources)In the figure above, VPN B has some resources on Site B that need to be available to some customers/partners. VPN A has to be able to access those VPN B resources 🤝.
This connection can be set up with a VPN policy as defined in Section 6.5.2.2 📜. But for simpler cases, where a particular VPN (VPN A) needs access to all resources in another VPN (VPN B), the model gives you an easy shortcut using the "extranet-vpns" container ⚡.
The extranet-vpns container defines a list of VPNs that a particular VPN wants to access 💌. It must be used on customer VPNs that access extranet resources in another VPN. In the figure above, to give VPN A access to VPN B, the extranet-vpns container needs to be configured under VPN A with an entry for VPN B. VPN B doesn't need any service configuration 💅.
Heads up 🚨: even if VPN B has no configuration requirement, if VPN A lists VPN B as an extranet, all sites in VPN B will gain access to all sites in VPN A. no cap, that's a big deal 😭.
The "site-role" leaf defines the role of the local VPN sites in the target extranet VPN service topology. Site roles are defined in Section 6.4, and the requirements in Section 6.4 about the site-role leaf apply here too 🦋.
In the example below, VPN A accesses VPN B resources through an extranet connection. VPN A sites need a Spoke role, because sites from VPN A must not be able to communicate with each other through the extranet VPN connection 🙈.
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNB</vpn-id>
<vpn-service-topology>hub-spoke</vpn-service-topology>
</vpn-service>
<vpn-service>
<vpn-id>VPNA</vpn-id>
<vpn-service-topology>any-to-any</vpn-service-topology>
<extranet-vpns>
<extranet-vpn>
<vpn-id>VPNB</vpn-id>
<local-sites-role>spoke-role</local-sites-role>
</extranet-vpn>
</extranet-vpns>
</vpn-service>
</vpn-services>
</l3vpn-svc>This model doesn't define how the extranet configuration gets achieved 🤷♀️.
Anything more complex, like only certain parts of sites on VPN A accessing only certain parts of sites on VPN B, needs a VPN attachment as defined in Section 6.5.2, and especially a VPN policy as defined in Section 6.5.2.2 🧩💖.
6.3. Site Overview ✨
okay bestie, a site is basically a customer office plugging into one or more VPN services 🏢💖 Every site is tied to one or more locations 📍
+-------------+
/ \
+------------------+ +-----| VPN1 |
| | | \ /
| New York Office |------ (site) -----+ +-------------+
| | | +-------------+
+------------------+ | / \
+-----| VPN2 |
\ /
+-------------+a site has a few main characteristics, and they're giving very organized energy 🎀
- Unique identifier (
site-id) 🆔: this uniquely identifies the site across the whole network infrastructure. It's a string, so any encoding works for the local administration of the VPN service. - Locations (
locations) 📍: site location info that makes it easy to pull up the nearest available resources. A site can have multiple locations. You can also put two or more sites at the same location by referencing the same location ID. - Devices (
devices) 🧰: lets the customer request one or more customer premises equipment entities from the SP for a particular site. - Management (
management) 🧑💻: defines the management type for the site, like co-managed, customer-managed, or provider-managed. See Section 6.10. - Site network accesses (
site-network-accesses) 🔌: the list of network accesses tied to the sites, plus their properties, especially the bearer, connection, and service parameters.
a site-network-access is an IP logical connection of a site 💅 A site can have multiple site-network-accesses, no cap.
+------------------+ Site
| |-----------------------------------
| |****** (site-network-access#1) ******
| New York Office |
| |****** (site-network-access#2) ******
| |-----------------------------------
+------------------+multiple site-network-accesses show up for things like multihoming 🙌 Some other meshing cases can also have multiple site-network-accesses.
the site config is treated as one global entity, and we assume the management system is the one that splits the parameters across the different elements in the network 🧠 For example, for site-network-access config, the management system has to divide the overall parameters between the PE configuration and the CE configuration. it's giving teamwork 🫶
6.3.1. Devices and Locations
a site can be made up of multiple locations, and all of them need to be configured inside the locations container and list 🏙️ A classic example is a headquarters office in a city made of multiple buildings. Those buildings might be spread across different parts of the city and linked by intra-city fibers (the customer metropolitan area network). In that case, when connecting to a VPN service, the customer may ask for multihoming based on their distributed locations, which is so smart ✨
New York Site
+------------------+ Site
| +--------------+ |-----------------------------------
| | Manhattan | |****** (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Brooklyn | |****** (site-network-access#2) ******
| +--------------+ |
| |-----------------------------------
+------------------+a customer can also request some premises equipment entities (CEs) from the SP through the devices container 📦 Requesting a CE implies a provider-managed or co-managed model. A particular device must be ordered to a particular location that's already configured. That helps the SP ship it to the right postal address 📬 In a multi-location site, a customer might request a CE for each location where multihoming needs to happen. In the figure above, one device could be requested for the Manhattan location and one more for the Brooklyn location.
by using devices and locations together, the user gets to shape the multihoming scenario they want, like a single CE, dual CE, and so on 💜
6.3.2. Site Network Accesses
like we said earlier, a site may be multihomed 🔁 Each IP network access for a site is defined in the site-network-accesses container. The site-network-access parameter defines how the site connects to the network, and it's split into three main classes of parameters:
bearer: defines requirements of the attachment (below Layer 3).connection: defines Layer 3 protocol parameters of the attachment.availability: defines the site's availability policy. The availability parameters are defined in Section 6.7.
a site-network-access has a specific type (site-network-access-type) 🎀 This document defines two types:
point-to-point: describes a point-to-point connection between the SP and the customer.multipoint: describes a multipoint connection between the SP and the customer.
the type can change which parameters get offered to the customer 👀 For example, an SP may not offer encryption for multipoint accesses. It's up to the provider to decide which parameters are supported for point-to-point and/or multipoint accesses, and that topic is out of scope for this document 🙅♀️ Some containers in the model might need extensions to work properly for multipoint accesses.
6.3.2.1. Bearer
the bearer container defines the requirements for the site attachment to the provider network that are below Layer 3 🧱 The bearer parameters help determine which access media gets used. This is covered further in Section 6.6.3.
6.3.2.2. Connection
the ip-connection container defines the protocol parameters of the attachment (IPv4 and IPv6) 🌐 Depending on the management mode, it refers to either PE-CE addressing or CE-to-customer-LAN addressing. Either way, it describes the responsibility boundary between the provider and the customer. For a customer-managed site, it refers to the PE-CE connection. For a provider-managed site, it refers to the CE-to-LAN connection. ✨
6.3.2.2.1. IP Addressing
an IP subnet can be configured for either IPv4 or IPv6 Layer 3 protocols. For a dual-stack connection, two subnets get provided, one for each address family 🦋
the address-allocation-type decides how the address allocation gets done. The current model defines five ways to do IP address allocation:
provider-dhcp: the provider provides DHCP service for customer equipment. This applies to either theIPv4container or theIPv6container.provider-dhcp-relay: the provider provides DHCP relay service for customer equipment. This applies to both IPv4 and IPv6 addressing. The customer needs to populate the DHCP server list to be used.static-address: addresses get assigned manually. This applies to both IPv4 and IPv6 addressing.slaac: this parameter enables stateless address autoconfiguration [RFC4862]. It applies to IPv6 only.provider-dhcp-slaac: the provider provides DHCP service for customer equipment, plus stateless address autoconfiguration. This applies to IPv6 only.
with dynamic addressing, the SP is expected to provide at least the IP address, prefix length, and default gateway information 🧭 And when multiple site-network-access points belong to the same VPN, the address space allocated for one site-network-access should not conflict with the one allocated for the other site-network-accesses 🚫💥
6.3.2.2.2. OAM
a customer may need a specific IP connectivity fault detection mechanism on the IP connection 🔍 The model supports BFD as a fault detection mechanism, and it can be extended with other mechanisms through augmentation. The provider can propose some profiles to the customer depending on the service level the customer wants, and profile names must be communicated to the customer. How that communication happens is out of scope for this document 📣 Some fixed values for the holdtime period may also be imposed by the customer, if the provider allows the customer to do that.
the oam container can easily be augmented by other mechanisms 🛠️ In particular, work done by the LIME Working Group (https://datatracker.ietf.org/wg/lime/charter/) may be reused in applicable scenarios. iykyk 😌
6.3.2.3. Inheritance of Parameters Defined at Site Level and Site Network Access Level
some parameters can be configured at both the site level and the site-network-access level, like routing, services, and security 🔀 Inheritance applies when parameters are defined at the site level. If a parameter is configured at both the site level and the access level, the access-level parameter MUST override the site-level parameter 👑 Those parameters get described later in this document.
Heads up: the provisioning impact is up to the implementation. It decides what happens when existing configurations get modified. But the SP will need to tell the user about the impact of using inheritance 📢
For example, say a site already has three site-network-accesses provisioned. What happens if a customer changes a service parameter at the site level? An implementation of this model might update the service parameters of all the already-provisioned site-network-accesses (with potential impact on live traffic), or it might only take the new parameter into account for new sites 😳
6.4. Site Role
a VPN has a particular service topology, as described in Section 6.2.1, so every site in a VPN gets a particular role in that topology 🎭 The site-role leaf defines the role of the site in a particular VPN topology.
in the any-to-any VPN service topology, all sites MUST have the same role, which will be "any-to-any-role" 🌐
in the Hub-and-Spoke VPN service topology or the Hub and Spoke disjoint VPN service topology, sites MUST have a Hub role or a Spoke role 🌟
6.5. Site Belonging to Multiple VPNs
6.5.1. Site VPN Flavor
a site can be part of one VPN or multiple VPNs 🌸 The site-vpn-flavor defines the way the VPN multiplexing is done. The current version of the model supports four flavors:
site-vpn-flavor-single: the site belongs to only one VPN.site-vpn-flavor-multi: the site belongs to multiple VPNs, and all the logical accesses of the site belong to the same set of VPNs.site-vpn-flavor-sub: the site belongs to multiple VPNs with multiple logical accesses. Each logical access may map to different VPNs (one or many).site-vpn-flavor-nni: the site represents an option A NNI.
6.5.1.1. Single VPN Attachment: site-vpn-flavor-single 🎀
okay so this first one is the simplest, bestie 💖 The figure below shows a single VPN attachment, meaning the site only hooks up to one VPN. Easy peasy 🌸
+--------+
+------------------+ Site / \
| |-----------------------------| |
| |***(site-network-access#1)***| VPN1 |
| New York Office | | |
| |***(site-network-access#2)***| |
| |-----------------------------| |
+------------------+ \ /
+--------+6.5.1.2. MultiVPN Attachment: site-vpn-flavor-multi 🦋
this one is giving main character energy 👑 The figure below shows a site connected to multiple VPNs.
+---------+
+---/----+ \
+------------------+ Site / | \ |
| |--------------------------------- | |VPN B|
| |***(site-network-access#1)******* | | |
| New York Office | | | | |
| |***(site-network-access#2)******* \ | /
| |-----------------------------| VPN A+-----|---+
+------------------+ \ /
+--------+In the example above, the New York office is multihomed 🙈 Both logical accesses use the same VPN attachment rules, and both are connected to VPN A and VPN B.
Reaching VPN A or VPN B from the New York office is done via destination-based routing. Having the same destination reachable from the two VPNs may cause routing troubles 💀 So the customer administration's job here is to make sure its prefixes are mapped properly in each VPN. Protect that mapping like it's your jewelry 💅
6.5.1.3. SubVPN Attachment: site-vpn-flavor-sub ✨
so a subVPN is when the site connects to multiple VPNs, but each logical access is attached to its own particular set of VPNs 🧚 A typical use case is a customer site used by multiple affiliates, each with private resources that can't be shared (communication between the affiliates is prevented). It's kinda like having separate sites, except the customer can share some physical components at one location while keeping strong communication isolation between the affiliates 🫶 In this example, site-network-access#1 is attached to VPN B, while site-network-access#2 is attached to VPN A.
+------------------+ Site +--------+
| |----------------------------------/ \
| |****(site-network-access#1)******| VPN B |
| New York Office | \ /
| | +--------+
| | +--------+
| | / \
| |****(site-network-access#2)******| VPN A |
| | \ /
| | +--------+
| |-----------------------------------
+------------------+A multiVPN can be implemented in addition to a subVPN, so each site-network-access can access multiple VPNs too 🌈 In the example below, site-network-access#1 is mapped to VPN B and VPN C, while site-network-access#2 is mapped to VPN A and VPN D.
+-----------------+ Site +------+
| |--------------------------------/ +-----+
| |****(site-network-access#1)****| VPN B / \
| New York Office | \ | VPN C |
| | +-----\ /
| | +-----+
| |
| | +-------+
| | / +-----+
| |****(site-network-access#2)****| VPN A / \
| | \ | VPN D |
| | +------\ /
| |--------------------------------- +-----+
+-----------------+Multihoming also works with subVPNs 🍓 In this case, site-network-accesses get grouped, and a particular group has access to the same set of VPNs. In the example below, site-network-access#1 and site-network-access#2 are part of the same group (multihomed together) and are mapped to VPN B and VPN C. Then, site-network-access#3 and site-network-access#4 are part of their own group (multihomed together) and are mapped to VPN A and VPN D. the grouping is everything 😭
+-----------------+ Site +------+
| |---------------------------------/ +-----+
| |****(site-network-access#1)*****| VPN B / \
| New York Office |****(site-network-access#2)***** \ | VPN C |
| | +-----\ /
| | +-----+
| |
| | +------+
| | / +-----+
| |****(site-network-access#3)*****| VPN A / \
| |****(site-network-access#4)***** \ | VPN D |
| | +-----\ /
| |---------------------------------- +-----+
+-----------------+In terms of service configuration, a subVPN can be achieved by requesting that the site-network-access use the same bearer (see Section 6.6.4 for more details). ✨
6.5.1.4. NNI: site-vpn-flavor-nni 🔥
okay this one's a bit different, so pay attention 🧐 A Network-to-Network Interface (NNI) scenario may be modeled using the sites container (see Section 6.15.1). Using the sites container to model an NNI is only one possible option for NNIs (see Section 6.15). This option is called "option A," named after the option A NNI defined in [RFC4364]. It's helpful for the SP to indicate that the requested VPN connection is not a regular site but rather an NNI, because specific default device configuration parameters may be applied to NNIs (e.g., ACLs, routing policies) 💜
SP A SP B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + |
| + (VRF2)---(VPN2)----(VRF2) + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + |
| + (VRF2)---(VPN2)----(VRF2) + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------The figure above shows an option A NNI scenario that can be modeled using the sites container. To connect its customer VPNs (VPN1 and VPN2) in SP B, SP A may request the creation of some site-network-accesses to SP B. The site-vpn-flavor-nni will be used to tell SP B that this is an NNI and not a regular customer site. The site-vpn-flavor-nni may be multihomed and multiVPN as well 🦋
6.5.2. Attaching a Site to a VPN 🌸
so because there are multiple site-vpn flavors, attaching a site to an IP VPN happens at the site-network-access (logical access) level, through the vpn-attachment container 🧚 The vpn-attachment container is mandatory. The model gives you two ways to attach a site to a VPN:
- By referencing the target VPN directly.
- By referencing a VPN policy for attachments that are more complex.
A choice is implemented so the user can pick whichever flavor fits best 💅
6.5.2.1. Referencing a VPN
Okay bestie, referencing a vpn-id is the easy-peasy way to plug a logical access into a VPN ✨. It's the move for a single VPN attachment, or for a subVPN where each logical access only belongs to one VPN 💅. When you reference a vpn-id, you also have to add the site-role setting so everyone knows what role the site plays in that target VPN service topology 🎀.
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
<vpn-service>
<vpn-id>VPNB</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>LA1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>LA2</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>This XML is giving subVPN realness 🦋. SITE1 has two logical accesses, LA1 and LA2, with LA1 attached to VPNA and LA2 attached to VPNB 💜.
6.5.2.2. VPN Policy
The "vpn-policy" list is the go-to for a multiVPN situation where one logical access belongs to multiple VPNs 🌈. You can make several VPN policies for a subVPN case where each logical access is part of a different set of VPNs 💖.
Since a site can belong to multiple VPNs, the vpn-policy list can have several entries 🧚. A filter can narrow things down so only some LANs of the site join a particular VPN 🎀. Every time a site (or LAN) gets attached to a VPN, you need to spell out its role (site-role) in that target VPN service topology 🙈.
+--------------------------------------------------------------+
| Site1 ------ PE7 |
+-------------------------+ (VPN2) |
| |
+-------------------------+ |
| Site2 ------ PE3 PE4 ------ Site3 |
+----------------------------------+ |
| |
+------------------------------------------------------------+ |
| Site4 ------ PE5 | PE6 ------ Site5 | |
| | |
| (VPN3) | |
+------------------------------------------------------------+ |
| |
+---------------------------+In the diagram above, Site5 is part of two VPNs: VPN3 and VPN2 👑. It plays a Hub role in VPN2 and an any-to-any role in VPN3 🔥. Here's how that multiVPN scenario looks in XML:
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPN2</vpn-id>
</vpn-service>
<vpn-service>
<vpn-id>VPN3</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>Site5</site-id>
<devices>
<device>
<device-id>D1</device-id>
</device>
</devices>
<management>
<type>provider-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<vpn-policies>
<vpn-policy>
<vpn-policy-id>POLICY1</vpn-policy-id>
<entries>
<id>ENTRY1</id>
<vpn>
<vpn-id>VPN2</vpn-id>
<site-role>hub-role</site-role>
</vpn>
</entries>
<entries>
<id>ENTRY2</id>
<vpn>
<vpn-id>VPN3</vpn-id>
<site-role>any-to-any-role</site-role>
</vpn>
</entries>
</vpn-policy>
</vpn-policies>
<site-network-accesses>
<site-network-access>
<site-network-access-id>LA1</site-network-access-id>
<device-reference>D1</device-reference>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>Now, if you need a more granular VPN attachment, filtering is your bestie 🫶. Say only LAN1 from Site5 should attach to VPN2 as a Hub, and only LAN2 should attach to VPN3. Then this XML does the trick:
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPN2</vpn-id>
</vpn-service>
<vpn-service>
<vpn-id>VPN3</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>Site5</site-id>
<vpn-policies>
<vpn-policy>
<vpn-policy-id>POLICY1</vpn-policy-id>
<entries>
<id>ENTRY1</id>
<filters>
<filter>
<type>lan</type>
<lan-tag>LAN1</lan-tag>
</filter>
</filters>
<vpn>
<vpn-id>VPN2</vpn-id>
<site-role>hub-role</site-role>
</vpn>
</entries>
<entries>
<id>ENTRY2</id>
<filters>
<filter>
<type>lan</type>
<lan-tag>LAN2</lan-tag>
</filter>
</filters>
<vpn>
<vpn-id>VPN3</vpn-id>
<site-role>any-to-any-role</site-role>
</vpn>
</entries>
</vpn-policy>
</vpn-policies>
<site-network-accesses>
<site-network-access>
<site-network-access-id>LA1</site-network-access-id>
<vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>6.6. Deciding Where to Connect the Site
The management system has to figure out where to plug each site-network-access of a given site into the provider network (e.g., PE, aggregation switch) 🍓.
The current model defines parameters and constraints that can influence how the site-network-access gets meshed 🕸️.
The management system MUST honor all customer constraints 💅. If a constraint is too strict and can't be fulfilled, the management system MUST NOT provision the site, and it MUST tell the user which constraints couldn't be met 😭. How that information gets provided is out of scope for this document. Whether to relax the constraint is then left up to the user 🫶.
Parameters such as site location (see Section 6.6.2) and access type are just hints (see Section 6.6.3) for the management system when it's deciding service placement 🧚.
On top of parameters and constraints, the management system's decision MAY be based on any other internal constraints the SP cares about: least load, distance, etc. 🌸
6.6.1. Constraint: Device
When it's provider management or co-management, the customer can have ordered one or more devices to a particular, already-configured location 🏢. The customer can force a particular site-network-access to be connected on a particular device they ordered 🎯.
New York Site
+------------------+ Site
| +--------------+ |-----------------------------------
| | Manhattan | |
| | CE1********* (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Brooklyn CE2********* (site-network-access#2) ******
| +--------------+ |
| |-----------------------------------
+------------------+In the figure above, site-network-access#1 is associated with CE1 in the service request 💖. The SP has to make sure this connection actually gets provisioned 🫶✨.
6.6.2. Constraint/Parameter: Site Location 📍✨
Okay so, the location info in this model MAY be used by a management system to figure out which target PE to mesh the site with (SP side) 🗺️. When you configure each site network access, you have to attach a location to it. The SP MUST honor the termination of the access on the location associated with the site network access (customer side) 🫶. And the "country-code" in the site location SHOULD be expressed as an ISO ALPHA-2 code 🌍💅.
So the site-network-access location is decided by the "location-flavor" 💖. If it's a provider-managed or co-managed site, the user is expected to configure a "device-reference" (device case) 🎀. That binds the site-network-access to a specific device the customer ordered. Each device already has a location, so the location info just gets pulled from the device's location 🧚. If it's a customer-managed site, the user is expected to configure a "location-reference" (location case) 🌸. That points at an existing configured location and helps with placement 📌.
Look at this diagram, it's giving serious map energy 🗺️🦋:
POP#1 (New York)
+---------+
| PE1 |
Site #1 ---... | PE2 |
(Atlantic City) | PE3 |
+---------+
POP#2 (Washington)
+---------+
| PE4 |
| PE5 |
| PE6 |
+---------+
POP#3 (Philadelphia)
+---------+
| PE7 |
Site #2 CE#1---... | PE8 |
(Reston) | PE9 |
+---------+So in this example 💅, Site #1 is a customer-managed site with location L1, and Site #2 is a provider-managed site where they ordered a CE (CE#1) 🙈. Site #2 is configured with L2 as its location 📍. When you set up a site-network-access for Site #1, you need to reference L1 so the management system knows the access has to terminate there 💖. Then, for distance reasons, the management system might mesh Site #1 on a PE in the Philadelphia POP 🦋. It can also look at which PEs have resources available to pick the exact target PE, like the least loaded one 🌈.
For Site #2, the user should configure the site-network-access with a device-reference to CE#1 💜. That way the management system knows the access must terminate on CE#1's location and must be connected to CE#1 🫶. For placing the SP side of the access connection, if it uses the nearest PE, it might mesh Site #2 on the Washington POP ✨.
6.6.3. Constraint/Parameter: Access Type 🦋
The management system has to pick the access media used to connect the site to the customer (for example, xDSL, leased line, Ethernet backhaul) 🔌. The customer can give some parameters or constraints that act as hints for the management system 💡.
The bearer container information SHOULD be the first thing considered when making this decision 🎀:
o The "requested-type" parameter tells the management system which media type the customer would like to use 🌸. If the "strict" leaf is equal to "true", that MUST be treated as a strict constraint, so the management system cannot connect the site with another media type 🚫. If the "strict" leaf is equal to "false" (default) and the requested media type can't be fulfilled, the management system can pick another media type 💅. The SP SHOULD communicate the supported media types to the customer through a mechanism that is out of scope for this document 📬.
o The "always-on" leaf is a strict constraint ⭐: if it's set to true, the management system MUST elect a media type that is "always-on" (so no dial access type, bestie) 📞🚫.
o The "bearer-reference" parameter is for when the customer already ordered a network connection to the SP separate from the IP VPN site and wants to reuse it 🔁. The string is an internal reference from the SP that describes the already-available connection 🧾. This is also a strict requirement that can't be relaxed 🔒. How the reference gets given to the customer is out of scope for this document 🙈. As a pure example, when the customer ordered the bearer (through a process that's also out of scope for this model), the SP may have provided the bearer reference to use for provisioning services on top 🎁.
Any other internal parameters from the SP can also be used 🧩. The management system MAY use other parameters, like the requested "svc-input-bandwidth" and "svc-output-bandwidth", to help decide which access type to use 📊✨.
6.6.4. Constraint: Access Diversity 🌈
Each site-network-access may have one or more constraints that drive where the access gets placed 📍. By default, the model assumes there are no constraints, but each site-network-access is expected to get a unique bearer 💜.
To help with the different placement scenarios, a site-network-access may be tagged with one or multiple group identifiers 🏷️. A group identifier is a string, so it can hold explicit names for a group of sites (e.g., "multihomed-set1" or "subVPN") or a numbered identifier (e.g., 12345678) 🔢. The meaning of each group-id is local to each customer administrator, and the management system MUST ensure that different customers can use the same group-ids 🙌. Group-ids can also be defined at the site level, and as a result, all site-network-accesses under the site MUST inherit the group-ids of the site they belong to 👑. When some group-ids are defined at the site-network-access level in addition to the site group-ids, the management system MUST consider the union of all groups (site level and site network access level) for that site-network-access 🫧.
For an already-configured site-network-access, each constraint MUST be expressed against a targeted set of site-network-accesses 🎯. That site-network-access MUST never be counted in the targeted set 🙅♀️ -- for example, "My site-network-access S must not be connected on the same POP as the site-network-accesses that are part of Group 10." 💀. The set of site-network-accesses the constraint is checked against can be a list of groups, "all-other-accesses", or "all-other-groups" 📋. The all-other-accesses option means the constraint MUST be evaluated against all the other site-network-accesses in the current site 🔍. The all-other-groups option means the constraint MUST be evaluated against all groups that the current site-network-access does not belong to 🧐.
The current model defines multiple constraint-types 🧠:
o pe-diverse: The current site-network-access MUST NOT be connected to the same PE as the targeted site-network-accesses 🚫.
o pop-diverse: The current site-network-access MUST NOT be connected to the same POP as the targeted site-network-accesses 🚫.
o linecard-diverse: The current site-network-access MUST NOT be connected to the same linecard as the targeted site-network-accesses 🚫.
o bearer-diverse: The current site-network-access MUST NOT use common bearer components compared to bearers used by the targeted site-network-accesses 🦋. "bearer-diverse" gives some level of diversity at the access level 🌸. For example, two bearer-diverse site-network-accesses must not use the same DSLAM, BAS, or Layer 2 switch 🙈.
o same-pe: The current site-network-access MUST be connected to the same PE as the targeted site-network-accesses 🤝.
o same-bearer: The current site-network-access MUST be connected using the same bearer as the targeted site-network-accesses 🤝.
These constraint-types can be extended through augmentation 🧩.
Each constraint is expressed as "The site-network-access S must be <constraint-type> (e.g., pe-diverse, pop-diverse) from these <target> site-network-accesses." 📝
The group-id used to target some site-network-accesses may be the same as the one used by the current site-network-access 💞. This makes it easier to set up scenarios where a group of access points has a constraint between the points in that group 🫶. For example, if we want a set of sites (Site#1 to Site#5) to be connected on different PEs, we can tag them with the same group-id and express a pe-diverse constraint for that group-id with this XML snippet 🎀:
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>SITE2</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>Okay so the XML picks up mid-snippet, so here's the rest of it 🧚
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
...
<site>
<site-id>SITE5</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>The group-id used to target some site-network-accesses can also be different from the one used by the current site-network-access 🦋 This is how you say "this group of sites has some constraints against another group of sites, but there's no constraint inside the group itself." Lowkey really useful. ✨
Here's the example, a set of six sites and two groups. We want a site in the first group to be pop-diverse from a site in the second group 💜
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>SITE2</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
...
<site>
<site-id>SITE5</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>SITE6</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>6.6.5. Infeasible Access Placement 🙈
Some infeasible access placement scenarios can be created through the proposed configuration framework, and ngl it's easy to do by accident 😭 They can come from constraints that are too restrictive, which makes access placement impossible on the network, or from conflicting constraints that also end up making placement impossible. For example, asking site-network-access#1 to be pe-diverse from site-network-access#2, while also asking site-network-access#2 to be on the same PE as site-network-access#1, is a direct contradiction. It's giving "can't have both" energy 💀
When the management system cannot determine the placement of a site-network-access, it MUST return an error message indicating that placement was not possible. No silent failures, periodt 🥲🎀
6.6.6. Examples of Access Placement 🦋
6.6.6.1. Multihoming 🌸
okay so the customer wants a multihomed site, and that's giving resiliency queen energy 👑. The site is made of two site-network-accesses, and for backup reasons they want those two accesses meshed on different POPs 🧚
POP#1
+-------+ +---------+
| | | PE1 |
| |---site-network-access#1----| PE2 |
| | | PE3 |
| | +---------+
| Site#1|
| | POP#2
| | +---------+
| | | PE4 |
| |---site-network-access#2----| PE5 |
| | | PE6 |
| | +---------+
+-------+This scenario can be expressed with the following XML snippet:
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>2</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>But it can also be expressed with the following XML snippet:
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<all-other-accesses/>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>2</site-network-access-id>
<access-diversity>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<all-other-accesses/>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>6.6.6.2. Site Offload 💅
the customer has six branch offices in one region, and he really doesn't want them all hanging off the same PE 🙈
He wants three of the branch offices to not be connected on the same linecard. The other branch offices must be connected on a different POP, and those other ones also can't be on the same linecard 💜
POP#1
+---------+
| PE1 |
Office#1 ---... | PE2 |
Office#2 ---... | PE3 |
Office#3 ---... | PE4 |
+---------+
POP#2
+---------+
Office#4 ---... | PE5 |
Office#5 ---... | PE6 |
Office#6 ---... | PE7 |
+---------+This scenario can be expressed as follows:
- We need to create two groups of sites: Group#10, which is composed of Office#1, Office#2, and Office#3; and Group#20, which is composed of Office#4, Office#5, and Office#6.
- Sites within Group#10 must be pop-diverse from sites within Group#20, and vice versa.
- Sites within Group#10 must be linecard-diverse from other sites in Group#10 (same for Group#20).
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>Office1</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office2</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office3</site-id>
<locations>
<location>
<location-id>L1</location-id> </location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office4</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office5</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office6</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>6.6.6.3. Parallel Links ✨
okay so bestie, a customer wants more site bandwidth but doesn't want the big price tag 💸. The move? Order two parallel site-network-accesses that both connect to the same PE router. It's giving smart upgrade energy 🔥.
Here's the diagram 🦋:
*******site-network-access#1**********
Site 1 *******site-network-access#2********** PE1And here's how that looks in XML 💅:
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNB</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>PE-linkgrp-1</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>same-pe</constraint-type>
<target>
<group>
<group-id>PE-linkgrp-1</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>2</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>PE-linkgrp-1</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>same-pe</constraint-type>
<target>
<group>
<group-id>PE-linkgrp-1</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>6.6.6.4. SubVPN with Multihoming ✨
okay so picture this: a customer has a site that's dual-homed 🏢, and the dual-homing must be done on two different PEs. On top of that, they want two subVPNs running over those multihomed accesses. bestie, it's giving layered 💅
The diagram below shows the New York Office with two subVPNs (B and C), each reached through a pair of accesses:
+-----------------+ Site +------+
| |---------------------------------/ +-----+
| |****(site-network-access#1)*****| VPN B / \
| New York Office |****(site-network-access#2)************| VPN C |
| | +-----\ /
| | +-----+
| |
| | +------+
| | / +-----+
| |****(site-network-access#3)*****| VPN B / \
| |****(site-network-access#4)************| VPN C |
| | +-----\ /
| |----------------------------------- +-----+
+-----------------+So here's the breakdown 🎀:
- The site ends up with four site network accesses. That's two subVPNs coupled through dual-homing, iconic ✨
site-network-access#1andsite-network-access#3are the multihoming pair for subVPN B. A PE-diverse constraint is required between them 🦋site-network-access#2andsite-network-access#4are the multihoming pair for subVPN C. Same deal, a PE-diverse constraint is required between them 🌸- For the subVPNs to use the same bearer properly,
site-network-access#1andsite-network-access#2must share the same bearer assite-network-access#3andsite-network-access#4. no cap, this is the part people mess up 🙈
Here's what the L3VPN service model looks like for this setup:
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNB</vpn-id>
</vpn-service>
<vpn-service>
<vpn-id>VPNC</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<management>
<type>customer-managed</type>
</management>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>dualhomed-1</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>dualhomed-2</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>same-bearer</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>2</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>dualhomed-1</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>dualhomed-2</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>same-bearer</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNC</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>3</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>dualhomed-2</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>same-bearer</constraint-type>
<target>
<group>
<group-id>dualhomed-2</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>4</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<access-diversity>
<groups>
<group>
<group-id>dualhomed-2</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>same-bearer</constraint-type>
<target>
<group>
<group-id>dualhomed-2</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNC</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>6.6.7. Route Distinguisher and VRF Allocation 🦋
okay this one is a whole vibe 🌈 the route distinguisher (RD) is a critical parameter for PE-based L3VPNs, as described in [RFC4364]. its whole job is letting you tell apart common addressing plans living in different VPNs, and it's giving very important energy 👑 just like route targets (RTs), a management system is expected to allocate a VRF on the target PE and an RD for that VRF.
if a VRF already exists on the target PE and it fulfills the connectivity constraints for the site, there's no need to recreate it. the site MAY be meshed within this existing VRF ✨ how the management system checks that an existing VRF actually fulfills those constraints is out of scope for this document, so no spoilers from me 🙈
if there's no such VRF on the target PE, the management system has to initiate creating a new VRF there, and it has to allocate a brand new RD for it 🌸
the management system MAY apply a per-VPN or per-VRF allocation policy for the RD, depending on the SP's policy 💖 in a per-VPN policy, all VRFs (spread across multiple PEs) within a VPN share the same RD value. in a per-VRF model, all VRFs should always have a unique RD value. other allocation policies are possible too, and this document doesn't restrict which ones get used 🧚
the allocation of RDs MAY be done the same way as RTs, and the examples in Section 6.2.1.1 could be reused in this scenario 🍓
and lastly, an SP MAY configure a target PE for automated allocation of RDs. if it does, there's no need for any backend system to allocate an RD value. no backend, no problem 💅✨
6.7. Site Network Access Availability 🌸
okay so a site can be multihomed, which just means it has multiple site-network-access points 🫶. The placement constraints from the earlier sections are gonna help make sure those accesses are physically diverse, no cap 💅.
When the site-network-accesses get placed on the network, a customer might wanna use a particular routing policy on those accesses 👑.
The "site-network-access/availability" container is where the parameters for site redundancy live 🦋. The "access-priority" leaf sets a preference for a particular access, and that preference is how you model load-balancing or primary/backup setups 🎀. The higher the access-priority value, the higher the preference, so it's giving simple ✨.
Here's the figure showing how access-priority works 🧚.
Hub#1 LAN (Primary/backup) Hub#2 LAN (Load-sharing)
| |
| access-priority 1 access-priority 1 |
|--- CE1 ------- PE1 PE3 --------- CE3 --- |
| |
| |
|--- CE2 ------- PE2 PE4 --------- CE4 --- |
| access-priority 2 access-priority 1 |
PE5
|
|
|
CE5
|
Spoke#1 site (Single-homed)In the figure above, Hub#2 needs load-sharing, so all the site-network-accesses must use the same access-priority value 🔥. Hub#1 is different, because it needs a primary site-network-access and a backup site-network-access, so the primary one gets a higher access-priority setting 💜.
Scenarios can get way more complex too 🌈. Imagine a Hub site with five accesses to the network (A1, A2, A3, A4, A5). The customer wants to load-share its traffic on A1 and A2 when everything's normal. If A1 and A2 fail, the customer wants to load-share on A3 and A4 instead. And if A1 through A4 are all down, they want to use A5. You can model that easily with these access-priority values: A1=100, A2=100, A3=50, A4=50, A5=10 🦋✨.
Okay, but the access-priority scenario has some limitations 🙈. A version of that five-access setup where traffic is load-shared between A3 and A4 when A1 OR A2 is down is not achievable. The authors still believe access-priority covers most deployment use cases, though, and that the model can be extended via augmentation to handle the rest 💖.
6.8. Traffic Protection 🛡️
The service model can protect the traffic for a site 🫶. That protection gives you better availability in multihoming scenarios, for example by using local-repair techniques when something fails. The level of service guarantee that goes with it would be based on an agreement between the customer and the SP, and that's out of scope for this document 💅.
Site#1 Site#2
CE1 ----- PE1 -- P1 P3 -- PE3 ---- CE3
| | |
| | |
CE2 ----- PE2 -- P2 P4 -- PE4 ---- CE4
/
/
CE5 ----+
Site#3In the figure above, we've got an IP VPN service with three sites, including two dual-homed sites (Site#1 and Site#2) 👑. For the dual-homed sites, we treat PE1-CE1 and PE3-CE3 as primary, and PE2-CE2 and PE4-CE4 as backup, just for the example (even though protection also applies to load-sharing scenarios) 🌸.
To protect Site#2 against a failure, a user can set the "traffic-protection/enabled" leaf to true for Site#2 💖. How the traffic protection actually gets implemented is out of scope for this document, but here's the vibe. Say traffic is coming from a remote site (Site#1 or Site#3), and the primary path uses PE3 as the egress PE. PE3 might have preprogrammed a backup forwarding entry that points to the backup path through PE4-CE4, for all the prefixes going through the PE3-CE3 link. How that backup path gets computed is also out of scope 🧚. When the PE3-CE3 link fails, PE3 still receives the traffic, and it automatically switches to the backup entry. So the path becomes PE1-P1-(...)-P3-PE3-PE4-CE4 until the remote PEs reconverge and start using PE4 as the egress PE 😭🫶.
PE1-P1-(...)-P3-PE3-PE4-CE46.9. Security 🔐
The "security" container holds the customer-specific security parameters for the site. The security options in the model are limited, but they can be extended via augmentation 💅.
6.9.1. Authentication 🔑
The current model doesn't support any authentication parameters for the site connection. Those parameters can be added to the "authentication" container through augmentation 🌈.
6.9.2. Encryption 🔒
Traffic encryption can be requested on the connection 💜. It can be performed at Layer 2 or Layer 3, depending on which enumeration you pick in the "layer" leaf. For example, an SP might use IPsec when a customer asks for Layer 3 encryption. The encryption profile can be defined by the SP or be customer specific ✨.
When an SP profile is used and the provider allocates a key (for example, a pre-shared key) for the customer to use, the SP should provide a way to communicate that key to the customer securely 🫶.
When a customer profile is used, the model only supports a pre-shared key for authentication of the site connection, and that pre-shared key is provided through the NETCONF or RESTCONF request. A secure channel must be used so the pre-shared key can't be intercepted 🚨.
For security reasons, the customer may need to change the pre-shared key on a regular basis 🔄. To do a key change, the user asks the SP to change the pre-shared key by submitting a new pre-shared key for the site configuration, like in the XML snippet below. Heads up: this mechanism might not be hitless 🙈.
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<security>
<encryption>
<encryption-profile>
<preshared-key>MY_NEW_KEY</preshared-key>
</encryption-profile>
</encryption>
</security>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>A hitless key change mechanism may be added through augmentation 💖. Other key-management methodologies (for example, PKI) may be added through augmentation too 🦋.
6.10. Management 🎀
The model defines three common management options 👑:
- provider-managed: The CE router is managed only by the provider. In this model, the responsibility boundary between the SP and the customer is between the CE and the customer network.
- customer-managed: The CE router is managed only by the customer. In this model, the responsibility boundary between the SP and the customer is between the PE and the CE.
- co-managed: The CE router is primarily managed by the provider. On top of that, the SP lets customers access the CE for configuration or monitoring purposes. In co-managed mode, the responsibility boundary is the same as the one for the provider-managed model.
Based on the management model, different security options MAY be derived 💅. In the co-managed case, the model defines options for the management address family (IPv4 or IPv6) and the associated management address 🌸.
6.11. Routing Protocols 🛣️
"routing-protocol" defines which routing protocol must be activated between the provider and the customer router 🫶. The current model supports these settings: bgp, rip, ospf, static, direct, and vrrp ✨.
The routing protocol you define applies at the provider-to-customer boundary 💜. Depending on how the management model is administered, it may apply to the PE-CE boundary or to the CE-to-customer boundary. For a customer-managed site, the routing protocol gets activated between the PE and the CE router the customer manages. For a provider-managed site, it gets activated between the CE that the SP manages and the router or LAN that belongs to the customer. In that case, the PE-CE routing is expected to be configured based on the SP's rules, since both are managed by the same entity 🧚.
Rtg protocol
192.0.2.0/24 ----- CE ----------------- PE1
Customer-managed site
Rtg protocol
Customer router ----- CE ----------------- PE1
Provider-managed siteAll the examples below refer to a scenario for a customer-managed site 🌈.
6.11.1. Handling of Dual Stack 🌐
All routing protocol types support dual stack by using the "address-family" leaf-list 💖.
Here's an example XML snippet with dual stack using the same routing protocol 🍓:
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<routing-protocols>
<routing-protocol>
<type>static</type>
<static>
<cascaded-lan-prefixes>
<ipv4-lan-prefixes>
<lan>192.0.2.0/24</lan>
<next-hop>203.0.113.1</next-hop>
</ipv4-lan-prefixes>
<ipv6-lan-prefixes>
<lan>2001:db8::1/64</lan>
<next-hop>2001:db8::2</next-hop>
</ipv6-lan-prefixes>
</cascaded-lan-prefixes>
</static>
</routing-protocol>
</routing-protocols>
</site>
</sites>
</l3vpn-svc>And here's one with dual stack using two different routing protocols 🦋:
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<routing-protocols>
<routing-protocol>
<type>rip</type>
<rip>
<address-family>ipv4</address-family>
</rip>
</routing-protocol>
<routing-protocol>
<type>ospf</type>
<ospf>
<address-family>ipv6</address-family>
<area-address>4.4.4.4</area-address>
</ospf>
</routing-protocol>
</routing-protocols>
</site>
</sites>
</l3vpn-svc>6.11.2. LAN Directly Connected to SP Network 🌸
okay so the routing protocol type "direct" SHOULD be used when a customer LAN is directly connected to the provider network and must be advertised in the IP VPN 🦋
LAN attached directly to provider network:
192.0.2.0/24 ----- PE1In this case, the customer has a default route to the PE address. 💅
6.11.3. LAN Directly Connected to SP Network with Redundancy 🎀
the routing protocol type "vrrp" SHOULD be used and advertised in the IP VPN when
- the customer LAN is directly connected to the provider network, and
- LAN redundancy is expected.
ok this is the setup where two PEs are both hooked up to the same LAN 👯
192.0.2.0/24 ------ PE1
|
+--- PE2In this case, the customer has a default route to the SP network. ✨
6.11.4. Static Routing 🧚
the routing protocol type "static" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IP VPN. here the static routes give next hops (nh) to the CE and to the PE, so it's giving very hand-crafted energy 🍓 The customer has a default route to the SP network.
Static rtg
192.0.2.0/24 ------ CE -------------- PE
| |
| Static route 192.0.2.0/24 nh CE
Static route 0.0.0.0/0 nh PE6.11.5. RIP Routing 🌈
the routing protocol type "rip" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IP VPN. for IPv4, the model assumes that RIP version 2 is used, bestie 💜
in the case of dual-stack routing requested through this model, the management system will be responsible for configuring RIP (including the correct version number) and associated address families on network elements. the management system is the one doing the heavy lifting here 🫶
RIP rtg
192.0.2.0/24 ------ CE -------------- PE6.11.6. OSPF Routing 🦋
the routing protocol type "ospf" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IP VPN. ospf is SO good for extending an existing OSPF network and interconnecting different areas 🌸 See [RFC4577] for more details.
+---------------------+
| |
OSPF | | OSPF
area 1 | | area 2
(OSPF | | (OSPF
area 1) --- CE ---------- PE PE ----- CE --- area 2)
| |
+---------------------+ok now the sham link era 🙈 The model also defines an option to create an OSPF sham link between two sites sharing the same area and having a backdoor link. the sham link is created by referencing the target site sharing the same OSPF area. the management system will be responsible for checking to see if there is already a sham link configured for this VPN and area between the same pair of PEs. if there is no existing sham link, the management system will provision one. this sham link MAY be reused by other sites, which is very efficient of it 💅
+------------------------+
| |
| |
| PE (--sham link--)PE |
| | | |
+----|----------------|--+
| OSPF area 1 | OSPF area 1
| |
CE1 CE2
| |
(OSPF area 1) (OSPF area 1)
| |
+----------------+regarding dual-stack support, the user MAY specify both IPv4 and IPv6 address families, if both protocols should be routed through OSPF. as OSPF uses separate protocol instances for IPv4 and IPv6, the management system will need to configure both OSPF version 2 and OSPF version 3 on the PE-CE link. two protocols, two instances, zero chill 😭
other OSPF parameters, such as timers, are typically set by the SP and communicated to the customer outside the scope of this model. not this model's problem, iykyk 🙈
example of a corresponding XML snippet with OSPF routing parameters in the service model:
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<routing-protocols>
<routing-protocol>
<type>ospf</type>
<ospf>
<area-address>0.0.0.1</area-address>
<address-family>ipv4</address-family>
<address-family>ipv6</address-family>
</ospf>
</routing-protocol>
</routing-protocols>
</site>
</sites>
</l3vpn-svc>example of PE configuration done by the management system:
router ospf 10
area 0.0.0.1
interface Ethernet0/0
!
router ospfv3 10
area 0.0.0.1
interface Ethernet0/0
!6.11.7. BGP Routing 💖
the routing protocol type "bgp" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IP VPN. bgp is the main character of routing protocols and we are not taking questions 👑
BGP rtg
192.0.2.0/24 ------ CE -------------- PEthe session addressing will be derived from connection parameters as well as the SP's knowledge of the addressing plan that is in use. 🧚
in the case of dual-stack access, the user MAY request BGP routing for both IPv4 and IPv6 by specifying both address families. it will be up to the SP and management system to determine how to describe the configuration (two BGP sessions, single, multi-session, etc.). this, along with other BGP parameters such as timers, is communicated to the customer outside the scope of this model. the SP and management system are basically deciding the vibe here 🌸
the service configuration below activates BGP on the PE-CE link for both IPv4 and IPv6. ✨
BGP activation requires the SP to know the address of the customer peer. if the site-network-access connection addresses are used for BGP peering, the "static-address" allocation type for the IP connection MUST be used. other peering mechanisms are outside the scope of this model. this one is a real must, no cap 🚨
example of a corresponding XML snippet is described as follows:
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<routing-protocols>
<routing-protocol>
<type>bgp</type>
<bgp>
<autonomous-system>65000</autonomous-system>
<address-family>ipv4</address-family>
<address-family>ipv6</address-family>
</bgp>
</routing-protocol>
</routing-protocols>
</site>
</sites>
</l3vpn-svc>depending on the SP flavor, a management system can divide this service configuration into different flavors, as shown by the following examples. so many options, I'm obsessed 😭
example of PE configuration done by the management system (single IPv4 transport session):
router bgp 100
neighbor 203.0.113.2 remote-as 65000
address-family ipv4 vrf Cust1
neighbor 203.0.113.2 activate
address-family ipv6 vrf Cust1
neighbor 203.0.113.2 activate
neighbor 203.0.113.2 route-map SET-NH-IPV6 outexample of PE configuration done by the management system (two sessions):
router bgp 100
neighbor 203.0.113.2 remote-as 65000
neighbor 2001::2 remote-as 65000
address-family ipv4 vrf Cust1
neighbor 203.0.113.2 activate
address-family ipv6 vrf Cust1
neighbor 2001::2 activateexample of PE configuration done by the management system (multi-session):
router bgp 100
neighbor 203.0.113.2 remote-as 65000
neighbor 203.0.113.2 multisession per-af
address-family ipv4 vrf Cust1
neighbor 203.0.113.2 activate
address-family ipv6 vrf Cust1
neighbor 203.0.113.2 activate
neighbor 203.0.113.2 route-map SET-NH-IPV6 out6.12. Service 🎀
the service defines service parameters associated with the site. this is the part where we get into the nitty gritty 💅
6.12.1. Bandwidth 🍓
the service bandwidth refers to the bandwidth requirement between the PE and the CE (WAN link bandwidth). it's expressed as svc-input-bandwidth and svc-output-bandwidth in bits per second. the input/output direction uses the customer site as a reference: "input bandwidth" means download bandwidth for the site, and "output bandwidth" means upload bandwidth for the site. ok so download is input and upload is output, easy 🦋
the service bandwidth is only configurable at the site-network-access level. 🌈
using a different input and output bandwidth will allow the SP to determine if the customer allows for asymmetric bandwidth access, such as ADSL. it can also be used to set rate-limiting in a different way for uploading and downloading on a symmetric bandwidth access. the SP gets to be a little clever about it 🧚
the bandwidth is a service bandwidth expressed primarily as IP bandwidth, but if the customer enables MPLS for Carriers' Carriers (CsC), this becomes MPLS bandwidth. ✨
6.12.2. MTU 🌸
the service MTU refers to the maximum PDU size that the customer may use. if the customer sends packets that are longer than the requested service MTU, the network may discard it (or for IPv4, fragment it). so keep those packets in check, bestie 🫶
6.12.3. QoS 💜
the model defines QoS parameters in an abstracted way:
- qos-classification-policy: policy that defines a set of ordered rules to classify customer traffic.
- qos-profile: QoS scheduling profile to be applied.
6.12.3.1. QoS Classification 💅
okay so QoS classification is handled by the qos-classification-policy container 🎀. It's an ordered list of rules, and each rule matches a flow or an application and sets the target class of service (target-class-id) ✨. The user can make the match using an application reference, or a flow definition that's way more specific, like Layer 3 source and destination addresses, Layer 4 ports, and the Layer 4 protocol 🦋.
When you use a flow definition, you can use a target-sites leaf-list to say where the flow is going, instead of typing out destination IP addresses 🧚. The catch is that the association between the site abstraction and the IP addresses that site uses must be done dynamically. How that association works is out of scope for this document, so we're not going there 🙈. The link between a site and an IP VPN is made through the vpn-attachment container 💜. That means you can also combine target-sites and vpn-attachment to point at a flow headed for a specific VPN service 🌸.
A rule with no match statement counts as a match-all rule 🌈. An SP may implement a default terminal classification rule if the customer doesn't give one, and it's up to the SP to decide that default target class 👑. The model already defines some applications, but new application identities can be added through augmentation ✨. What each application identity actually means is up to the SP, so the SP will need to advise the customer on how to use application matching 🫶.
Where the classification happens depends on how the SP implements the service 🍓. Either way, classification is about the flow coming from the customer site and entering the network 💖.
Provider network
+-----------------------+
192.0.2.0/24
198.51.100.0/24 ---- CE --------- PE
Traffic flow
---------->In the figure above, the management system should implement the classification rule:
- in the ingress direction on the PE interface, if the CE is customer-managed.
- in the ingress direction on the CE interface connected to the customer LAN, if the CE is provider-managed.
Here's a sample service description of QoS classification for a site 🎀:
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<service>
<qos>
<qos-classification-policy>
<rule>
<id>SvrA-http</id>
<match-flow>
<ipv4-src-prefix>192.0.2.0/24</ipv4-src-prefix>
<ipv4-dst-prefix>203.0.113.1/32</ipv4-dst-prefix>
<l4-dst-port>80</l4-dst-port>
<protocol-type>tcp</protocol-type>
</match-flow>
<target-class-id>DATA2</target-class-id>
</rule>
<rule>
<id>SvrA-ftp</id>
<match-flow>
<ipv4-src-prefix>192.0.2.0/24</ipv4-src-prefix>
<ipv4-dst-prefix>203.0.113.1/32</ipv4-dst-prefix>
<l4-dst-port>21</l4-dst-port>
<protocol-field>tcp</protocol-field>
</match-flow>
<target-class-id>DATA2</target-class-id>
</rule>
<rule>
<id>p2p</id>
<match-application>p2p</match-application>
<target-class-id>DATA3</target-class-id>
</rule>
<rule>
<id>any</id>
<target-class-id>DATA1</target-class-id>
</rule>
</qos-classification-policy>
</qos>
</service>
</site>
</sites>
</l3vpn-svc>In the example above 🧁:
- HTTP traffic from the 192.0.2.0/24 LAN destined for 203.0.113.1/32 will be classified in DATA2 💅.
- FTP traffic from the 192.0.2.0/24 LAN destined for 203.0.113.1/32 will be classified in DATA2 📁.
- Peer-to-peer traffic will be classified in DATA3 🫣.
- All other traffic will be classified in DATA1 🌸.
The user gets to decide the order of the rule list entries 👑. The management system that translates those rules into network element configuration MUST keep the same processing order in that configuration ⭐. No reordering, bestie, it's not optional 😭.
6.12.3.2. QoS Profile ✨
The user can pick either a standard profile from the operator or a custom one 🎀. The qos-profile container defines the traffic-scheduling policy that the SP will use 🦋.
Provider network
+-----------------------+
192.0.2.0/24
198.51.100.0/24 ---- CE --------- PE
\ /
qos-profileA custom QoS profile is a list of classes of service, each with its own properties 💖. Here they are 💅:
- direction: this says which direction the QoS profile applies to 🧭. The model supports three direction settings: "Site-to-WAN", "WAN-to-Site", and "both". By default, the "both" value is used. With "both", the provider should make sure scheduling follows the requested policy in both traffic directions (SP to customer and customer to SP) 🔁. For example, a device-scheduling policy may be implemented on both the PE side and the CE side of the WAN link 🌈. With "WAN-to-Site", the provider should make sure scheduling runs from the SP network to the customer site 🌊. For example, a device-scheduling policy may be implemented only on the PE side of the WAN link towards the customer 🎯.
- rate-limit: this rate-limits the class of service 🚦. The value is a percentage of the global service bandwidth 📊. When the
qos-profilecontainer is implemented on the CE side,svc-output-bandwidthis the reference. When it's implemented on the PE side,svc-input-bandwidthis used 🧠. - latency: this defines the latency constraint of the class ⚡. The constraint can be the lowest possible latency, or a latency boundary in milliseconds 🕒. How that constraint gets fulfilled is up to the SP's implementation of the service 🛠️. For example, strict priority queuing may be used on the access and in the core network, and/or a low-latency routing configuration may be created for this traffic class 🚀.
- jitter: this defines the jitter constraint of the class 🎶. The constraint can be the lowest possible jitter, or a jitter boundary in microseconds 🔬. How it gets fulfilled is up to the SP's implementation of the service 🧃. For example, strict priority queuing may be used on the access and in the core network, and/or a jitter-aware routing configuration may be created for this traffic class 🪄.
- bandwidth: this defines a guaranteed amount of bandwidth for the class of service, expressed as a percentage 🏆. The
guaranteed-bw-percentparameter uses available bandwidth as its reference. When theqos-profilecontainer is implemented on the CE side,svc-output-bandwidthis taken into account as the reference. When it's implemented on the PE side,svc-input-bandwidthis used 📦. By default, the bandwidth reservation is only guaranteed at the access level 🚪. If the user wants an end-to-end bandwidth reservation, including across the MPLS transport network, they can use the "end-to-end" leaf 🌍. (In other words, the SP will activate something in the MPLS core so the bandwidth request from the customer gets fulfilled by the MPLS core too 💫.) How this is done (for example, RSVP reservation or controller reservation) is out of scope for this document 🙈.
Heads up, bestie: due to network conditions, some constraints may not be completely fulfilled by the SP. When that happens, the SP should advise the customer about the limitations 🚨. How that communication is done is out of scope for this document 🤷♀️.
Here's an example of a service configuration using a standard QoS profile, with the matching XML snippet 🎀:
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-profiles>
<valid-provider-identifiers>
<qos-profile-identifier>
<id>GOLD</id>
</qos-profile-identifier>
<qos-profile-identifier>
<id>PLATINUM</id>
</qos-profile-identifier>
</valid-provider-identifiers>
</vpn-profiles>
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1245HRTFGJGJ154654</site-network-access-id>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<service>
<svc-input-bandwidth>100000000</svc-input-bandwidth>
<svc-output-bandwidth>100000000</svc-output-bandwidth>
<svc-mtu>1514</svc-mtu>
<qos>
<qos-profile>
<profile>PLATINUM</profile>
</qos-profile>
</qos>
</service>
</site-network-access>
<site-network-access>
<site-network-access-id>555555AAAA2344</site-network-access-id>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<service>
<svc-input-bandwidth>2000000</svc-input-bandwidth>
<svc-output-bandwidth>2000000</svc-output-bandwidth>
<svc-mtu>1514</svc-mtu>
<qos>
<qos-profile>
<profile>GOLD</profile>
</qos-profile>
</qos>
</service>
</site-network-access>
</site-network-accesses>
</site>
</sites></l3vpn-svc>Okay, so here's a full example of a service config with a custom QoS profile, and it's giving fully engineered 💅✨
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-profiles>
<valid-provider-identifiers>
<qos-profile-identifier>
<id>GOLD</id>
</qos-profile-identifier>
<qos-profile-identifier>
<id>PLATINUM</id>
</qos-profile-identifier>
</valid-provider-identifiers>
</vpn-profiles>
<vpn-services>
<vpn-service>
<vpn-id>VPNA</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>SITE1</site-id>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<site-network-accesses>
<site-network-access>
<site-network-access-id>Site1</site-network-access-id>
<location-reference>L1</location-reference>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<service>
<svc-mtu>1514</svc-mtu>
<svc-input-bandwidth>10000000</svc-input-bandwidth>
<svc-output-bandwidth>10000000</svc-output-bandwidth>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<location-reference>L1</location-reference>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
<service>
<svc-input-bandwidth>100000000</svc-input-bandwidth>
<svc-output-bandwidth>100000000</svc-output-bandwidth>
<qos>
<qos-profile>
<classes>
<class>
<class-id>REAL_TIME</class-id>
<direction>both</direction>
<rate-limit>10</rate-limit>
<latency>
<use-lowest-latency/>
</latency>
<bandwidth>
<guaranteed-bw-percent>80</guaranteed-bw-percent>
</bandwidth>
</class>
<class>
<class-id>DATA1</class-id>
<latency>
<latency-boundary>70</latency-boundary>
</latency>
<bandwidth>
<guaranteed-bw-percent>80</guaranteed-bw-percent>
</bandwidth>
</class>
<class>
<class-id>DATA2</class-id>
<latency>
<latency-boundary>200</latency-boundary>
</latency>
<bandwidth>
<guaranteed-bw-percent>5</guaranteed-bw-percent>
<end-to-end/>
</bandwidth>
</class>
</classes>
</qos-profile>
</qos>
</service>
</site-network-access>
</site-network-accesses>
</site>
</sites>
</l3vpn-svc>So for Site1's custom QoS profile 🎀, we get a REAL_TIME class with a latency constraint of "the lowest possible latency" (⚡ lowkey iconic), plus two data classes, DATA1 and DATA2. Both data classes have a latency boundary and a bandwidth reservation. The REAL_TIME class is rate-limited to 10% of the service bandwidth (10% of 100 Mbps = 10 Mbps) 🦋. When congestion happens, REAL_TIME traffic can go up to 10 Mbps (let's assume it only uses 5 Mbps, bestie 🫶). DATA1 and DATA2 then split the remaining bandwidth (95 Mbps) according to their percentages, so DATA1 gets at least 76 Mbps 😭 and DATA2 gets at least 4.75 Mbps 🌸.
The latency boundary info on the data classes can help the SP do specific buffer tuning or specific routing inside the network 🧚. And honestly? The maximum percentage isn't capped by this model itself, but it MUST be limited by the management system according to the policies the SP authorizes 🔥 (non-negotiable, periodt 💅).
6.12.4. Multicast 💜
The "multicast" container says what kind of site this is in the customer's multicast service topology: source, receiver, or both 🍓. These parameters help the management system optimise the multicast service ✨. Users can also pick the type of multicast relationship with the customer: router (which needs a protocol like PIM), host (IGMP or MLD), or both 🌈. An address family (IPv4, IPv6, or both) can be defined too 🦋.
6.13. Enhanced VPN Features 👑
6.13.1. Carriers' Carriers 🌸
Okay, so picture this: with CsC [RFC4364], a customer might want to build an MPLS service using an IP VPN to carry its traffic 🧚♀️ It's a whole VPN inside a VPN, and it's giving inception 🤯
LAN customer1
|
|
CE1
|
| -------------
(vrf_cust1)
CE1_ISP1
| ISP1 POP
| MPLS link
| -------------
|
(vrf ISP1)
PE1
(...) Provider backbone
PE2
(vrf ISP1)
|
| ------------
|
| MPLS link
| ISP1 POP
CE2_ISP1
(vrf_cust1)
| ------------
|
CE2
|
LAN customer1In the figure above, ISP1 resells an IP VPN service but has no core network infrastructure between its POPs 🥺. So ISP1 uses an IP VPN as the core network infrastructure between its POPs, and that IP VPN belongs to another provider 💀✨.
To support CsC, the VPN service has to indicate MPLS support by setting the "carrierscarrier" leaf to true in the vpn-service list 🔥. The link between CE1_ISP1/PE1 and CE2_ISP1/PE2 must also run an MPLS signalling protocol 🫶. This gets configured at the site level, bestie 🍓.
In the proposed model, LDP or BGP can be used as the MPLS signalling protocol 🌈. With LDP, an IGP routing protocol MUST also be activated 😭. With BGP signalling, BGP MUST also be configured as the routing protocol 💜.
If CsC is enabled, the requested "svc-mtu" leaf refers to the MPLS MTU, not the IP MTU 🎀 (small detail, big vibes).
6.14. External ID References 🦋
The service model sometimes points to external information through identifiers 🧚. For example, to order cloud-access to a particular cloud service provider (CSP), the model uses an identifier to refer to the targeted CSP ☁️. If a customer uses this service model directly as an API (through REST or NETCONF, for example) to order a particular service, the SP should provide a list of authorized identifiers 💅. For cloud-access, the SP provides the associated identifiers for each available CSP 🌸. The same goes for other identifiers, like std-qos-profile, OAM profile-name, and provider-profile for encryption ✨.
How an SP tells the customer what those identifiers mean is out of scope for this document 🙈.
6.15. Defining NNIs 🌈
An autonomous system (AS) is a single network, or a group of networks, that's controlled by a common system administration group and uses a single, clearly defined routing protocol 👑. Sometimes VPNs need to span different ASes in different geographic areas, or span different SPs 🌍. The connection between ASes is set up by the SPs and is seamless to the customer 🫶. Examples include:
- a partnership between SPs (e.g., carrier, cloud) to extend their VPN service seamlessly 🤝.
- an internal administrative boundary within a single SP (e.g., backhaul versus core versus data center) 🏢.
NNIs (network-to-network interfaces) have to be defined to extend VPNs across multiple ASes 🔗.
[RFC4364] defines multiple flavours of VPN NNI implementations 📚. Each one has pros and cons, and that topic is outside the scope of this document 🙃. For example, in an Inter-AS option A, autonomous system border router (ASBR) peers are connected by multiple interfaces, with at least one of those interfaces spanning the two ASes while being present in the same VPN 🦋. For these ASBRs to signal unlabeled IP prefixes, they associate each interface with a VPN routing and forwarding (VRF) instance and a Border Gateway Protocol (BGP) session 💜. So traffic between the back-to-back VRFs is IP 🌸. In this scenario the VPNs are isolated from each other, and because the traffic is IP, QoS mechanisms that operate on IP traffic can be applied to meet customer service level agreements (SLAs) ✨.
-------- -------------- -----------
/ \ / \ / \
| Cloud | | | | |
| Provider |-----NNI-----| |----NNI---| Data Center |
| #1 | | | | |
\ / | | \ /
-------- | | -----------
| |
-------- | My network | -----------
/ \ | | / \
| Cloud | | | | |
| Provider |-----NNI-----| |---NNI---| L3VPN |
| #2 | | | | Partner |
\ / | | | |
-------- | | | |
\ / | |
-------------- \ /
| -----------
|
NNI
|
|
-------------------
/ \
| |
| |
| |
| L3VPN Partner |
| |
\ /
-------------------The figure above shows an SP network called "My network" with several NNIs 🏰. This network uses NNIs to:
- increase its footprint by relying on L3VPN partners 🗺️.
- connect its own data center services to the customer IP VPN 💖.
- enable the customer to reach their private resources in a private cloud owned by some CSPs 🔐.
6.15.1. Defining an NNI with the Option A Flavor ✨
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + |
| + (VRF2)---(VPN2)----(VRF2) + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + |
| + (VRF2)---(VPN2)----(VRF2) + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------okay so in option A, the two ASes are hooked up to each other with physical links on their ASBRs 🔗 For resiliency, there can be multiple physical connections between the ASes, which is so smart 💅 A VPN connection gets created for each VPN that needs to cross the AS boundary. It can be physical, or logical sitting on top of a physical link, and together that gives you the back-to-back VRF model. It's giving clean architecture ✨
From a service model's perspective, that VPN connection can be seen as a site 🎀 Let's say AS B wants to extend some VPN connections for VPN C over on AS A. The AS B admin can use this service model to order a site on AS A. Every connection scenario can be realized with the features of the current model. The figure above, for example, shows two physical connections with logical connections per VPN overlaid on them. That's a dual-homed subVPN scenario, and it's so iconic 👑 Also, the AS B admin gets to choose the appropriate routing protocol (e.g., E-BGP) to dynamically exchange routes between ASes. Main character energy 🦋
This document assumes that the option A NNI flavor SHOULD reuse the existing VPN site modeling. 💜
Okay, now a little example 🧚 A customer wants its CSP A to attach its virtual network N to an existing IP VPN (VPN1) that they already have from L3VPN SP B.
CSP A L3VPN SP B
----------------- -------------------
/ \ / \
| | | | |
| VM --| ++++++++ NNI ++++++++ |--- VPN1
| | + +_________+ + | Site#1
| |--------(VRF1)---(VPN1)--(VRF1)+ |
| | + ASBR + + ASBR + |
| | + +_________+ + |
| | ++++++++ ++++++++ |
| VM --| | | |--- VPN1
| |Virtual | | | Site#2
| |Network | | |
| VM --| | | |--- VPN1
| | | | | Site#3
\ / \ /
----------------- -------------------
|
|
VPN1
Site#4To create the VPN connectivity, the CSP or the customer may use the L3VPN service model that SP B exposes 💅 We could consider that, since the NNI is shared, the physical connection (bearer) between CSP A and SP B already exists. CSP A may request, through a service model, the creation of a new site with a single site-network-access (single-homing is used in the figure). As a placement constraint, CSP A may use the existing bearer reference it has from SP A to force the placement of the VPN NNI on the existing link. The XML snippet below illustrates a possible configuration request to SP B 🫶
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-profiles>
<valid-provider-identifiers>
<qos-profile-identifier>
<id>GOLD</id>
</qos-profile-identifier>
<qos-profile-identifier>
<id>PLATINUM</id>
</qos-profile-identifier>
</valid-provider-identifiers>
</vpn-profiles>
<vpn-services>
<vpn-service>
<vpn-id>VPN1</vpn-id>
</vpn-service>
</vpn-services>
<sites>
<site>
<site-id>CSP_A_attachment</site-id>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<locations>
<location>
<location-id>L1</location-id>
</location>
</locations>
<locations>
<location>
<location-id>1</location-id>
<city>NY</city>
<country-code>US</country-code>
</location>
</locations>
<site-vpn-flavor>site-vpn-flavor-nni</site-vpn-flavor>
<routing-protocols>
<routing-protocol>
<type>bgp</type>
<bgp>
<autonomous-system>500</autonomous-system>
<address-family>ipv4</address-family>
</bgp>
</routing-protocol>
</routing-protocols>
<site-network-accesses>
<site-network-access>
<site-network-access-id>CSP_A_VN1</site-network-access-id>
<location-reference>L1</location-reference>
<ip-connection>
<ipv4>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv4>
<ipv6>
<address-allocation-type>provider-dhcp</address-allocation-type>
</ipv6>
</ip-connection>
<ip-connection>
<ipv4>
<address-allocation-type>static-address</address-allocation-type>
<addresses>
<provider-address>203.0.113.1</provider-address>
<customer-address>203.0.113.2</customer-address>
<prefix-length>30</prefix-length>
</addresses>
</ipv4>
</ip-connection>
<service>
<svc-input-bandwidth>450000000</svc-input-bandwidth>
<svc-output-bandwidth>450000000</svc-output-bandwidth>
<svc-mtu>1514</svc-mtu>
</service>
<security>
<encryption>
<layer>layer3</layer>
</encryption>
</security>
<vpn-attachment>
<vpn-id>VPN1</vpn-id>
<site-role>any-to-any-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
<management>
<type>customer-managed</type>
</management>
</site>
</sites>
</l3vpn-svc>Quick distinction, bestie 🌸 The case described above is different from a scenario using the cloud-accesses container. A cloud-access gives you public cloud access, while this example enables access to private resources located in a CSP network 🍓
6.15.2. Defining an NNI with the Option B Flavor 🦋
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR +<---MP-BGP---->+ ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR +<---MP-BGP---->+ ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------Okay bestie, so in option B the two ASes are hooked up to each other with physical links on ASBRs 🔗. For resiliency there may be multiple physical connections between the ASes ✨. The VPN "connection" between the ASes happens by swapping VPN routes over MP-BGP [RFC4760] 💅.
There are multiple flavors of this NNI, periodt 👑. For example:
- The NNI is internal to the provider and sits between a backbone and a data center 🏢. The domains trust each other enough to not filter the VPN routes, so all the VPN routes get exchanged. RT filtering may be implemented to save some unnecessary route states 🧹.
- The NNI is used between providers that agreed to exchange VPN routes for specific RTs only 🤝. Each provider is authorized to use the RT values from the other provider.
- The NNI is used between providers that agreed to exchange VPN routes for specific RTs only 🤝. Each provider has its own RT scheme, so a customer spanning the two networks will have different RTs in each network for a particular VPN 🙈.
Case 1 does not require any service modeling, since the protocol enables the dynamic exchange of necessary VPN routes 🌸.
Case 2 requires that an RT-filtering policy on ASBRs be maintained. From a service modeling point of view, it is necessary to agree on the list of RTs to authorize 📝.
In Case 3, both ASes need to agree on the VPN RT to exchange, as well as how to map a VPN RT from AS A to the corresponding RT in AS B (and vice versa) 🔁.
Those modelings are currently out of scope for this document 🙃.
CSP A L3VPN SP B
----------------- ------------------
/ \ / \
| | | | |
| VM --| ++++++++ NNI ++++++++ |--- VPN1
| | + +__________+ + | Site#1
| |-------+ + + + |
| | + ASBR +<-MP-BGP->+ ASBR + |
| | + +__________+ + |
| | ++++++++ ++++++++ |
| VM --| | | |--- VPN1
| |Virtual | | | Site#2
| |Network | | |
| VM --| | | |--- VPN1
| | | | | Site#3
\ / | |
----------------- | |
\ /
------------------
|
|
VPN1
Site#4The example above describes an NNI connection between CSP A and SP network B. Both SPs do not trust themselves and use a different RT allocation policy 🙅♀️. So, in terms of implementation, the customer VPN has a different RT in each network (RT A in CSP A and RT B in SP network B). To connect the customer virtual network in CSP A to the customer IP VPN (VPN1) in SP network B, CSP A should request that SP network B open the customer VPN on the NNI (accept the appropriate RT). Who does the RT translation depends on the agreement between the two SPs: SP B may permit CSP A to request VPN (RT) translation 💖.
6.15.3. Defining an NNI with the Option C Flavor 🌈
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| | | |
| | | |
| ++++++++ Multihop E-BGP ++++++++ |
| + + + + |
| + + + + |
| + RGW +<----MP-BGP---->+ RGW + |
| + + + + |
| + + + + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------From a VPN service's perspective, the option C NNI is very similar to option B, since an MP-BGP session is used to exchange VPN routes between the ASes 💜. The difference is that the forwarding plane and the control plane are on different nodes, so the MP-BGP session is multihop between routing gateway (RGW) nodes 🧚.
From a VPN service's point of view, modeling options B and C will be identical 🎀.
7. Service Model Usage Example ✨
As explained in Section 5, this service model is intended to be instantiated at a management layer and is not intended to be used directly on network elements. The management system serves as a central point of configuration of the overall service 🫶.
This section provides an example of how a management system can use this model to configure an IP VPN service on network elements 💅.
In this example, we want to achieve the provisioning of a VPN service for three sites using a Hub-and-Spoke VPN service topology. One of the sites will be dual-homed, and load-sharing is expected 🍓.
+-------------------------------------------------------------+
| Hub_Site ------ PE1 PE2 ------ Spoke_Site1 |
| | +----------------------------------+
| | |
| | +----------------------------------+
| Hub_Site ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+The following XML snippet describes the overall simplified service configuration of this VPN 🌸.
<?xml version="1.0"?>
<l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc">
<vpn-profiles>
<valid-provider-identifiers>
<qos-profile-identifier>
<id>GOLD</id>
</qos-profile-identifier>
<qos-profile-identifier>
<id>PLATINUM</id>
</qos-profile-identifier>
</valid-provider-identifiers>
</vpn-profiles>
<vpn-services>
<vpn-service>
<vpn-id>12456487</vpn-id>
<vpn-service-topology>hub-spoke</vpn-service-topology>
</vpn-service>
</vpn-services>
</l3vpn-svc>When receiving the request for provisioning the VPN service, the management system will internally (or through communication with another OSS component) allocate VPN RTs 🧠. In this specific case, two RTs will be allocated (100:1 for Hub and 100:2 for Spoke) 🎯. The output of corresponding XML snippet below describes the configuration of Spoke_Site1 💜.
<?xml version="1.0"?><l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"> <vpn-profiles> <valid-provider-identifiers> <qos-profile-identifier> <id>GOLD</id> </qos-profile-identifier> <qos-profile-identifier> <id>PLATINUM</id> </qos-profile-identifier> </valid-provider-identifiers> </vpn-profiles> <vpn-services> <vpn-service> <vpn-id>12456487</vpn-id> <vpn-service-topology>hub-spoke</vpn-service-topology> </vpn-service> </vpn-services> <sites> <site> <site-id>Spoke_Site1</site-id> <devices> <device> <device-id>D1</device-id> </device> </devices> <locations> <location> <location-id>1</location-id> <city>NY</city> <country-code>US</country-code> </location> </locations> <security> <encryption> <layer>layer3</layer> </encryption> </security> <routing-protocols> <routing-protocol> <type>bgp</type> <bgp> <autonomous-system>500</autonomous-system> <address-family>ipv4</address-family> <address-family>ipv6</address-family> </bgp> </routing-protocol> </routing-protocols> <site-network-accesses> <site-network-access> <site-network-access-id>Spoke_Site1</site-network-access-id> <device-reference>D1</device-reference> <access-diversity> <groups> <group> <group-id>20</group-id> </group> </groups> <constraints> <constraint> <constraint-type>pe-diverse</constraint-type> <target> <group> <group-id>10</group-id> </group> </target> </constraint> </constraints> </access-diversity> <ip-connection> <ipv4> <address-allocation-type>static-address</address-allocation-type> <addresses> <provider-address>203.0.113.254</provider-address> <customer-address>203.0.113.2</customer-address> <prefix-length>24</prefix-length> </addresses> </ipv4> <ipv6> <address-allocation-type>static-address</address-allocation-type> <addresses> <provider-address>2001:db8::1</provider-address> <customer-address>2001:db8::2</customer-address> <prefix-length>64</prefix-length> </addresses> </ipv6> </ip-connection> <service> <svc-input-bandwidth>450000000</svc-input-bandwidth> <svc-output-bandwidth>450000000</svc-output-bandwidth> <svc-mtu>1514</svc-mtu> </service> <security> <encryption> <layer>layer3</layer> </encryption> </security> <vpn-attachment> <vpn-id>12456487</vpn-id> <site-role>spoke-role</site-role> </vpn-attachment> </site-network-access> </site-network-accesses> <management> <type>provider-managed</type> </management> </site> </sites> </l3vpn-svc>
okay so bestie, the second Spoke_Site1 request lands and the management system is officially on the clock 💅🎀. It MUST allocate network resources for this site. First thing, it MUST figure out which network elements to provision for the access, especially the PE router (and maybe an aggregation switch too 🧚). Remember Section 6.6? There, the management system SHOULD use the location information, and it MUST use the access-diversity constraint to find the right PE 🦋. In this example, Spoke_Site1 needs PE diversity with the Hub, and the management system picks PEs based on least distance. So it checks the location info, finds the available PEs closest to the customer, and grabs one that fits the access-diversity constraint ✨.
once the PE is picked, the management system needs an interface from the pool of available ones 🔌. It can start provisioning that PE node however it likes (e.g., NETCONF, CLI) 💜. Next, it checks whether a VRF that fits its needs already exists. If not, it provisions one. The RD comes from the internal allocation policy model, and the RTs come from the VPN policy config for the site (the management system already allocated some RTs for the VPN) 🌸. Since this is a Spoke site (site-role), it knows which RTs must be imported and exported. Because the site is provider-managed, some management RTs may also get added (100:5000). Standard provider VPN policies MAY also be added to the config 🫶.
Example of generated PE configuration:
ip vrf Customer1 export-map STD-CUSTOMER-EXPORT <---- Standard SP configuration route-distinguisher 100:3123234324 route-target import 100:1 route-target import 100:5000 <---- Standard SP configuration route-target export 100:2 for provider-managed CE !
once the VRF is up, the management system can configure the access on the PE using the allocated interface info 🌈. IP addressing is chosen by the management system: one address comes from an allocated subnet for the PE, and another goes to the CE config. Routing protocols between PE and CE get configured too, and since this model is provider-managed, the SP gets to decide those choices 👑. BGP was picked for this example, and that choice has nothing to do with whatever routing protocol the customer is using, bestie 🙈. BGP will configure the CE-to-LAN connection as requested in the service model. Peering addresses are derived from the connection's addresses. Because the CE is provider-managed, its AS number can be auto-allocated by the management system. Standard configuration templates from the SP may also be added 💅.
Example of generated PE configuration:
interface Ethernet1/1/0.10 encapsulation dot1q 10 ip vrf forwarding Customer1 ip address 198.51.100.1 255.255.255.252 <---- Comes from automated allocation ipv6 address 2001:db8::10:1/64 ip access-group STD-PROTECT-IN <---- Standard SP config ! router bgp 100 address-family ipv4 vrf Customer1 neighbor 198.51.100.2 remote-as 65000 <---- Comes from automated allocation neighbor 198.51.100.2 route-map STD in <---- Standard SP config neighbor 198.51.100.2 filter-list 10 in <---- Standard SP config ! address-family ipv6 vrf Customer1 neighbor 2001:db8::0a10:2 remote-as 65000 <---- Comes from automated allocation neighbor 2001:db8::0a10:2 route-map STD in <---- Standard SP config neighbor 2001:db8::0a10:2 filter-list 10 in <---- Standard SP config ! ip route vrf Customer1 192.0.2.1 255.255.255.255 198.51.100.2 ! Static route for provider administration of CE !
since the CE router isn't reachable at this stage, the management system can build a complete CE config and manually upload it to the node before it gets sent to the customer premises 📦✨. The CE config is built the same way the PE would be configured. Based on the CE type (vendor/model) allocated to the customer and the bearer info, the management system knows which interface needs configuring on the CE. PE-CE link config is expected to be handled automatically through the SP OSS, since both resources are managed internally 🤖. CE-to-LAN-interface parameters like IP addressing come from the ip-connection container, taking into account how the management system splits addresses between the PE and CE within the subnet. This gives you a plug-and-play CE config, and honestly? Iconic 🎀🔥.
Example of generated CE configuration:
interface Loopback10 description "Administration" ip address 192.0.2.1 255.255.255.255 ! interface FastEthernet10 description "WAN" ip address 198.51.100.2 255.255.255.252 <---- Comes from automated allocation ipv6 address 2001:db8::0a10:2/64 ! interface FastEthernet11 description "LAN" ip address 203.0.113.254 255.255.255.0 <---- Comes from the ip-connection container ipv6 address 2001:db8::1/64 ! router bgp 65000 address-family ipv4 redistribute static route-map STATIC2BGP <---- Standard SP configuration neighbor 198.51.100.1 remote-as 100 <---- Comes from automated allocation neighbor 203.0.113.2 remote-as 500 <---- Comes from the ip-connection container address-family ipv6 redistribute static route-map STATIC2BGP <---- Standard SP configuration neighbor 2001:db8::0a10:1 remote-as 100 <---- Comes from automated allocation neighbor 2001:db8::2 remote-as 500 <---- Comes from the ip-connection container ! route-map STATIC2BGP permit 10 match tag 10 !
# 8. Interaction with Other YANG Models ✨
okay so, like we said back in <cyan>Section 5</cyan>, this service model is meant to be instantiated in a management system 🧚 and not directly on network elements 🙅♀️
the management system's whole job is to configure the network elements 🛠️ and it can be modular 💅. that means the piece that instantiates the service model (the "service component") and the piece in charge of network element configuration (the "configuration component") might be two different things 🎀
l3vpn-svc | Model |
+---------------------+
| Service component | Service datastore |
+---------------------+
+---------------------+ +----| Config component |------+ / +---------------------+ \ Network / / \ \ Configuration / / \ \ models / / \ \ ++++++++ ++++++++ ++++++++ ++++++++
- CE A + ------- + PE A + + PE B + ----- + CE B + Config ++++++++ ++++++++ ++++++++ ++++++++ datastore
Site A Site B
in the previous sections we showed some examples of translating service provisioning requests into router configuration lines 📝 and in the NETCONF/YANG world, the plan is for NETCONF/YANG to be used between the configuration component and the network elements to set up the requested services on those elements 🔧✨
specs are expected to give specific YANG modeling of service components on network elements 💜. there's going to be a seriously strong relationship between the abstracted view this service model gives and the detailed configuration view that the specific config models for network elements will provide 🫶 it's giving teamwork, bestie 🌈
the authors of this document expect YANG modules for the network elements below 👑 (and this list is not exhaustive, so there could be more! 🦋):
- VRF definition, including VPN policy expression. 💅
- Physical interface.
- IP layer (IPv4, IPv6).
- QoS: classification, profiles, etc.
- Routing protocols: support of configuration of all protocols listed in the document, as well as routing policies associated with those protocols.
- Multicast VPN.
- Network address translation.
here's an example XML snippet of a VPN site request at the service level, using this model 🎀:
<?xml version="1.0"?> <l3vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"> <vpn-profiles> <valid-provider-identifiers> <qos-profile-identifier> <id>GOLD</id> </qos-profile-identifier> <qos-profile-identifier> <id>PLATINUM</id> </qos-profile-identifier> </valid-provider-identifiers> </vpn-profiles> <vpn-services> <vpn-service> <vpn-id>VPN1</vpn-id> <vpn-service-topology>hub-spoke</vpn-service-topology> </vpn-service> </vpn-services> <sites> <site> <site-id>Site A</site-id> <security> <encryption> <layer>layer3</layer> </encryption> </security> <locations> <location> <location-id>L1</location-id> </location> </locations> <site-network-accesses> <site-network-access> <site-network-access-id>1</site-network-access-id> <ip-connection>
<ipv4> <address-allocation-type>static-address</address-allocation-type> <addresses> <provider-address>203.0.113.254</provider-address> <customer-address>203.0.113.2</customer-address> <prefix-length>24</prefix-length> </addresses> </ipv4> <ipv6> <address-allocation-type>provider-dhcp</address-allocation-type> </ipv6> </ip-connection> <service> <svc-mtu>1514</svc-mtu> <svc-input-bandwidth>10000000</svc-input-bandwidth> <svc-output-bandwidth>10000000</svc-output-bandwidth> </service> <location-reference>L1</location-reference> <vpn-attachment> <vpn-policy-id>VPNPOL1</vpn-policy-id> </vpn-attachment> </site-network-access> </site-network-accesses> <routing-protocols> <routing-protocol> <type>static</type> <static> <cascaded-lan-prefixes> <ipv4-lan-prefixes> <lan>198.51.100.0/30</lan> <next-hop>203.0.113.2</next-hop> </ipv4-lan-prefixes> </cascaded-lan-prefixes> </static> </routing-protocol> </routing-protocols> <management> <type>customer-managed</type> </management> <vpn-policies> <vpn-policy> <vpn-policy-id>VPNPOL1</vpn-policy-id> <entries> <id>1</id> <vpn> <vpn-id>VPN1</vpn-id> <site-role>any-to-any-role</site-role> </vpn>
</entries> </vpn-policy> </vpn-policies> </site> </sites> </l3vpn-svc>
in the service example above, the service component asks the configuration component of the management system to provide the configuration of the service elements 💌. if the service component picked a PE (PE A) as the target PE for the site, the configuration component will need to push the configuration to PE A 🚀. the configuration component will use several YANG data models to define the configuration to be applied to PE A, and the XML snippet config for PE A might look like this 🧚:
<if:interfaces> <if:interface> <if:name>eth0</if:name> <if:type>ianaift:ethernetCsmacd</if:type> <if:description> Link to CE A. </if:description> <ip:ipv4> <ip:address> <ip:ip>203.0.113.254</ip:ip> <ip:prefix-length>24</ip:prefix-length> </ip:address> <ip:forwarding>true</ip:forwarding> </ip:ipv4> </if:interface> </if:interfaces> <rt:routing> <rt:routing-instance> <rt:name>VRF_CustA</rt:name> <rt:type>l3vpn-network:vrf</rt:type> <rt:description>VRF for Customer A</rt:description> <l3vpn-network:rd>100:1546542343</l3vpn-network:rd> <l3vpn-network:import-rt>100:1</l3vpn-network:import-rt> <l3vpn-network:export-rt>100:1</l3vpn-network:export-rt> <rt:interfaces> <rt:interface> <rt:name>eth0</rt:name> </rt:interface> </rt:interfaces> <rt:routing-protocols> <rt:routing-protocol> <rt:type>rt:static</rt:type> <rt:name>st0</rt:name> <rt:static-routes> <v4ur:ipv4> <v4ur:route> <v4ur:destination-prefix>198.51.100.0/30</v4ur:destination-prefix> <v4ur:next-hop> <v4ur:next-hop-address>203.0.113.2</v4ur:next-hop-address> </v4ur:next-hop> </v4ur:route> </v4ur:ipv4> </rt:static-routes> </rt:routing-protocol> </rt:routing-protocols> </rt:routing-instance> </rt:routing>
# 9. YANG Module 🎀
<CODE BEGINS>file "ietf-l3vpn-svc@2018-01-19.yang" module ietf-l3vpn-svc { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"; prefix l3vpn-svc; import ietf-inet-types { prefix inet; } import ietf-yang-types { prefix yang; } import ietf-netconf-acm { prefix nacm; } organization "IETF L3SM Working Group"; contact "WG List: <mailto:l3sm@ietf.org> Editor: L3SM WG Chairs: Adrian Farrel, Qin Wu "; description "This YANG module defines a generic service configuration model for Layer 3 VPNs. This model is common across all vendor implementations.
Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8299; see the RFC itself for full legal notices.";
okay so the revision history is already giving glow-up 💖 this 2018 revision exists to fix implementation issues from the 2017 first draft, which is so relatable 😭 next up are the features (the optional switches 🎀), then the typedefs and identities that give everything its vocab ✨
revision 2018-01-19 { description "Revision of RFC 8049 to fix implementation issues."; reference "RFC 8299"; } revision 2017-01-27 { description "Initial document."; reference "RFC 8049."; } /* Features / feature cloud-access { description "Allows the VPN to connect to a CSP."; } feature multicast { description "Enables multicast capabilities in a VPN."; } feature ipv4 { description "Enables IPv4 support in a VPN."; } feature ipv6 { description "Enables IPv6 support in a VPN."; } feature lan-tag { description "Enables LAN Tag support in a VPN Policy filter."; } feature carrierscarrier { description "Enables support of CsC."; } feature extranet-vpn { description "Enables support of extranet VPNs."; } feature site-diversity { description "Enables support of site diversity constraints."; } feature encryption { description "Enables support of encryption."; } feature qos { description "Enables support of classes of services."; } feature qos-custom { description "Enables support of the custom QoS profile."; } feature rtg-bgp { description "Enables support of the BGP routing protocol."; } feature rtg-rip { description "Enables support of the RIP routing protocol."; } feature rtg-ospf { description "Enables support of the OSPF routing protocol."; } feature rtg-ospf-sham-link { description "Enables support of OSPF sham links."; } feature rtg-vrrp { description "Enables support of the VRRP routing protocol."; } feature fast-reroute { description "Enables support of Fast Reroute."; } feature bfd { description "Enables support of BFD."; } feature always-on { description "Enables support of the 'always-on' access constraint."; } feature requested-type { description "Enables support of the 'requested-type' access constraint."; } feature bearer-reference { description "Enables support of the 'bearer-reference' access constraint."; } feature target-sites { description "Enables support of the 'target-sites' match flow parameter."; } / Typedefs / typedef svc-id { type string; description "Defines a type of service component identifier."; } typedef template-id { type string; description "Defines a type of service template identifier."; } typedef address-family { type enumeration { enum ipv4 { description "IPv4 address family."; } enum ipv6 { description "IPv6 address family."; } } description "Defines a type for the address family."; } / Identities */ identity site-network-access-type { description "Base identity for site-network-access type."; } identity point-to-point { base site-network-access-type; description "Identity for point-to-point connection."; } identity multipoint { base site-network-access-type; description "Identity for multipoint connection. Example: Ethernet broadcast segment."; } identity placement-diversity { description "Base identity for site placement constraints."; } identity bearer-diverse { base placement-diversity; description "Identity for bearer diversity. The bearers should not use common elements."; } identity pe-diverse { base placement-diversity; description "Identity for PE diversity."; } identity pop-diverse { base placement-diversity; description "Identity for POP diversity."; } identity linecard-diverse { base placement-diversity; description "Identity for linecard diversity."; } identity same-pe { base placement-diversity; description "Identity for having sites connected on the same PE."; } identity same-bearer { base placement-diversity; description "Identity for having sites connected using the same bearer."; } identity customer-application { description "Base identity for customer application."; } identity web { base customer-application; description "Identity for Web application (e.g., HTTP, HTTPS)."; } identity mail { base customer-application; description "Identity for mail application."; } identity file-transfer { base customer-application; description "Identity for file transfer application (e.g., FTP, SFTP)."; } identity database { base customer-application; description "Identity for database application."; } identity social { base customer-application; description "Identity for social-network application."; } identity games { base customer-application; description "Identity for gaming application."; } identity p2p { base customer-application; description "Identity for peer-to-peer application."; } identity network-management { base customer-application; description "Identity for management application (e.g., Telnet, syslog, SNMP)."; } identity voice { base customer-application; description "Identity for voice application."; } identity video { base customer-application; description "Identity for video conference application."; } identity embb { base customer-application; description "Identity for an enhanced Mobile Broadband (eMBB) application. Note that an eMBB application demands network performance with a wide variety of characteristics, such as data rate, latency, loss rate, reliability, and many other parameters."; } identity urllc { base customer-application; description "Identity for an Ultra-Reliable and Low Latency Communications (URLLC) application. Note that a URLLC application demands network performance with a wide variety of characteristics, such as latency, reliability, and many other parameters."; } identity mmtc { base customer-application; description "Identity for a massive Machine Type Communications (mMTC) application. Note that an mMTC application demands network performance with a wide variety of characteristics, such as data rate, latency, loss rate, reliability, and many other parameters."; } identity site-vpn-flavor { description "Base identity for the site VPN service flavor."; } identity site-vpn-flavor-single { base site-vpn-flavor; description "Base identity for the site VPN service flavor. Used when the site belongs to only one VPN."; } identity site-vpn-flavor-multi { base site-vpn-flavor; description "Base identity for the site VPN service flavor. Used when a logical connection of a site belongs to multiple VPNs."; } identity site-vpn-flavor-sub { base site-vpn-flavor; description "Base identity for the site VPN service flavor. Used when a site has multiple logical connections. Each connection may belong to different multiple VPNs."; } identity site-vpn-flavor-nni { base site-vpn-flavor; description "Base identity for the site VPN service flavor. Used to describe an NNI option A connection."; } identity management { description "Base identity for site management scheme."; } identity co-managed { base management; description "Base identity for co-managed site."; } identity customer-managed { base management; description "Base identity for customer-managed site."; } identity provider-managed { base management; description "Base identity for provider-managed site."; } identity address-allocation-type { description "Base identity for address-allocation-type for PE-CE link."; } identity provider-dhcp { base address-allocation-type; description "Provider network provides DHCP service to customer."; } identity provider-dhcp-relay { base address-allocation-type; description "Provider network provides DHCP relay service to customer."; } identity provider-dhcp-slaac { base address-allocation-type; description "Provider network provides DHCP service to customer, as well as SLAAC."; } identity static-address { base address-allocation-type; description "Provider-to-customer addressing is static."; } identity slaac { base address-allocation-type; description "Use IPv6 SLAAC."; } identity site-role { description "Base identity for site type."; } identity any-to-any-role { base site-role; description "Site in an any-to-any IP VPN."; } identity spoke-role { base site-role; description "Spoke site in a Hub-and-Spoke IP VPN."; } identity hub-role { base site-role; description "Hub site in a Hub-and-Spoke IP VPN."; } identity vpn-topology { description "Base identity for VPN topology."; } identity any-to-any { base vpn-topology; description "Identity for any-to-any VPN topology."; } identity hub-spoke { base vpn-topology; description "Identity for Hub-and-Spoke VPN topology.";
} identity hub-spoke-disjoint { base vpn-topology; description "Identity for Hub-and-Spoke VPN topology where Hubs cannot communicate with each other."; } identity multicast-tree-type { description "Base identity for multicast tree type."; } identity ssm-tree-type { base multicast-tree-type; description "Identity for SSM tree type."; } identity asm-tree-type { base multicast-tree-type; description "Identity for ASM tree type."; } identity bidir-tree-type { base multicast-tree-type; description "Identity for bidirectional tree type."; } identity multicast-rp-discovery-type { description "Base identity for RP discovery type."; } identity auto-rp { base multicast-rp-discovery-type; description "Base identity for Auto-RP discovery type."; } identity static-rp { base multicast-rp-discovery-type; description "Base identity for static type."; } identity bsr-rp { base multicast-rp-discovery-type; description "Base identity for BSR discovery type."; } identity routing-protocol-type { description "Base identity for routing protocol type.";
---
<lavender>the module is getting so juicy 🌸 more of the identities and the rest of the YANG code are coming next, so stay tuned 🫶</lavender>
<pink>okay the identity list is about to get very cute 🦋 let's go bestie 💅</pink>
} identity ospf { base routing-protocol-type; description "Identity for OSPF protocol type."; } identity bgp { base routing-protocol-type; description "Identity for BGP protocol type."; } identity static { base routing-protocol-type; description "Identity for static routing protocol type."; } identity rip { base routing-protocol-type; description "Identity for RIP protocol type."; } identity vrrp { base routing-protocol-type; description "Identity for VRRP protocol type. This is to be used when LANs are directly connected to PE routers."; } identity direct { base routing-protocol-type; description "Identity for direct protocol type."; } identity protocol-type { description "Base identity for protocol field type."; } identity tcp { base protocol-type; description "TCP protocol type."; } identity udp { base protocol-type; description "UDP protocol type."; } identity icmp { base protocol-type; description "ICMP protocol type."; } identity icmp6 { base protocol-type; description "ICMPv6 protocol type."; } identity gre { base protocol-type; description "GRE protocol type."; } identity ipip { base protocol-type; description "IP-in-IP protocol type."; } identity hop-by-hop { base protocol-type; description "Hop-by-Hop IPv6 header type."; } identity routing { base protocol-type; description "Routing IPv6 header type."; } identity esp { base protocol-type; description "ESP header type."; } identity ah { base protocol-type; description "AH header type."; } identity vpn-policy-filter-type { description "Base identity for VPN Policy filter type."; } identity ipv4 { base vpn-policy-filter-type; description "Identity for IPv4 Prefix filter type.";
} identity ipv6 { base vpn-policy-filter-type; description "Identity for IPv6 Prefix filter type."; } identity lan { base vpn-policy-filter-type; description "Identity for LAN Tag filter type."; }
identity qos-profile-direction { description "Base identity for QoS profile direction."; }
identity site-to-wan { base qos-profile-direction; description "Identity for Site-to-WAN direction."; } identity wan-to-site { base qos-profile-direction; description "Identity for WAN-to-Site direction."; } identity both { base qos-profile-direction; description "Identity for both WAN-to-Site direction and Site-to-WAN direction."; } /* Groupings */ grouping vpn-service-cloud-access { container cloud-accesses { if-feature cloud-access; list cloud-access { key cloud-identifier; leaf cloud-identifier { type leafref { path "/l3vpn-svc/vpn-profiles/"+ "valid-provider-identifiers/cloud-identifier/id"; } description "Identification of cloud service. Local administration meaning."; } choice list-flavor { case permit-any { leaf permit-any { type empty; description "Allows all sites."; } } case deny-any-except { leaf-list permit-site { type leafref { path "/l3vpn-svc/sites/site/site-id"; } description "Site ID to be authorized."; } } case permit-any-except { leaf-list deny-site { type leafref { path "/l3vpn-svc/sites/site/site-id"; } description "Site ID to be denied."; } } description "Choice for cloud access policy. By default, all sites in the IP VPN MUST be authorized to access the cloud."; } container address-translation { container nat44 { leaf enabled { type boolean; default false; description "Controls whether or not Network address translation from IPv4 to IPv4 (NAT44) [RFC3022] is required."; } leaf nat44-customer-address { type inet:ipv4-address; description "Address to be used for network address translation from IPv4 to IPv4. This is to be used if the customer is providing the IPv4 address. If the customer address is not set, the model assumes that the provider will allocate the address."; } description "IPv4-to-IPv4 translation."; } description "Container for NAT."; } description "Cloud access configuration."; } description "Container for cloud access configurations."; } description "Grouping for VPN cloud definition."; } grouping multicast-rp-group-cfg { choice group-format { mandatory true; case singleaddress { leaf group-address { type inet:ip-address; description "A single multicast group address."; } } case startend { leaf group-start { type inet:ip-address; description "The first multicast group address in the multicast group address range."; } leaf group-end { type inet:ip-address; description "The last multicast group address in the multicast group address range."; } } description "Choice for multicast group format."; } description "This grouping defines multicast group or multicast groups for RP-to-group mapping.";
okay so we're deep in the multicast bits now 💖 the RP stuff, the customer locations, and the site diversity groupings are all here, and this part ends partway through `operational-requirements` 🦋
} grouping vpn-service-multicast { container multicast { if-feature multicast; leaf enabled { type boolean; default false; description "Enables multicast."; } container customer-tree-flavors { leaf-list tree-flavor { type identityref { base multicast-tree-type; } description "Type of tree to be used."; } description "Type of trees used by customer."; } container rp { container rp-group-mappings { list rp-group-mapping { key id; leaf id { type uint16; description "Unique identifier for the mapping."; } container provider-managed { leaf enabled { type boolean; default false; description "Set to true if the Rendezvous Point (RP) must be a provider-managed node. Set to false if it is a customer-managed node."; } leaf rp-redundancy { type boolean; default false; description "If true, a redundancy mechanism for the RP is required."; } leaf optimal-traffic-delivery { type boolean; default false; description "If true, the SP must ensure that traffic uses an optimal path. An SP may use Anycast RP or RP-tree-to-SPT switchover architectures."; } description "Parameters for a provider-managed RP."; } leaf rp-address { when "../provider-managed/enabled = 'false'" { description "Relevant when the RP is not provider-managed."; } type inet:ip-address; mandatory true; description "Defines the address of the RP. Used if the RP is customer-managed."; } container groups { list group { key id; leaf id { type uint16; description "Identifier for the group."; } uses multicast-rp-group-cfg; description "List of multicast groups."; } description "Multicast groups associated with the RP."; } description "List of RP-to-group mappings."; } description "RP-to-group mappings parameters."; } container rp-discovery { leaf rp-discovery-type { type identityref { base multicast-rp-discovery-type; } default static-rp; description "Type of RP discovery used."; } container bsr-candidates { when "derived-from-or-self(../rp-discovery-type, "+ "'l3vpn-svc:bsr-rp')" { description "Only applicable if discovery type is BSR-RP."; } leaf-list bsr-candidate-address { type inet:ip-address; description "Address of BSR candidate."; } description "Container for List of Customer BSR candidate's addresses."; } description "RP discovery parameters."; } description "RP parameters."; } description "Multicast global parameters for the VPN service."; } description "Grouping for multicast VPN definition."; } grouping vpn-service-mpls { leaf carrierscarrier { if-feature carrierscarrier; type boolean; default false; description "The VPN is using CsC, and so MPLS is required."; } description "Grouping for MPLS CsC definition."; } grouping customer-location-info { container locations { list location { key location-id; leaf location-id { type svc-id; description "Identifier for a particular location."; } leaf address { type string; description "Address (number and street) of the site."; } leaf postal-code { type string; description "Postal code of the site."; } leaf state { type string; description "State of the site. This leaf can also be used to describe a region for a country that does not have states."; } leaf city { type string; description "City of the site."; } leaf country-code { type string { pattern '[A-Z]{2}'; } description "Country of the site. Expressed as ISO ALPHA-2 code."; } description "Location of the site."; } description "List of locations for the site."; } description "This grouping defines customer location parameters."; } grouping site-group { container groups { list group { key group-id; leaf group-id { type string; description "Group-id the site belongs to."; } description "List of group-ids."; } description "Groups the site or site-network-access belongs to."; } description "Grouping definition to assign group-ids to site or site-network-access."; } grouping site-diversity { container site-diversity { if-feature site-diversity; uses site-group; description "Diversity constraint type. All site-network-accesses will inherit the group values defined here."; } description "This grouping defines site diversity parameters."; } grouping access-diversity { container access-diversity { if-feature site-diversity; uses site-group; container constraints { list constraint { key constraint-type; leaf constraint-type { type identityref { base placement-diversity; } description "Diversity constraint type."; } container target { choice target-flavor { default id; case id { list group { key group-id; leaf group-id { type string; description "The constraint will be applied against this particular group-id for this site network access level."; } description "List of group-ids associated with one specific constraint for this site network access level."; } } case all-accesses { leaf all-other-accesses { type empty; description "The constraint will be applied against all other site network accesses of this site."; } } case all-groups { leaf all-other-groups { type empty; description "The constraint will be applied against all other groups managed by the customer."; } } description "Choice for the target flavor definition."; } description "The constraint will be applied against a Specific target, and the target can be a list of group-ids,all other site network accesses of this site, or all other groups managed by the customer."; } description "List of constraints."; } description "Placement constraints for this site network access."; } description "Diversity parameters."; } description "This grouping defines access diversity parameters."; } grouping operational-requirements { leaf requested-site-start { type yang:date-and-time; description "Optional leaf indicating requested date and time when the service at a particular site is expected to start."; }
<pink>the multicast grouping is a whole mood ✨</pink> it's got a global on/off switch, a list of the tree flavors the customer wants, and then an RP section where the RP can be provider-managed or customer-managed 💅 the `rp-group-mapping` list ties each RP to its multicast groups, and the BSR candidate addresses only show up when the discovery type is BSR-RP 🎀
the location and site stuff is giving org chart 🌸 each site gets a list of locations with the address, postal code, state, city, and a two-letter country code, and sites can be put into groups so the diversity constraints know who's who 🧚
<hotpink>more groupings are coming next, so stay tuned</hotpink> 🫶
okay the YANG is getting SPICY now 🌶️💅 we're deep in the grouping zone, so buckle up bestie 🎀
leaf requested-site-stop { type yang:date-and-time; description "Optional leaf indicating requested date and time when the service at a particular site is expected to stop."; } description "This grouping defines some operational parameters."; } grouping operational-requirements-ops { leaf actual-site-start { type yang:date-and-time; config false; description "Optional leaf indicating actual date and time when the service at a particular site actually started."; } leaf actual-site-stop { type yang:date-and-time; config false; description "Optional leaf indicating actual date and time when the service at a particular site actually stopped."; } description "This grouping defines some operational parameters."; } grouping flow-definition { container match-flow { leaf dscp { type inet:dscp; description "DSCP value."; } leaf dot1p { type uint8 { range "0..7"; } description "802.1p matching."; } leaf ipv4-src-prefix { type inet:ipv4-prefix; description "Match on IPv4 src address."; } leaf ipv6-src-prefix { type inet:ipv6-prefix; description "Match on IPv6 src address."; } leaf ipv4-dst-prefix { type inet:ipv4-prefix; description "Match on IPv4 dst address."; } leaf ipv6-dst-prefix { type inet:ipv6-prefix; description "Match on IPv6 dst address."; } leaf l4-src-port { type inet:port-number; must "current() < ../l4-src-port-range/lower-port or "+ "current() > ../l4-src-port-range/upper-port" { description "If l4-src-port and l4-src-port-range/lower-port and upper-port are set at the same time, l4-src-port should not overlap with l4-src-port-range."; } description "Match on Layer 4 src port."; } leaf-list target-sites { if-feature target-sites; type svc-id; description "Identify a site as traffic destination."; } container l4-src-port-range { leaf lower-port { type inet:port-number; description "Lower boundary for port."; } leaf upper-port { type inet:port-number; must ". >= ../lower-port" { description "Upper boundary for port. If it exists, the upper boundary must be higher than the lower boundary."; } description "Upper boundary for port."; } description "Match on Layer 4 src port range. When only the lower-port is present, it represents a single port. When both the lower-port and upper-port are specified, it implies a range inclusive of both values."; } leaf l4-dst-port { type inet:port-number; must "current() < ../l4-dst-port-range/lower-port or "+ "current() > ../l4-dst-port-range/upper-port" { description "If l4-dst-port and l4-dst-port-range/lower-port and upper-port are set at the same time, l4-dst-port should not overlap with l4-src-port-range."; } description "Match on Layer 4 dst port."; } container l4-dst-port-range { leaf lower-port { type inet:port-number; description "Lower boundary for port."; } leaf upper-port { type inet:port-number; must ". >= ../lower-port" { description "Upper boundary must be higher than lower boundary."; } description "Upper boundary for port. If it exists, upper boundary must be higher than lower boundary."; } description "Match on Layer 4 dst port range. When only lower-port is present, it represents a single port. When both lower-port and upper-port are specified, it implies a range inclusive of both values."; } leaf protocol-field { type union { type uint8; type identityref { base protocol-type; } } description "Match on IPv4 protocol or IPv6 Next Header field."; } description "Describes flow-matching criteria."; } description "Flow definition based on criteria."; } grouping site-service-basic { leaf svc-input-bandwidth { type uint64; units bps; mandatory true; description "From the customer site's perspective, the service input bandwidth of the connection or download bandwidth from the SP to the site."; } leaf svc-output-bandwidth { type uint64; units bps; mandatory true; description "From the customer site's perspective, the service output bandwidth of the connection or upload bandwidth from the site to the SP."; } leaf svc-mtu { type uint16; units bytes; mandatory true; description "MTU at service level. If the service is IP, it refers to the IP MTU. If CsC is enabled, the requested 'svc-mtu' leaf will refer to the MPLS MTU and not to the IP MTU."; } description "Defines basic service parameters for a site."; } grouping site-protection { container traffic-protection { if-feature fast-reroute; leaf enabled { type boolean; default false; description "Enables traffic protection of access link."; } description "Fast Reroute service parameters for the site."; } description "Defines protection service parameters for a site."; } grouping site-service-mpls { container carrierscarrier { if-feature carrierscarrier; leaf signalling-type { type enumeration { enum ldp { description "Use LDP as the signalling protocol between the PE and the CE. In this case, an IGP routing protocol must also be activated."; } enum bgp { description "Use BGP (as per RFC 8277) as the signalling protocol between the PE and the CE. In this case, BGP must also be configured as the routing protocol."; } } default bgp; description "MPLS signalling type.";
} description "This container is used when the customer provides MPLS-based services. This is only used in the case of CsC (i.e., a customer builds an MPLS service using an IP VPN to carry its traffic)."; } description "Defines MPLS service parameters for a site."; } grouping site-service-qos-profile { container qos { if-feature qos; container qos-classification-policy { list rule { key id; ordered-by user; leaf id { type string; description "A description identifying the qos-classification-policy rule."; } choice match-type { default match-flow; case match-flow { uses flow-definition; } case match-application { leaf match-application { type identityref { base customer-application; } description "Defines the application to match."; } } description "Choice for classification."; } leaf target-class-id { type string; description "Identification of the class of service. This identifier is internal to the administration."; } description "List of marking rules.";
} description "Configuration of the traffic classification policy."; } container qos-profile { choice qos-profile { description "Choice for QoS profile. Can be standard profile or customized profile."; case standard { description "Standard QoS profile."; leaf profile { type leafref { path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers"+ "/qos-profile-identifier/id"; } description "QoS profile to be used."; } } case custom { description "Customized QoS profile."; container classes { if-feature qos-custom; list class { key class-id; leaf class-id { type string; description "Identification of the class of service. This identifier is internal to the administration."; } leaf direction { type identityref { base qos-profile-direction; } default both; description "The direction to which the QoS profile is applied."; } leaf rate-limit { type decimal64 { fraction-digits 5; range "0..100";
} units percent; description "To be used if the class must be rate-limited. Expressed as percentage of the service bandwidth."; } container latency { choice flavor { case lowest { leaf use-lowest-latency { type empty; description "The traffic class should use the path with the lowest latency."; } } case boundary { leaf latency-boundary { type uint16; units msec; default 400; description "The traffic class should use a path with a defined maximum latency."; } } description "Latency constraint on the traffic class."; } description "Latency constraint on the traffic class."; } container jitter { choice flavor { case lowest { leaf use-lowest-jitter { type empty; description "The traffic class should use the path with the lowest jitter."; } } case boundary { leaf latency-boundary { type uint32; units usec; default 40000;
description "The traffic class should use a path with a defined maximum jitter."; } } description "Jitter constraint on the traffic class."; } description "Jitter constraint on the traffic class."; } container bandwidth { leaf guaranteed-bw-percent { type decimal64 { fraction-digits 5; range "0..100"; } units percent; mandatory true; description "To be used to define the guaranteed bandwidth as a percentage of the available service bandwidth."; } leaf end-to-end { type empty; description "Used if the bandwidth reservation must be done on the MPLS network too."; } description "Bandwidth constraint on the traffic class."; } description "List of classes of services."; } description "Container for list of classes of services."; } } } description "QoS profile configuration."; } description "QoS configuration."; } description "This grouping defines QoS parameters for a site.";
} grouping site-security-authentication { container authentication { description "Authentication parameters."; } description "This grouping defines authentication parameters for a site."; } grouping site-security-encryption { container encryption { if-feature encryption; leaf enabled { type boolean; default false; description "If true, traffic encryption on the connection is required."; } leaf layer { when "../enabled = 'true'" { description "Require a value for layer when enabled is true."; } type enumeration { enum layer2 { description "Encryption will occur at Layer 2."; } enum layer3 { description "Encryption will occur at Layer 3. For example, IPsec may be used when a customer requests Layer 3 encryption."; } } description "Layer on which encryption is applied."; } container encryption-profile { choice profile { case provider-profile { leaf profile-name { type leafref { path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers"+ "/encryption-profile-identifier/id"; } description "Name of the SP profile to be applied.";
} } case customer-profile { leaf algorithm { type string; description "Encryption algorithm to be used."; } choice key-type { default psk; case psk { leaf preshared-key { type string; description "Pre-Shared Key (PSK) coming from the customer."; } } description "Type of keys to be used."; } } description "Choice of encryption profile. The encryption profile can be the provider profile or customer profile."; } description "Profile of encryption to be applied."; } description "Encryption parameters."; } description "This grouping defines encryption parameters for a site."; }
Okay, the encryption grouping is giving layers 🔐💖 Layer 2 or Layer 3, and the profile can be either the provider's or the customer's, so it's giving choice 💅✨ Next up is the bearer stuff, which is all about how the site connects in the first place 🦋
grouping site-attachment-bearer { container bearer { container requested-type { if-feature requested-type; leaf requested-type { type string; description "Type of requested bearer: Ethernet, DSL, Wireless, etc. Operator specific."; } leaf strict { type boolean; default false; description "Defines whether requested-type is a preference or a strict requirement."; } description "Container for requested-type."; } leaf always-on { if-feature always-on; type boolean; default true; description "Request for an always-on access type. For example, this could mean no dial access type."; } leaf bearer-reference { if-feature bearer-reference; type string; description "This is an internal reference for the SP."; } description "Bearer-specific parameters. To be augmented."; } description "Defines physical properties of a site attachment."; } grouping site-routing { container routing-protocols { list routing-protocol { key type; leaf type { type identityref { base routing-protocol-type; } description "Type of routing protocol."; } container ospf { when "derived-from-or-self(../type, 'l3vpn-svc:ospf')" { description "Only applies when protocol is OSPF."; } if-feature rtg-ospf; leaf-list address-family { type address-family; min-elements "1"; description "If OSPF is used on this site, this node contains a configured value. This node contains at least one address family to be activated."; } leaf area-address { type yang:dotted-quad; mandatory true; description "Area address."; } leaf metric { type uint16; default 1; description "Metric of the PE-CE link. It is used in the routing state calculation and path selection."; } container sham-links { if-feature rtg-ospf-sham-link; list sham-link { key target-site; leaf target-site { type svc-id; description "Target site for the sham link connection. The site is referred to by its ID."; } leaf metric { type uint16; default 1; description "Metric of the sham link. It is used in the routing state calculation and path selection. The default value is set to 1."; } description "Creates a sham link with another site."; } description "List of sham links."; } description "OSPF-specific configuration."; } container bgp {
when "derived-from-or-self(../type, 'l3vpn-svc:bgp')" { description "Only applies when protocol is BGP."; } if-feature rtg-bgp; leaf autonomous-system { type uint32; mandatory true; description "Customer AS number in case the customer requests BGP routing."; } leaf-list address-family { type address-family; min-elements "1"; description "If BGP is used on this site, this node contains a configured value. This node contains at least one address family to be activated."; } description "BGP-specific configuration."; } container static { when "derived-from-or-self(../type, 'l3vpn-svc:static')" { description "Only applies when protocol is static. BGP activation requires the SP to know the address of the customer peer. When BGP is enabled, the 'static-address' allocation type for the IP connection MUST be used."; } container cascaded-lan-prefixes { list ipv4-lan-prefixes { if-feature ipv4; key "lan next-hop"; leaf lan { type inet:ipv4-prefix; description "LAN prefixes."; } leaf lan-tag { type string; description "Internal tag to be used in VPN policies."; } leaf next-hop { type inet:ipv4-address; description "Next-hop address to use on the customer side."; } description "List of LAN prefixes for the site."; } list ipv6-lan-prefixes { if-feature ipv6; key "lan next-hop"; leaf lan { type inet:ipv6-prefix; description "LAN prefixes."; } leaf lan-tag { type string; description "Internal tag to be used in VPN policies."; } leaf next-hop { type inet:ipv6-address; description "Next-hop address to use on the customer side."; } description "List of LAN prefixes for the site."; } description "LAN prefixes from the customer."; } description "Configuration specific to static routing."; } container rip { when "derived-from-or-self(../type, 'l3vpn-svc:rip')" { description "Only applies when the protocol is RIP. For IPv4, the model assumes that RIP version 2 is used."; } if-feature rtg-rip; leaf-list address-family { type address-family; min-elements "1"; description "If RIP is used on this site, this node contains a configured value. This node contains at least one address family to be activated."; } description "Configuration specific to RIP routing."; } container vrrp { when "derived-from-or-self(../type, 'l3vpn-svc:vrrp')" { description "Only applies when protocol is VRRP."; } if-feature rtg-vrrp; leaf-list address-family { type address-family; min-elements "1"; description "If VRRP is used on this site, this node contains a configured value. This node contains at least one address family to be activated."; } description "Configuration specific to VRRP routing."; } description "List of routing protocols used on the site. This list can be augmented."; } description "Defines routing protocols."; } description "Grouping for routing protocols."; }
The routing grouping is a whole buffet 🧚 OSPF, BGP, static, RIP and VRRP all live in there, each with its own little `when` gate so it only shows up when that protocol is the one being used 💜 Last stop for this part is the IP connection grouping, which is where the address allocation drama starts 🎀
grouping site-attachment-ip-connection { container ip-connection { container ipv4 { if-feature ipv4; leaf address-allocation-type { type identityref { base address-allocation-type; } must "not(derived-from-or-self(current(), 'l3vpn-svc:slaac') or "+ "derived-from-or-self(current(), "+ "'l3vpn-svc:provider-dhcp-slaac'))" { error-message "SLAAC is only applicable to IPv6"; } description "Defines how addresses are allocated.
If there is no value for the address allocation type, then IPv4 is not enabled."; } container provider-dhcp { when "derived-from-or-self(../address-allocation-type, "+ "'l3vpn-svc:provider-dhcp')" { description "Only applies when addresses are allocated by DHCP."; } leaf provider-address { type inet:ipv4-address; description "Address of provider side. If provider-address is not specified, then prefix length should not be specified either. It also implies provider-dhcp allocation is not enabled. If provider-address is specified, then the prefix length may or may not be specified."; } leaf prefix-length { type uint8 { range "0..32"; } must "(../provider-address)" { error-message "If the prefix length is specified, provider-address must also be specified."; description "If the prefix length is specified, provider-address must also be specified."; } description "Subnet prefix length expressed in bits. If not specified, or specified as zero, this means the customer leaves the actual prefix length value to the provider."; } choice address-assign { default number; case number { leaf number-of-dynamic-address { type uint16; default 1; description "Describes the number of IP addresses the customer requires."; } } case explicit {
<rainbow>Okay bestie, keep going with the DHCP stuff</rainbow> 🎀 So the `customer-addresses` container is where the customer's DHCP-allocated addresses live, and it's giving very organised vibes 💅 Each `address-group` is a list keyed by `group-id` 🦋, and every group is a `start-address` to an `end-address` range, both inclusive ✨ If you only fill in one of them, it's just a single address, which is so simple 🌸 And if you leave both out entirely, the group basically says "we don't support customer addresses here" 🙈
container customer-addresses { list address-group { key "group-id"; leaf group-id { type string; description "Group-id for the address range from start-address to end-address."; } leaf start-address { type inet:ipv4-address; description "First address."; } leaf end-address { type inet:ipv4-address; description "Last address."; } description "Describes IP addresses allocated by DHCP. When only start-address or only end-address is present, it represents a single address. When both start-address and end-address are specified, it implies a range inclusive of both addresses. If no address is specified, it implies customer addresses group is not supported."; } description "Container for customer addresses is allocated by DHCP."; } } description "Choice for the way to assign addresses."; } description "DHCP allocated addresses related parameters."; } container dhcp-relay { when "derived-from-or-self(../address-allocation-type, "+ "'l3vpn-svc:provider-dhcp-relay')" { description "Only applies when provider is required to implement DHCP relay function."; } leaf provider-address { type inet:ipv4-address; description "Address of provider side. If provider-address is not specified, then prefix length should not be specified either. It also implies provider-dhcp allocation is not enabled. If provider-address is specified, then prefix length may or may not be specified."; } leaf prefix-length { type uint8 { range "0..32"; } must "(../provider-address)" { error-message "If prefix length is specified, provider-address must also be specified."; description "If prefix length is specified, provider-address must also be specified."; } description "Subnet prefix length expressed in bits. If not specified, or specified as zero, this means the customer leaves the actual prefix length value to the provider."; } container customer-dhcp-servers { leaf-list server-ip-address { type inet:ipv4-address; description "IP address of customer DHCP server."; } description "Container for list of customer DHCP servers."; } description "DHCP relay provided by operator."; } container addresses { when "derived-from-or-self(../address-allocation-type, "+ "'l3vpn-svc:static-address')" { description "Only applies when protocol allocation type is static."; } leaf provider-address { type inet:ipv4-address; description "IPv4 Address List of the provider side. When the protocol allocation type is static, the provider address must be configured.";
} leaf customer-address { type inet:ipv4-address; description "IPv4 Address of customer side."; } leaf prefix-length { type uint8 { range "0..32"; } description "Subnet prefix length expressed in bits. It is applied to both provider-address and customer-address."; } description "Describes IPv4 addresses used."; } description "IPv4-specific parameters."; } container ipv6 { if-feature ipv6; leaf address-allocation-type { type identityref { base address-allocation-type; } description "Defines how addresses are allocated. If there is no value for the address allocation type, then IPv6 is not enabled."; }
container provider-dhcp { when "derived-from-or-self(../address-allocation-type, "+ "'l3vpn-svc:provider-dhcp') "+ "or derived-from-or-self(../address-allocation-type, "+ "'l3vpn-svc:provider-dhcp-slaac')" { description "Only applies when addresses are allocated by DHCP."; } leaf provider-address { type inet:ipv6-address; description "Address of the provider side. If provider-address is not specified, then prefix length should not be specified either. It also implies provider-dhcp allocation is not enabled. If provider-address is specified, then prefix length may or may not be specified."; } leaf prefix-length { type uint8 { range "0..128"; } must "(../provider-address)" { error-message "If prefix length is specified, provider-address must also be specified."; description "If prefix length is specified, provider-address must also be specified."; } description "Subnet prefix length expressed in bits. If not specified, or specified as zero, this means the customer leaves the actual prefix length value to the provider."; } choice address-assign { default number; case number { leaf number-of-dynamic-address { type uint16; default 1; description "Describes the number of IP addresses the customer requires."; } } case explicit { container customer-addresses { list address-group { key "group-id"; leaf group-id { type string; description "Group-id for the address range from start-address to end-address."; } leaf start-address { type inet:ipv6-address; description "First address."; }
leaf end-address { type inet:ipv6-address; description "Last address."; } description "Describes IP addresses allocated by DHCP. When only start-address or only end-address is present, it represents a single address. When both start-address and end-address are specified, it implies a range inclusive of both addresses. If no address is specified, it implies customer addresses group is not supported."; } description "Container for customer addresses allocated by DHCP."; } } description "Choice for the way to assign addresses."; } description "DHCP allocated addresses related parameters."; } container dhcp-relay { when "derived-from-or-self(../address-allocation-type, "+ "'l3vpn-svc:provider-dhcp-relay')" { description "Only applies when the provider is required to implement DHCP relay function."; } leaf provider-address { type inet:ipv6-address; description "Address of the provider side. If provider-address is not specified, then prefix length should not be specified either. It also implies provider-dhcp allocation is not enabled. If provider address is specified, then prefix length may or may not be specified."; } leaf prefix-length { type uint8 { range "0..128"; } must "(../provider-address)" { error-message "If prefix length is specified, provider-address must also be specified."; description "If prefix length is specified, provider-address must also be specified."; } description "Subnet prefix length expressed in bits. If not specified, or specified as zero, this means the customer leaves the actual prefix length value to the provider."; } container customer-dhcp-servers { leaf-list server-ip-address { type inet:ipv6-address; description "This node contains the IP address of the customer DHCP server. If the DHCP relay function is implemented by the provider, this node contains the configured value."; } description "Container for list of customer DHCP servers."; } description "DHCP relay provided by operator."; } container addresses { when "derived-from-or-self(../address-allocation-type, "+ "'l3vpn-svc:static-address')" { description "Only applies when protocol allocation type is static."; } leaf provider-address { type inet:ipv6-address; description "IPv6 Address of the provider side. When the protocol allocation type is static, the provider address must be configured."; } leaf customer-address { type inet:ipv6-address; description "The IPv6 Address of the customer side."; } leaf prefix-length { type uint8 { range "0..128";
---
<lavender>Part 28 of 31 done, bestie!</lavender> 💜 Next up we keep going through the IPv6 side of things 🧚
<mint>okay bestie, the BFD holdtime is giving two flavours: a fixed value or a provider profile 💅✨</mint> <pink>the multicast site types and protocol types are also lowkey iconic 🎀</pink>
} description "Subnet prefix length expressed in bits. It is applied to both provider-address and customer-address."; } description "Describes IPv6 addresses used."; } description "IPv6-specific parameters."; } container oam { container bfd { if-feature bfd; leaf enabled { type boolean; default false; description "If true, BFD activation is required."; } choice holdtime { default fixed; case fixed { leaf fixed-value { type uint32; units msec; description "Expected BFD holdtime expressed in msec. The customer may impose some fixed values for the holdtime period if the provider allows the customer use this function. If the provider doesn't allow the customer to use this function, the fixed-value will not be set."; } } case profile { leaf profile-name { type leafref { path "/l3vpn-svc/vpn-profiles/valid-provider-identifiers/"+ "bfd-profile-identifier/id"; } description "Well-known SP profile name. The provider can propose some profiles to the customer, depending on the service level the customer wants to achieve. Profile names must be communicated to the customer."; } description "Well-known SP profile."; } description "Choice for holdtime flavor."; } description "Container for BFD."; } description "Defines the Operations, Administration, and Maintenance (OAM) mechanisms used on the connection. BFD is set as a fault detection mechanism, but the 'oam' container can easily be augmented by other mechanisms"; } description "Defines connection parameters."; } description "This grouping defines IP connection parameters."; } grouping site-service-multicast { container multicast { if-feature multicast; leaf multicast-site-type { type enumeration { enum receiver-only { description "The site only has receivers."; } enum source-only { description "The site only has sources."; } enum source-receiver { description "The site has both sources and receivers."; } } default source-receiver; description "Type of multicast site."; } container multicast-address-family { leaf ipv4 { if-feature ipv4; type boolean; default false; description "Enables IPv4 multicast."; } leaf ipv6 { if-feature ipv6; type boolean; default false; description "Enables IPv6 multicast."; } description "Defines protocol to carry multicast."; } leaf protocol-type { type enumeration { enum host { description "Hosts are directly connected to the provider network. Host protocols such as IGMP or MLD are required."; } enum router { description "Hosts are behind a customer router. PIM will be implemented."; } enum both { description "Some hosts are behind a customer router, and some others are directly connected to the provider network. Both host and routing protocols must be used. Typically, IGMP and PIM will be implemented."; } } default "both"; description "Multicast protocol type to be used with the customer site."; } description "Multicast parameters for the site."; } description "Multicast parameters for the site."; } grouping site-management { container management { leaf type { type identityref { base management;
} mandatory true; description "Management type of the connection."; } description "Management configuration."; } description "Management parameters for the site."; } grouping site-devices { container devices { when "derived-from-or-self(../management/type, "+ "'l3vpn-svc:provider-managed') or "+ "derived-from-or-self(../management/type, 'l3vpn-svc:co-managed')" { description "Applicable only for provider-managed or co-managed device."; } list device { key device-id; leaf device-id { type svc-id; description "Identifier for the device."; } leaf location { type leafref { path "../../../locations/"+ "location/location-id"; } mandatory true; description "Location of the device."; } container management { when "derived-from-or-self(../../../management/type,"+ "'l3vpn-svc:co-managed')" { description "Applicable only for co-managed device."; } leaf address-family { type address-family; description "Address family used for management."; } leaf address {
when "(../address-family)" { description "If address-family is specified, then address should also be specified. If address-family is not specified, then address should also not be specified."; } type inet:ip-address; mandatory true; description "Management address."; } description "Management configuration. Applicable only for co-managed device."; } description "List of devices requested by customer."; } description "Device configuration."; } description "Grouping for device allocation."; } grouping site-vpn-flavor { leaf site-vpn-flavor { type identityref { base site-vpn-flavor; } default site-vpn-flavor-single; description "Defines the way the VPN multiplexing is done, e.g., whether the site belongs to a single VPN site or a multiVPN; or, in the case of a multiVPN, whether the logical accesses of the sites belong to the same set of VPNs or each logical access maps to different VPNs."; } description "Grouping for site VPN flavor."; } grouping site-vpn-policy { container vpn-policies { list vpn-policy { key vpn-policy-id; leaf vpn-policy-id { type svc-id; description "Unique identifier for the VPN policy.";
Okay bestie, first up is the VPN policy filter stuff, and it is *giving* granular 🦋 You can split a site's LANs across multiple VPNs using a LAN Tag or a LAN prefix. If you don't add a filter, every LAN just joins the same VPNs with the same role. Iconic 💅
} list entries { key id; leaf id { type svc-id; description "Unique identifier for the policy entry."; } container filters { list filter { key type; ordered-by user; leaf type { type identityref { base vpn-policy-filter-type; } description "Type of VPN Policy filter."; } leaf-list lan-tag { when "derived-from-or-self(../type, 'l3vpn-svc:lan')" { description "Only applies when the VPN Policy filter is a LAN Tag filter."; } if-feature lan-tag; type string; description "List of 'lan-tag' items to be matched. LAN Tag is an Internal tag to be used in VPN policies "; } leaf-list ipv4-lan-prefix { when "derived-from-or-self(../type, 'l3vpn-svc:ipv4')" { description "Only applies when VPN Policy filter is IPv4 Prefix filter."; } if-feature ipv4; type inet:ipv4-prefix; description "List of IPv4 prefixes as LAN Prefixes to be matched."; } leaf-list ipv6-lan-prefix { when "derived-from-or-self(../type, 'l3vpn-svc:ipv6')" { description "Only applies when VPN Policy filter is IPv6 Prefix filter."; } if-feature ipv6; type inet:ipv6-prefix; description "List of IPv6 prefixes as LAN prefixes to be matched."; } description "List of filters used on the site. This list can be augmented."; } description "If a more-granular VPN attachment is necessary, filtering can be used. If used, it permits the splitting of site LANs among multiple VPNs. The Site LAN can be split based on either LAN Tag or LAN prefix. If no filter is used, all the LANs will be part of the same VPNs with the same role."; } list vpn { key vpn-id; leaf vpn-id { type leafref { path "/l3vpn-svc/vpn-services/"+ "vpn-service/vpn-id"; } mandatory true; description "Reference to an IP VPN."; } leaf site-role { type identityref { base site-role; } default any-to-any-role; description "Role of the site in the IP VPN."; } description "List of VPNs the LAN is associated with."; } description "List of entries for export policy."; } description "List of VPN policies."; } description "VPN policy."; } description "VPN policy parameters for the site."; } grouping site-maximum-routes { container maximum-routes { list address-family { key af; leaf af { type address-family; description "Address family."; } leaf maximum-routes { type uint32; description "Maximum prefixes the VRF can accept for this address family."; } description "List of address families."; } description "Defines 'maximum-routes' for the VRF."; } description "Defines 'maximum-routes' for the site."; } grouping site-security { container security { uses site-security-authentication; uses site-security-encryption; description "Site-specific security parameters."; } description "Grouping for security parameters."; } grouping site-service { container service { uses site-service-qos-profile; uses site-service-mpls; uses site-service-multicast; description "Service parameters on the attachment."; } description "Grouping for service parameters."; } grouping site-network-access-service { container service { uses site-service-basic; uses site-service-qos-profile; uses site-service-mpls; uses site-service-multicast; description "Service parameters on the attachment."; } description "Grouping for service parameters."; }
---
<mint>Extranets next, and this one's so cute 🧚 The extranet grouping gives you an easy way to connect all the sites from two VPNs.</mint> The role rules here are a whole vibe, so read them carefully 💖
grouping vpn-extranet { container extranet-vpns { if-feature extranet-vpn; list extranet-vpn { key vpn-id; leaf vpn-id { type svc-id; description "Identifies the target VPN the local VPN want to access."; } leaf local-sites-role { type identityref { base site-role; } default any-to-any-role; description "This describes the role of the local sites in the target VPN topology. In the any-to-any VPN service topology, the local sites must have the same role, which will be 'any-to-any-role'. In the Hub-and-Spoke VPN service topology or the Hub-and-Spoke disjoint VPN service topology, the local sites must have a Hub role or a Spoke role."; } description "List of extranet VPNs or target VPNs the local VPN is attached to."; } description "Container for extranet VPN configuration."; } description "Grouping for extranet VPN configuration. This provides an easy way to interconnect all sites from two VPNs."; } grouping site-attachment-availability { container availability { leaf access-priority { type uint32; default 100; description "Defines the priority for the access. The higher the access-priority value, the higher the preference of the access will be."; } description "Availability parameters (used for multihoming)."; } description "Defines availability parameters for a site."; } grouping access-vpn-policy { container vpn-attachment { choice attachment-flavor { case vpn-policy-id { leaf vpn-policy-id { type leafref { path "../../../../"+ "vpn-policies/vpn-policy/"+ "vpn-policy-id"; } description "Reference to a VPN policy. When referencing VPN policy for attachment, the vpn-policy-id must be configured."; } } case vpn-id { leaf vpn-id { type leafref { path "/l3vpn-svc/vpn-services"+ "/vpn-service/vpn-id"; } description "Reference to an IP VPN. Referencing a vpn-id provides an easy way to attach a particular logical access to a VPN. In this case, vpn-id must be configured."; } leaf site-role { type identityref { base site-role; } default any-to-any-role; description "Role of the site in the IP VPN. When referencing a vpn-id, the site-role setting must be added to express the role of the site in the target VPN service topology."; } } mandatory true; description "Choice for VPN attachment flavor. A choice is implemented to allow the user to choose the flavor that provides the best fit."; } description "Defines VPN attachment of a site."; } description "Defines the VPN attachment rules for a site's logical access."; } grouping vpn-profile-cfg { container valid-provider-identifiers { list cloud-identifier { if-feature cloud-access; key id; leaf id { type string; description "Identification of cloud service. Local administration meaning."; } description "List for Cloud Identifiers."; } list encryption-profile-identifier { key id; leaf id { type string; description "Identification of the SP encryption profile to be used. Local administration meaning."; } description "List for encryption profile identifiers."; } list qos-profile-identifier { key id; leaf id { type string; description "Identification of the QoS Profile to be used. Local administration meaning.";
} description "List for QoS Profile Identifiers."; } list bfd-profile-identifier { key id; leaf id { type string; description "Identification of the SP BFD Profile to be used. Local administration meaning."; } description "List for BFD Profile identifiers."; } nacm:default-deny-write; description "Container for Valid Provider Identifies."; } description "Grouping for VPN Profile configuration."; }
---
<lavender>Now the VPN service config, which is basically the main character of this whole module 👑</lavender> It has the VPN ID, the customer name, and the topology (any-to-any is the default 🌸).
grouping vpn-svc-cfg { leaf vpn-id { type svc-id; description "VPN identifier. Local administration meaning."; } leaf customer-name { type string; description "Name of the customer that actually uses the VPN service. In the case that any intermediary (e.g., Tier-2 provider or partner) sells the VPN service to their end user on behalf of the original service provider (e.g., Tier-1 provider), the original service provider may require the customer name to provide smooth activation/commissioning and operation for the service."; } leaf vpn-service-topology { type identityref { base vpn-topology; } default any-to-any; description "VPN service topology."; } uses vpn-service-cloud-access; uses vpn-service-multicast; uses vpn-service-mpls; uses vpn-extranet; description "Grouping for VPN service configuration."; } grouping site-top-level-cfg { uses operational-requirements; uses customer-location-info; uses site-devices; uses site-diversity; uses site-management; uses site-vpn-policy; uses site-vpn-flavor; uses site-maximum-routes; uses site-security; uses site-service; uses site-protection; uses site-routing; description "Grouping for site top-level configuration."; } grouping site-network-access-top-level-cfg { leaf site-network-access-type { type identityref { base site-network-access-type; } default point-to-point; description "Describes the type of connection, e.g., point-to-point or multipoint."; } choice location-flavor { case location { when "derived-from-or-self(../../management/type, "+ "'l3vpn-svc:customer-managed')" { description "Applicable only for customer-managed device."; } leaf location-reference { type leafref { path "../../../locations/location/location-id"; } description "Location of the site-network-access."; } } case device {
when "derived-from-or-self(../../management/type, "+ "'l3vpn-svc:provider-managed') or "+ "derived-from-or-self(../../management/type, "+ "'l3vpn-svc:co-managed')" { description "Applicable only for provider-managed or co-managed device."; } leaf device-reference { type leafref { path "../../../devices/device/device-id"; } description "Identifier of CE to use."; } } mandatory true; description "Choice of how to describe the site's location."; } uses access-diversity; uses site-attachment-bearer; uses site-attachment-ip-connection; uses site-security; uses site-network-access-service; uses site-routing; uses site-attachment-availability; uses access-vpn-policy; description "Grouping for site network access top-level configuration."; } /* Main blocks */ container l3vpn-svc { container vpn-profiles { uses vpn-profile-cfg; description "Container for VPN Profiles."; } container vpn-services { list vpn-service { key vpn-id; uses vpn-svc-cfg; description "List of VPN services."; } description "Top-level container for the VPN services."; } container sites {
list site { key site-id; leaf site-id { type svc-id; description "Identifier of the site."; } uses site-top-level-cfg; uses operational-requirements-ops; container site-network-accesses { list site-network-access { key site-network-access-id; leaf site-network-access-id { type svc-id; description "Identifier for the access."; } uses site-network-access-top-level-cfg; description "List of accesses for a site."; } description "List of accesses for a site."; } description "List of sites."; } description "Container for sites."; } description "Main container for L3VPN service configuration."; } } <CODE ENDS>
---
# 10. Security Considerations 🔐
Okay bestie, this YANG module is a schema for data that's meant to be reached over network management protocols like NETCONF [RFC6241] or RESTCONF [RFC8040] 💖. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport there is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and its mandatory-to-implement secure transport is TLS [RFC5246]. Security is not optional, periodt 💅.
The NETCONF access control model [RFC6536] lets you restrict particular NETCONF or RESTCONF users to a preconfigured subset of all the available protocol operations and content. Main character access control energy ✨.
A bunch of data nodes in this module are writable, creatable and deletable (that's `config true`, which is the default) 🙈. These can be sensitive or vulnerable in some network environments, and write operations like edit-config to them without proper protection can have a negative effect on network operations. The subtrees and data nodes, and why they're sensitive, are:
- `/l3vpn-svc/vpn-services/vpn-service`: the entries in this list include the whole VPN service configurations the customer subscribes to, and they indirectly create or modify the PE and CE device configurations. Unexpected changes to these entries could lead to service disruption and/or network misbehavior 😭.
- `/l3vpn-svc/sites/site`: the entries in this list include the customer site configurations. Same as above, unexpected changes to these entries could lead to service disruption and/or network misbehavior 💀.
Some of the readable data nodes in this module may also be sensitive or vulnerable, so it's really important to control read access (for example via get, get-config, or notification) to them 👀. These are the subtrees and data nodes:
- `/l3vpn-svc/vpn-services/vpn-service`
- `/l3vpn-svc/sites/site`
The entries in those lists include customer-proprietary or confidential information, like the customer name, site location, and what service the customer subscribes to. Keep that tea private 🤫.
> The data model defines some security parameters that can be extended via augmentation as part of the customer service request. Those parameters are described in Section 6.9, so go check them out before you augment anything 🚨.
---
# 11. IANA Considerations 🌈
IANA has assigned a new URI from the "IETF XML Registry" [RFC3688] 🎀:
URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc Registrant Contact: The IESG XML: N/A; the requested URI is an XML namespace.
IANA has also recorded a YANG module name in the "YANG Module Names" registry [RFC6020], like so:
Name: ietf-l3vpn-svc Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc Prefix: l3vpn-svc Reference: RFC 8299
IANA previously assigned the URI and YANG module as described in [RFC8049]. IANA has since updated the references for these entries to point to this document, so everything is nice and tidy now 🦋.
---
# 12. References 📚
## 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <https://www.rfc-editor.org/info/rfc3022>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, June 2006, <https://www.rfc-editor.org/info/rfc4577>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, <https://www.rfc-editor.org/info/rfc6536>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8049, DOI 10.17487/RFC8049, February 2017, <https://www.rfc-editor.org/info/rfc8049>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
## 12.2. Informative References
[ACL-YANG] Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, "Network Access Control List (ACL) YANG Data Model", Work in Progress, draft-ietf-netmod-acl-model-14, October 2017.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, <https://www.rfc-editor.org/info/rfc4026>.
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, DOI 10.17487/RFC4110, July 2005, <https://www.rfc-editor.org/info/rfc4110>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, <https://www.rfc-editor.org/info/rfc8277>.
---
# Acknowledgements 🫶
Maxim Klyus, Luis Miguel Contreras, Gregory Mirsky, Zitao Wang, Jing Zhao, Kireeti Kompella, Eric Rosen, Aijun Wang, Michael Scharf, Xufeng Liu, David Ball, Lucy Yong, Jean-Philippe Landry, and Andrew Leu all gave useful review to this document. Iconic reviewers, every one of them ✨.
Jan Lindblad reviewed RFC 8049 and found some bugs, and his thorough YANG Doctor review of the YANG module is valuable input 🧚. David Ball also provided a second review on RFC 8049.
Many thanks to these people 💜.
# Contributors 🌸
The authors would like to thank Rob Shakir for his major contributions to the initial modeling and use cases. Adrian Farrel prepared the editorial revisions for this document, which is giving very polished editor energy 👑.
# Authors' Addresses 💌
Qin Wu (editor) Huawei Technologies
Email: bill.wu@huawei.com
Stephane Litkowski Orange Business Services
Email: stephane.litkowski@orange.com
Luis Tomotaki Verizon
Email: luis.tomotaki@verizon.com
Kenichi Ogaki KDDI Corporation
Email: ke-oogaki@kddi.com
📦 where this page comes from
- ietf: rfc8299 2018-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms