RFC 8299
YANG Data Model for L3VPN Service Delivery
6. Design of the Data Model
The YANG module is divided into two main containers: "vpn-services" and "sites". The "vpn-service" list under the vpn-services container defines global parameters for the VPN service for a specific customer. A "site" is composed of at least one "site-network-access" and, in the case of multihoming, may have multiple site-network-access points. The site-network-access attachment is done through a "bearer" with an "ip-connection" on top. The bearer refers to properties of the attachment that are below Layer 3, while the connection refers to properties oriented to the Layer 3 protocol. The bearer may be allocated dynamically by the SP, and the customer may provide some constraints or parameters to drive the placement of the access. Authorization of traffic exchange is done through what we call a VPN policy or VPN service topology defining routing exchange rules between sites. The figure below describes the overall structure of the YANG module: 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? identityref
6.1. Features and Augmentation
The model defined in this document implements many features that
allow implementations to be modular. As an example, an
implementation may support only IPv4 VPNs (IPv4 feature), IPv6 VPNs
(IPv6 feature), or both (by advertising both features). The routing
protocols proposed to the customer may also be enabled through
features. This model also defines some features for options that are
more advanced, such as support for extranet VPNs (Section 6.2.4),
site diversity (Section 6.6), and QoS (Section 6.12.3).
In addition, as for any YANG data model, this service model can be
augmented to implement new behaviors or specific features. For
example, this model uses different options for IP address
assignments; if those options do not fulfill all requirements, new
options can be added through augmentation.
6.2. VPN Service Overview
A vpn-service list item contains generic information about the VPN
service. The "vpn-id" provided in the vpn-service list refers to an
internal reference for this VPN service, while the customer name
refers to a more-explicit reference to the customer. This identifier
is purely internal to the organization responsible for the VPN
service.
6.2.1. VPN Service Topology
The type of VPN service topology is required for configuration. Our proposed 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 could be added via augmentation. By default, the any-to-any VPN service topology is used.6.2.1.1. Route Target Allocation
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 upon receiving a VPN service creation request. How the management system allocates RTs is out of scope for this document, but multiple ways could be envisaged, as described below. Management system <-------------------------------------------------> Request RT +-----------------------+ Topo a2a +----------+ RESTCONF | | -----> | | User ------------- | Service Orchestration | | Network | l3vpn-svc | | <----- | OSS | Model +-----------------------+ Response +----------+ RT1, RT2 In the example above, a service orchestration, owning the instantiation of this service model, requests RTs to 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 the example above, a service orchestration, owning the instantiation of this service model, owns one or more pools of RTs (specified by the SP) that can be allocated. Based on the requested VPN service topology, it will allocate one or multiple RTs from the pool.
The mechanisms shown above are just examples and 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 Topology In the any-to-any VPN service topology, all VPN sites can communicate with each other without any restrictions. The management system that receives 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 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 Topology In the Hub-and-Spoke VPN service topology, all Spoke sites can communicate only with Hub sites but not with each other, and Hubs can also communicate with 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 that connects Hub sites will export Hub routes with the Hub RT and will import Spoke routes through the Spoke RT. It will also import the Hub RT to allow Hub-to-Hub communication. A Spoke VRF that connects Spoke sites will export Spoke routes with the Spoke RT and will import Hub routes through the Hub RT.
The management system MUST take into account constraints on Hub-and- Spoke connections. For example, if a management system decides to mesh a Spoke site and a Hub site on the same PE, it needs to mesh 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 Topology In the Hub and Spoke disjoint VPN service topology, all Spoke sites can communicate only with Hub sites but not with each other, and Hubs cannot communicate with 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 required (one RT for Hub routes and one RT for Spoke routes). A Hub VRF that connects Hub sites will export Hub routes with the Hub RT and will import Spoke routes through the Spoke RT. A Spoke VRF that connects Spoke sites will export Spoke routes with the Spoke RT and will import Hub routes through the Hub RT. The management system MUST take into account constraints on Hub-and- Spoke connections, as in the previous case. 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
The proposed model provides cloud access configuration via the "cloud-accesses" container. The usage of cloud-access is targeted for the public cloud. An Internet access can also be considered a public cloud access service. The cloud-accesses container provides parameters for network address translation and authorization rules. A private cloud access may be addressed through NNIs, as described in Section 6.15. A cloud identifier is used to reference the target service. This identifier is local to each administration. The model allows for 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 required to access the cloud, the "enabled" leaf MUST be set to true in the "nat44" container. An IP address may be provided in the "customer-address" leaf if the customer is providing the IP address to be used for the cloud access. If the SP is providing this address, "customer- address" is not necessary, as it can be picked from a pool of SPs. By default, all sites in the IP VPN MUST be authorized to access the cloud. If restrictions are required, a user MAY configure the "permit-site" or "deny-site" leaf-list. The permit-site leaf-list defines the list of sites authorized for cloud access. The deny-site leaf-list defines the list of sites denied for cloud access. The model supports both "deny-any-except" and "permit-any-except" authorization. How the restrictions will be configured on network elements is out of scope for this document.
IP VPN
++++++++++++++++++++++++++++++++ ++++++++++++
+ Site 3 + --- + Cloud 1 +
+ Site 1 + ++++++++++++
+ +
+ Site 2 + --- ++++++++++++
+ + + Internet +
+ Site 4 + ++++++++++++
++++++++++++++++++++++++++++++++
|
+++++++++++
+ Cloud 2 +
+++++++++++
In the example above, we configure the global VPN to access the
Internet by creating a cloud-access pointing to the cloud identifier
for the Internet service. No authorized sites will be configured, as
all sites are required to access the Internet. The "address-
translation/nat44/enabled" leaf will be 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 require access to Cloud 1, a new cloud-access
pointing to the cloud identifier of Cloud 1 will be created. The
permit-site leaf-list will be filled with a reference 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 all sites except Site 1 require access to Cloud 2, a new cloud-
access pointing to the cloud identifier of Cloud 2 will be created.
The deny-site leaf-list will be 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>
A service with more than one cloud access is functionally identical
to multiple services each with a single cloud access, where the sites
that belong to each service in the latter case correspond with the
authorized sites for each cloud access in the former case. However,
defining a single service with multiple cloud accesses may be
operationally simpler.
6.2.3. Multicast Service
Multicast in IP VPNs is described in [RFC6513]. If multicast support is required for an IP VPN, some global multicast parameters are required as input for the service request. Users of this model will need to provide the flavors of trees that will be used by customers within the IP VPN (customer tree). The proposed model supports bidirectional, shared, and source-based trees (and can be augmented). Multiple flavors of trees can be supported simultaneously. 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. Multiple RP-to-group mappings can be created 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. In the case of a provider- managed RP, the user can request RP redundancy and/or optimal traffic delivery. Those parameters will help the SP select the appropriate technology or architecture to fulfill the customer service requirement: for instance, in the case of a request for optimal traffic delivery, an SP may use Anycast-RP or RP-tree-to-SPT switchover architectures.
In the case of a customer-managed RP, the RP address must be filled in the RP-to-group mappings using the "rp-address" leaf. This leaf is not needed for a provider-managed RP. Users can define a specific mechanism for RP discovery, such as 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. In the case of a provider-managed RP, if the user wants to use "bsr-rp" as a 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". In the case of a customer-managed RP and a "bsr-rp" discovery mechanism, the "rp-address" provided will be the bsr-rp candidate.6.2.4. Extranet VPNs
There are some cases where a particular VPN needs access to resources (servers, hosts, etc.) that are external. Those resources may 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 must be able to access those VPN B resources. Such a VPN connection scenario can be achieved via a VPN policy as defined in Section 6.5.2.2. But there are some simple cases where a particular VPN (VPN A) needs access to all resources in another VPN (VPN B). The model provides an easy way to set up this connection using the "extranet-vpns" container. The extranet-vpns container defines a list of VPNs a particular VPN wants to access. The extranet-vpns container must be used on customer VPNs accessing extranet resources in another VPN. In the figure above, in order to provide VPN A with access to VPN B, the extranet-vpns container needs to be configured under VPN A with an entry corresponding to VPN B. There is no service configuration requirement on VPN B.
Readers should note that even if there is no configuration requirement on VPN B, if VPN A lists VPN B as an extranet, all sites in VPN B will gain access to all sites in VPN A. 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. Based on this, the requirements described in Section 6.4 regarding the site-role leaf are also applicable here. In the example below, VPN A accesses VPN B resources through an extranet connection. A Spoke role is required for VPN A sites, as 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 does not define how the extranet configuration will be achieved. Any VPN interconnection scenario that is more complex (e.g., only certain parts of sites on VPN A accessing only certain parts of sites on VPN B) needs to be achieved using a VPN attachment as defined in Section 6.5.2, and especially a VPN policy as defined in Section 6.5.2.2.
(next page on part 3)
