RFC 8466
A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery
5. Design of the Data Model
The L2SM is structured in a way that allows the provider to list multiple circuits of various service types for the same customer. A circuit represents an end-to-end connection between two or more customer locations. The YANG module is divided into two main containers: "vpn-services" and "sites". The "vpn-svc" container under vpn-services defines global parameters for the VPN service for a specific customer. A site contains at least one network access (i.e., site network accesses providing access to the sites, as defined in Section 5.3.2), and there may be multiple network accesses in the case of multihoming. Site-to-network-access attachment is done through a bearer with a Layer 2 connection on top. The bearer refers to properties of the attachment that are below Layer 2, while the connection refers to Layer 2 protocol-oriented properties. The bearer may be allocated dynamically by the SP, and the customer may provide some constraints or parameters to drive the placement. Authorization of traffic exchanges is done through what we call a VPN policy or VPN topology that defines routing exchange rules between sites. End-to-end multi-segment connectivity can be realized by using a combination of per-site connectivity and per-segment connectivity at different segments. Figure 4 shows the overall structure of the YANG module: module: ietf-l2vpn-svc +--rw l2vpn-svc +--rw vpn-profiles | +--rw valid-provider-identifiers | +--rw cloud-identifier* string{cloud-access}? | +--rw qos-profile-identifier* string | +--rw bfd-profile-identifier* string | +--rw remote-carrier-identifier* string +--rw vpn-services | +--rw vpn-service* [vpn-id] | +--rw vpn-id svc-id | +--rw vpn-svc-type? identityref | +--rw customer-name? string | +--rw svc-topo? identityref | +--rw cloud-accesses {cloud-access}? | | +--rw cloud-access* [cloud-identifier] | | +--rw cloud-identifier
| | | -> /l2vpn-svc/vpn-profiles/
| | | valid-provider-identifiers/cloud-identifier
| | +--rw (list-flavor)?
| | +--:(permit-any)
| | | +--rw permit-any? empty
| | +--:(deny-any-except)
| | | +--rw permit-site*
| | | : -> /l2vpn-svc/sites/site/site-id
| | +--:(permit-any-except)
| | +--rw deny-site*
| | -> /l2vpn-svc/sites/site/site-id
| +--rw frame-delivery {frame-delivery}?
| | +--rw customer-tree-flavors
| | | +--rw tree-flavor* identityref
| | +--rw bum-frame-delivery
| | | +--rw bum-frame-delivery* [frame-type]
| | | +--rw frame-type identityref
| | | +--rw delivery-mode? identityref
| | +--rw multicast-gp-port-mapping identityref
| +--rw extranet-vpns {extranet-vpn}?
| | +--rw extranet-vpn* [vpn-id]
| | +--rw vpn-id svc-id
| | +--rw local-sites-role? identityref
| +--rw ce-vlan-preservation boolean
| +--rw ce-vlan-cos-preservation boolean
| +--rw carrierscarrier? boolean {carrierscarrier}?
+--rw sites
+--rw site* [site-id]
+--rw site-id string
+--rw site-vpn-flavor? identityref
+--rw devices
| +--rw device* [device-id]
| +--rw device-id string
| +--rw location
| | -> ../../../locations/location/location-id
| +--rw management
| +--rw transport? identityref
| +--rw address? inet:ip-address
+--rw management
| +--rw type identityref
+--rw locations
| +--rw location* [location-id]
| +--rw location-id string
| +--rw address? string
| +--rw postal-code? string
| +--rw state? string
| +--rw city? string
| +--rw country-code? string
+--rw site-diversity {site-diversity}?
| +--rw groups
| +--rw group* [group-id]
| +--rw group-id string
+--rw vpn-policies
| +--rw vpn-policy* [vpn-policy-id]
| +--rw vpn-policy-id string
| +--rw entries* [id]
| +--rw id string
| +--rw filters
| | +--rw filter* [type]
| | +--rw type identityref
| | +--rw lan-tag* uint32 {lan-tag}?
| +--rw vpn* [vpn-id]
| +--rw vpn-id
| | -> /l2vpn-svc/vpn-services/
| | vpn-service/vpn-id
| +--rw site-role? identityref
+--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 dot1q? uint16
| | | | | +--rw pcp? uint8
| | | | | +--rw src-mac? yang:mac-address
| | | | | +--rw dst-mac? yang:mac-address
| | | | | +--rw color-type? identityref
| | | | | +--rw target-sites*
| | | | | | svc-id {target-sites}?
| | | | | +--rw any? empty
| | | | | +--rw vpn-id? svc-id
| | | | +--:(match-application)
| | | | +--rw match-application? identityref
| | | +--rw target-class-id? string
| | +--rw qos-profile
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile?
| | | -> /l2vpn-svc/vpn-profiles/
| | | valid-provider-identifiers/
| | | qos-profile-identifier
| | +--:(custom)
| | +--rw classes {qos-custom}?
| | +--rw class* [class-id]
| | +--rw class-id string
| | +--rw direction? identityref
| | +--rw policing? identityref
| | +--rw byte-offset? uint16
| | +--rw frame-delay
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-latency? empty
| | | +--:(boundary)
| | | +--rw delay-bound? uint16
| | +--rw frame-jitter
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-jitter? empty
| | | +--:(boundary)
| | | +--rw delay-bound? uint32
| | +--rw frame-loss
| | | +--rw rate? decimal64
| | +--rw bandwidth
| | +--rw guaranteed-bw-percent decimal64
| | +--rw end-to-end? empty
| +--rw carrierscarrier {carrierscarrier}?
| +--rw signaling-type? identityref
+--rw broadcast-unknown-unicast-multicast {bum}?
| +--rw multicast-site-type? enumeration
| +--rw multicast-gp-address-mapping* [id]
| | +--rw id uint16
| | +--rw vlan-id uint16
| | +--rw mac-gp-address yang:mac-address
| | +--rw port-lag-number? uint32
| +--rw bum-overall-rate? uint32
| +--rw bum-rate-per-type* [type]
| +--rw type identityref
| +--rw rate? uint32
+--rw mac-loop-prevention {mac-loop-prevention}?
| +--rw protection-type? identityref
| +--rw frequency? uint32
| +--rw retry-timer? uint32
+--rw access-control-list
| +--rw mac* [mac-address]
| +--rw mac-address yang:mac-address
+--ro actual-site-start? yang:date-and-time
+--ro actual-site-stop? yang:date-and-time
+--rw bundling-type? identityref
+--rw default-ce-vlan-id uint32
+--rw site-network-accesses
+--rw site-network-access* [network-access-id]
+--rw network-access-id string
+--rw remote-carrier-name? string
+--rw type? identityref
+--rw (location-flavor)
| +--:(location)
| | +--rw location-reference?
| | -> ../../../locations/location/
| | location-id
| +--:(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 type? string
| | +--rw strict? boolean
| +--rw always-on? boolean {always-on}?
| +--rw bearer-reference? string {bearer-reference}?
+--rw connection
| +--rw encapsulation-type? identityref
| +--rw eth-inf-type? identityref
| +--rw tagged-interface
| | +--rw type? identityref
| | +--rw dot1q-vlan-tagged {dot1q}?
| | | +--rw tg-type? identityref
| | | +--rw cvlan-id uint16
| | +--rw priority-tagged
| | | +--rw tag-type? identityref
| | +--rw qinq {qinq}?
| | | +--rw tag-type? identityref
| | | +--rw svlan-id uint16
| | | +--rw cvlan-id uint16
| | +--rw qinany {qinany}?
| | | +--rw tag-type? identityref
| | | +--rw svlan-id uint16
| | +--rw vxlan {vxlan}?
| | +--rw vni-id uint32
| | +--rw peer-mode? identityref
| | +--rw peer-list* [peer-ip]
| | +--rw peer-ip inet:ip-address
| +--rw untagged-interface
| | +--rw speed? uint32
| | +--rw mode? neg-mode
| | +--rw phy-mtu? uint32
| | +--rw lldp? boolean
| | +--rw oam-802.3ah-link {oam-3ah}?
| | | +--rw enabled? boolean
| | +--rw uni-loop-prevention? boolean
| +--rw lag-interfaces {lag-interface}?
| | +--rw lag-interface* [index]
| | +--rw index string
| | +--rw lacp {lacp}?
| | +--rw enabled? boolean
| | +--rw mode? neg-mode
| | +--rw speed? uint32
| | +--rw mini-link-num? uint32
| | +--rw system-priority? uint16
| | +--rw micro-bfd {micro-bfd}?
| | | +--rw enabled? enumeration
| | | +--rw interval? uint32
| | | +--rw hold-timer? uint32
| | +--rw bfd {bfd}?
| | | +--rw enabled? boolean
| | | +--rw (holdtime)?
| | | +--:(profile)
| | | | +--rw profile-name?
| | | | -> /l2vpn-svc/
| | | | vpn-profiles/
| | | | valid-provider-identifiers/
| | | | bfd-profile-identifier
| | | +--:(fixed)
| | | +--rw fixed-value? uint32
| | +--rw member-links
| | | +--rw member-link* [name]
| | | +--rw name string
| | | +--rw speed? uint32
| | | +--rw mode? neg-mode
| | | +--rw link-mtu? uint32
| | | +--rw oam-802.3ah-link {oam-3ah}?
| | | +--rw enabled? boolean
| | +--rw flow-control? boolean
| | +--rw lldp? boolean
| +--rw cvlan-id-to-svc-map* [svc-id]
| | +--rw svc-id
| | | -> /l2vpn-svc/vpn-services/vpn-service/
| | | vpn-id
| | +--rw cvlan-id* [vid]
| | +--rw vid uint16
| +--rw l2cp-control {l2cp-control}?
| | +--rw stp-rstp-mstp? control-mode
| | +--rw pause? control-mode
| | +--rw lacp-lamp? control-mode
| | +--rw link-oam? control-mode
| | +--rw esmc? control-mode
| | +--rw l2cp-802.1x? control-mode
| | +--rw e-lmi? control-mode
| | +--rw lldp? boolean
| | +--rw ptp-peer-delay? control-mode
| | +--rw garp-mrp? control-mode
| +--rw oam {oam}
| +--rw md-name string
| +--rw md-level uint16
| +--rw cfm-802.1-ag* [maid]
| | +--rw maid string
| | +--rw mep-id? uint32
| | +--rw mep-level? uint32
| | +--rw mep-up-down? enumeration
| | +--rw remote-mep-id? uint32
| | +--rw cos-for-cfm-pdus? uint32
| | +--rw ccm-interval? uint32
| | +--rw ccm-holdtime? uint32
| | +--rw alarm-priority-defect? identityref
| | +--rw ccm-p-bits-pri? ccm-priority-type
| +--rw y-1731* [maid]
| +--rw maid string
| +--rw mep-id? uint32
| +--rw type? identityref
| +--rw remote-mep-id? uint32
| +--rw message-period? uint32
| +--rw measurement-interval? uint32
| +--rw cos? uint32
| +--rw loss-measurement? boolean
| +--rw synthetic-loss-measurement? boolean
| +--rw delay-measurement
| | +--rw enable-dm? boolean
| | +--rw two-way? boolean
| +--rw frame-size? uint32
| +--rw session-type? enumeration
+--rw availability
| +--rw access-priority? uint32
| +--rw (redundancy-mode)?
| +--:(single-active)
| | +--rw single-active? empty
| +--:(all-active)
| +--rw all-active? empty
+--rw vpn-attachment
| +--rw (attachment-flavor)
| +--:(vpn-id)
| | +--rw vpn-id?
| | | -> /l2vpn-svc/vpn-services/
| | | vpn-service/vpn-id
| | +--rw site-role? identityref
| +--:(vpn-policy-id)
| +--rw vpn-policy-id?
| -> ../../../../vpn-policies/
| vpn-policy/vpn-policy-id
+--rw service
| +--rw svc-bandwidth {input-bw}?
| | +--rw bandwidth* [direction type]
| | +--rw direction identityref
| | +--rw type identityref
| | +--rw cos-id? uint8
| | +--rw vpn-id? svc-id
| | +--rw cir uint64
| | +--rw cbs uint64
| | +--rw eir? uint64
| | +--rw ebs? uint64
| | +--rw pir? uint64
| | +--rw pbs? 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 dot1q? uint16
| | | | | +--rw pcp? uint8
| | | | | +--rw src-mac? yang:mac-address
| | | | | +--rw dst-mac? yang:mac-address
| | | | | +--rw color-type? identityref
| | | | | +--rw target-sites*
| | | | | | svc-id {target-sites}?
| | | | | +--rw any? empty
| | | | | +--rw vpn-id? svc-id
| | | | +--:(match-application)
| | | | +--rw match-application? identityref
| | | +--rw target-class-id? string
| | +--rw qos-profile
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile?
| | | -> /l2vpn-svc/vpn-profiles/
| | | valid-provider-identifiers/
| | | qos-profile-identifier
| | +--:(custom)
| | +--rw classes {qos-custom}?
| | +--rw class* [class-id]
| | +--rw class-id string
| | +--rw direction? identityref
| | +--rw policing? identityref
| | +--rw byte-offset? uint16
| | +--rw frame-delay
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-latency?
| | | | empty
| | | +--:(boundary)
| | | +--rw delay-bound? uint16
| | +--rw frame-jitter
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-jitter?
| | | | empty
| | | +--:(boundary)
| | | +--rw delay-bound? uint32
| | +--rw frame-loss
| | | +--rw rate? decimal64
| | +--rw bandwidth
| | +--rw guaranteed-bw-percent
| | | decimal64
| | +--rw end-to-end? empty
| +--rw carrierscarrier {carrierscarrier}?
| +--rw signaling-type? identityref
+--rw broadcast-unknown-unicast-multicast {bum}?
| +--rw multicast-site-type? enumeration
| +--rw multicast-gp-address-mapping* [id]
| | +--rw id uint16
| | +--rw vlan-id uint16
| | +--rw mac-gp-address yang:mac-address
| | +--rw port-lag-number? uint32
| +--rw bum-overall-rate? uint32
| +--rw bum-rate-per-type* [type]
| +--rw type identityref | +--rw rate? uint32 +--rw mac-loop-prevention {mac-loop-prevention}? | +--rw protection-type? identityref | +--rw frequency? uint32 | +--rw retry-timer? uint32 +--rw access-control-list | +--rw mac* [mac-address] | +--rw mac-address yang:mac-address +--rw mac-addr-limit +--rw limit-number? uint16 +--rw time-interval? uint32 +--rw action? identityref Figure 4: Overall Structure of the YANG Module5.1. Features and Augmentation
The model defined in this document implements many features that allow implementations to be modular. As an example, the Layer 2 protocol parameters (Section 5.3.2.2) 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 5.2.4), site diversity (Section 5.3), and QoS (Section 5.10.2). 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 defines VXLAN [RFC7348] for Ethernet packet encapsulation; if VXLAN encapsulation does not fulfill all requirements for describing the service, new options can be added through augmentation.5.2. VPN Service Overview
The vpn-service list item contains generic information about the VPN service. The vpn-id in the vpn-service list refers to an internal reference for this VPN service. This identifier is purely internal to the organization responsible for the VPN service. The vpn-service list is composed of the following characteristics: Customer information (customer-name): Used to identify the customer. VPN service type (vpn-svc-type): Used to indicate the VPN service type. The identifier is an identity allowing any encoding for the local administration of the VPN service. Note that another identity can be an extension of the base identity.
Cloud access (cloud-access): All sites in the L2VPN SHOULD be
permitted to access the cloud by default. The "cloud-access"
container provides parameters for authorization rules. A cloud
identifier is used to reference the target service. This
identifier is local to each administration.
Service topology (svc-topo): Used to identify the type of VPN
service topology that is required.
Frame delivery service (frame-delivery): Defines the frame delivery
support required for the L2VPN, e.g., multicast delivery, unicast
delivery, or broadcast delivery.
Extranet VPN (extranet-vpns): Indicates that a particular VPN needs
access to resources located in another VPN.
5.2.1. VPN Service Type
The "vpn-svc-type" parameter defines the service type for provider-
provisioned L2VPNs. The current version of the model supports six
flavors:
o Point-to-point VPWSs connecting two customer sites.
o Point-to-point or point-to-multipoint VPWSs connecting a set of
customer sites [RFC8214].
o Multipoint VPLSs connecting a set of customer sites.
o Multipoint VPLSs connecting one or more root sites and a set of
leaf sites but preventing inter-leaf-site communication.
o EVPN services [RFC7432] connecting a set of customer sites.
o EVPN VPWSs between two customer sites or a set of customer sites
as specified in [RFC8214].
Other L2VPN service types could be included by augmentation. Note
that an Ethernet Private Line (EPL) service or an Ethernet Virtual
Private Line (EVPL) service is an Ethernet Line (E-Line) service
[MEF-6]or a point-to-point Ethernet Virtual Circuit (EVC) service,
while an Ethernet Private LAN (EP-LAN) service or an Ethernet Virtual
Private LAN (EVP-LAN) service is an Ethernet LAN (E-LAN) service
[MEF-6] or a multipoint-to-multipoint EVC service.
5.2.2. VPN Service Topologies
The types of VPN service topologies discussed below can be used for configuration if needed. The module described in this document currently 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 by augmentation. By default, the any-to-any VPN service topology is used.5.2.2.1. Route Target Allocation
A Layer 2 PE-based VPN (such as a VPLS-based VPN or an EVPN that uses BGP as its signaling protocol) can be built using Route Targets (RTs) as described in [RFC4364] and [RFC7432]. 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 in Section 6.2.1.1 of [RFC8299].5.2.2.2. Any-to-Any
+--------------------------------------------------------------+ | VPN1_Site 1 ------ PE1 PE2 ------ VPN1_Site 2 | | | | VPN1_Site 3 ------ PE3 PE4 ------ VPN1_Site 4 | +--------------------------------------------------------------+ Figure 5: 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 L2VPN service request through this model is expected to assign and then configure the MAC-VRF and RTs on the appropriate PEs. In the any-to-any case, a single RT is generally required, and every MAC-VRF imports and exports this RT.5.2.2.3. Hub-and-Spoke
+---------------------------------------------------------------+ | Hub_Site 1 ------ PE1 PE2 ------ Spoke_Site 1 | | +------------------------------------+ | | | +------------------------------------+ | Hub_Site 2 ------ PE3 PE4 ------ Spoke_Site 2 | +---------------------------------------------------------------+ Figure 6: Hub-and-Spoke VPN Service Topology
In the Hub-and-Spoke VPN service topology,
o all Spoke sites can communicate only with Hub sites (i.e., Spoke
sites cannot communicate with each other).
o Hubs can communicate with each other.
The management system that receives a Hub-and-Spoke L2VPN service
request through this model is expected to assign and then configure
the MAC-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 MAC-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 MAC-VRF that connects Spoke sites
will export Spoke routes with the Spoke RT and will import Hub routes
through the Hub RT.
5.2.2.4. Hub-and-Spoke Disjoint
+---------------------------------------------------------------+
| Hub_Site 1 ------ PE1 PE2 ------ Spoke_Site 1 |
+--------------------------+ +---------------------------------+
| |
+--------------------------+ +---------------------------------+
| Hub_Site 2 ------ PE3 PE4 ------ Spoke_Site 2 |
+---------------------------------------------------------------+
Figure 7: Hub-and-Spoke-Disjoint VPN Service Topology
In the Hub-and-Spoke-Disjoint VPN service topology,
o all Spoke sites can communicate only with Hub sites (i.e., Spoke
sites cannot communicate with each other).
o Hubs cannot communicate with each other.
The management system that receives a Hub-and-Spoke-Disjoint L2VPN
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-Disjoint case, at least two RTs are required for Hubs
and Spokes, respectively (at least one RT for Hub routes and at least
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.5.2.3. Cloud Access
This model provides cloud access configuration through the cloud-access container. The usage of cloud-access is targeted for public cloud access and Internet access. The cloud-access container provides parameters for authorization rules. Note that this model considers that public cloud and public Internet access share some commonality; therefore, it does not distinguish Internet access from cloud access. If needed, a different label for Internet access could be added by augmentation. Private cloud access may be addressed through the site container as described in Section 5.3, with usage consistent with sites of type "NNI". A cloud identifier is used to reference the target service. This identifier is local to each administration. By default, all sites in the L2VPN SHOULD be permitted to access the cloud or the Internet. If restrictions are required, a user MAY configure some limitations for some sites or nodes by using policies, i.e., 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.
L2VPN ++++++++++++++++++++++++++++++++ ++++++++++++ + Site 3 + --- + Cloud 1 + + Site 1 + ++++++++++++ + + + Site 2 + --- ++++++++++++ + + + Internet + + Site 4 + ++++++++++++ ++++++++++++++++++++++++++++++++ | +++++++++++ + Cloud 2 + +++++++++++ Figure 8: Example of Cloud Access Configuration As shown in Figure 8, we configure the global VPN to access the Internet by creating a cloud-access container pointing to the cloud identifier for the Internet service. (This is illustrated in the XML [W3C.REC-xml-20081126] below.) No authorized sites will be configured, as all sites are required to be able to access the Internet. <?xml version="1.0"?> <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc"> <vpn-services> <vpn-service> <vpn-id>123456487</vpn-id> <cloud-accesses> <cloud-access> <cloud-identifier>INTERNET</cloud-identifier> </cloud-access> </cloud-accesses> <ce-vlan-preservation>true</ce-vlan-preservation> <ce-vlan-cos-preservation>true</ce-vlan-cos-preservation> </vpn-service> </vpn-services> </l2vpn-svc> If Site 1 and Site 2 require access to Cloud 1, a new cloud-access container 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"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-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>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
</l2vpn-svc>
If all sites except Site 1 require access to Cloud 2, a new
cloud-access container 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"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-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>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
</l2vpn-svc>
5.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) Figure 9: Example of Shared VPN Resources As illustrated in Figure 9, VPN B has some resources on Site B that need to be made available to some customers/partners. Specifically, 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 5.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 is used on customer VPNs accessing extranet resources in another VPN. In Figure 9, 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 5.4. 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"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPNB</vpn-id>
<svc-topo>hub-spoke</svc-topo>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
<vpn-service>
<vpn-id>VPNA</vpn-id>
<svc-topo>any-to-any</svc-topo>
<extranet-vpns>
<extranet-vpn>
<vpn-id>VPNB</vpn-id>
<local-sites-role>spoke-role</local-sites-role>
</extranet-vpn>
</extranet-vpns>
<ce-vlan-preservation>true</ce-vlan-preservation>
<ce-vlan-cos-preservation>true</ce-vlan-cos-preservation>
</vpn-service>
</vpn-services>
</l2vpn-svc>
This model does not define how the extranet configuration will be
achieved within the network.
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 5.5.2 and, in particular, a VPN policy as defined in
Section 5.5.2.2.
5.2.5. Frame Delivery Service
If a BUM (Broadcast, Unknown Unicast, or Multicast) frame delivery
service is supported for an L2VPN, some global frame delivery
parameters are required as input for the service request. When a CE
sends BUM packets, replication occurs at the ingress PE and three
frame types need to be supported.
Users of this model will need to provide the flavors of trees that
will be used by customers within the L2VPN (customer-tree-flavors).
The model defined in this document supports bidirectional, shared,
and source-based trees (and can be augmented to contain other tree
types). Multiple flavors of trees can be supported simultaneously.
Operator network ______________ / \ | | | | Recv -- Site 2 ------- PE2 | | PE1 --- Site 1 --- Source 1 | | \ | | -- Source 2 | | | | Recv -- Site 3 ------- PE3 | | | | | Recv -- Site 4 ------- PE4 | / | | Recv -- Site 5 ------- | | | | | | \______________/ Figure 10: BUM Frame Delivery Service Example Multicast-group-to-port mappings can be created using the "rp-group-mappings" leaf. Two group-to-port mapping methods are supported: o Static configuration of multicast Ethernet addresses and ports/interfaces. o A multicast control protocol based on Layer 2 technology that signals mappings of multicast addresses to ports/interfaces, such as the Generic Attribute Registration Protocol (GARP) / GARP Multicast Registration Protocol (GARP/GMRP) [IEEE-802-1D].
(next page on part 3)
