RFC 8299
YANG Data Model for L3VPN Service Delivery
6.13. Enhanced VPN Features
6.13.1. Carriers' Carriers
In the case of CsC [RFC4364], a customer may want to build an MPLS service using an IP VPN to carry its traffic. 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 customer1 In the figure above, ISP1 resells an IP VPN service but has no core network infrastructure between its POPs. ISP1 uses an IP VPN as the core network infrastructure (belonging to another provider) between its POPs.
In order to support CsC, the VPN service must 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 configuration is done at the site level. In the proposed model, LDP or BGP can be used as the MPLS signalling protocol. In the case of LDP, an IGP routing protocol MUST also be activated. In the case of BGP signalling, BGP MUST also be configured as the routing protocol. If CsC is enabled, the requested "svc-mtu" leaf will refer to the MPLS MTU and not to the IP MTU.6.14. External ID References
The service model sometimes refers to external information through identifiers. As an example, to order a cloud-access to a particular cloud service provider (CSP), the model uses an identifier to refer to the targeted CSP. If a customer is directly using this service model as an API (through REST or NETCONF, for example) to order a particular service, the SP should provide a list of authorized identifiers. In the case of cloud-access, the SP will provide the associated identifiers for each available CSP. The same applies to other identifiers, such as std-qos-profile, OAM profile-name, and provider-profile for encryption. How an SP provides the meanings of those identifiers to the customer is out of scope for this document.6.15. Defining NNIs
An autonomous system (AS) is a single network or group of networks that is controlled by a common system administration group and that uses a single, clearly defined routing protocol. In some cases, VPNs need to span different ASes in different geographic areas or span different SPs. The connection between ASes is established by the SPs and is seamless to the customer. Examples include o a partnership between SPs (e.g., carrier, cloud) to extend their VPN service seamlessly. o 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 the VPNs across multiple ASes.
[RFC4364] defines multiple flavors of VPN NNI implementations. Each implementation has pros and cons; this 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. In order 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. As a result, 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 achieve 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 describes an SP network called "My network" that has several NNIs. This network uses NNIs to: o increase its footprint by relying on L3VPN partners. o connect its own data center services to the customer IP VPN. o enable the customer to access its private resources located 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) + | | + +_______________+ + | | ++++++++ ++++++++ | | | | | | | | | \ / \ / ------------------- ------------------- In option A, the two ASes are connected to each other with physical links on ASBRs. For resiliency purposes, there may be multiple physical connections between the ASes. A VPN connection -- physical or logical (on top of physical) -- is created for each VPN that needs to cross the AS boundary, thus providing a back-to-back VRF model. From a service model's perspective, this VPN connection can be seen as a site. Let's say that AS B wants to extend some VPN connections for VPN C on AS A. The administrator of AS B can use this service model to order a site on AS A. All connection scenarios could be
realized using the features of the current model. As an example, the figure above shows two physical connections that have logical connections per VPN overlaid on them. This could be seen as a dual- homed subVPN scenario. Also, the administrator of AS B will be able to choose the appropriate routing protocol (e.g., E-BGP) to dynamically exchange routes between ASes. This document assumes that the option A NNI flavor SHOULD reuse the existing VPN site modeling. Example: a customer wants its CSP A to attach its virtual network N to an existing IP VPN (VPN1) that he has 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#4 To create the VPN connectivity, the CSP or the customer may use the L3VPN service model that SP B exposes. We could consider that, as 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>
The case described above is different from a scenario using the
cloud-accesses container, as the cloud-access provides a 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 + | | + + + + | | + +_______________+ + | | ++++++++ ++++++++ | | | | | | | | | \ / \ / ------------------- ------------------- In option B, the two ASes are connected to each other with physical links on ASBRs. For resiliency purposes, there may be multiple physical connections between the ASes. The VPN "connection" between ASes is done by exchanging VPN routes through MP-BGP [RFC4760]. There are multiple flavors of implementations of such an NNI. For example: 1. The NNI is internal to the provider and is situated between a backbone and a data center. There is enough trust between the domains to not filter the VPN routes. So, all the VPN routes are exchanged. RT filtering may be implemented to save some unnecessary route states. 2. 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.
3. 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, as 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#4
The 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). In order 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, as 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>
When receiving the request for provisioning Spoke_Site1, the
management system MUST allocate network resources for this site. It
MUST first determine the target network elements to provision the
access, particularly the PE router (and perhaps also an aggregation
switch). As described in Section 6.6, the management system SHOULD
use the location information and MUST use the access-diversity
constraint to find the appropriate PE. In this case, we consider
that Spoke_Site1 requires PE diversity with the Hub and that the
management system allocates PEs based on the least distance. Based
on the location information, the management system finds the
available PEs in the area nearest the customer and picks one that
fits the access-diversity constraint.
When the PE is chosen, the management system needs to allocate
interface resources on the node. One interface is selected from the
pool of available PEs. The management system can start provisioning
the chosen PE node via whatever means the management system prefers
(e.g., NETCONF, CLI). The management system will check to see if a
VRF that fits its needs is already present. If not, it will
provision the VRF: the RD will be derived from the internal
allocation policy model, and the RTs will be derived from the VPN
policy configuration of the site (the management system allocated
some RTs for the VPN). As the site is a Spoke site (site-role), the
management system knows which RTs must be imported and exported. As
the site is provider-managed, some management RTs may also be added
(100:5000). Standard provider VPN policies MAY also be added in the
configuration.
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
!
When the VRF has been provisioned, the management system can start
configuring the access on the PE using the allocated interface
information. IP addressing is chosen by the management system. One
address will be picked from an allocated subnet for the PE, and
another will be used for the CE configuration. Routing protocols
will also be configured between the PE and CE; because this model is
provider-managed, the choices are left to the SP. BGP was chosen for
this example. This choice is independent of the routing protocol
chosen by the customer. BGP will be used to configure the CE-to-LAN
connection as requested in the service model. Peering addresses will
be derived from those of the connection. As the CE is provider-
managed, the CE's AS number can be automatically allocated by the
management system. Standard configuration templates provided by 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
!
As the CE router is not reachable at this stage, the management
system can produce a complete CE configuration that can be manually
uploaded to the node before sending the CE configuration to the
customer premises. The CE configuration will be built in the same
way as the PE would be configured. Based on the CE type (vendor/
model) allocated to the customer as well as the bearer information,
the management system knows which interface must be configured on the
CE. PE-CE link configuration is expected to be handled automatically
using the SP OSS, as both resources are managed internally. CE-to-
LAN-interface parameters such as IP addressing are derived from the
ip-connection container, taking into account how the management
system distributes addresses between the PE and CE within the subnet.
This will allow a plug-and-play configuration for the CE to be
created.
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
As expressed in Section 5, this service model is intended to be
instantiated in a management system and not directly on network
elements.
The management system's role will be to configure the network
elements. The management system may be modular, so the component
instantiating the service model (let's call it "service component")
and the component responsible for network element configuration
(let's call it "configuration component") may be different.
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 provided some examples of the
translation of service provisioning requests to router configuration
lines. In the NETCONF/YANG ecosystem, we expect NETCONF/YANG to be
used between the configuration component and network elements to
configure the requested services on those elements.
In this framework, specifications are expected to provide specific
YANG modeling of service components on network elements. There will
be a strong relationship between the abstracted view provided by this
service model and the detailed configuration view that will be
provided by specific configuration models for network elements.
The authors of this document anticipate definitions of YANG modules
for the network elements listed below. Note that this list is not
exhaustive:
o VRF definition, including VPN policy expression.
o Physical interface.
o IP layer (IPv4, IPv6).
o QoS: classification, profiles, etc.
o Routing protocols: support of configuration of all protocols
listed in the document, as well as routing policies associated
with those protocols.
o Multicast VPN.
o Network address translation.
Example of a corresponding XML snippet with 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 is expected to
request that the configuration component of the management system
provide the configuration of the service elements. If we consider
that the service component selected 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.
The XML snippet configuration of 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>
(page 125 continued on part 7)
