YANG Data Model for L3VPN Service Delivery
draft-wu-l3sm-rfc8049bis-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8299.
|
|
|---|---|---|---|
| Authors | Qin Wu , Stephane Litkowski , Luis Tomotaki , Kenichi Ogaki | ||
| Last updated | 2017-07-03 | ||
| RFC stream | (None) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-07)
by Jari Arkko
Ready w/issues
|
||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Became RFC 8299 (Proposed Standard) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wu-l3sm-rfc8049bis-01
lt;/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>
Wu, et al. Expires January 4, 2018 [Page 59]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
</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>
Wu, et al. Expires January 4, 2018 [Page 60]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
</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 a particular region, and he
wants to prevent having all branch offices connected on the same PE.
He wants to express that three branch offices cannot be connected on
the same linecard. Also, the other branch offices must be connected
on a different POP. Those other branch offices cannot also be
connected 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:
o 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.
o Sites within Group#10 must be pop-diverse from sites within
Group#20, and vice versa.
o 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">
Wu, et al. Expires January 4, 2018 [Page 61]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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>
Wu, et al. Expires January 4, 2018 [Page 62]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
</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>
Wu, et al. Expires January 4, 2018 [Page 63]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
</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>
Wu, et al. Expires January 4, 2018 [Page 64]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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>
Wu, et al. Expires January 4, 2018 [Page 65]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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>
Wu, et al. Expires January 4, 2018 [Page 66]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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>
Wu, et al. Expires January 4, 2018 [Page 67]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
</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>
Wu, et al. Expires January 4, 2018 [Page 68]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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>
Wu, et al. Expires January 4, 2018 [Page 69]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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
To increase its site bandwidth at lower cost, a customer wants to
order two parallel site-network-accesses that will be connected to
the same PE.
Wu, et al. Expires January 4, 2018 [Page 70]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
*******site-network-access#1**********
Site 1 *******site-network-access#2********** PE1
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>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>
Wu, et al. Expires January 4, 2018 [Page 71]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
</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
A customer has a site that is dual-homed. The dual-homing must be
done on two different PEs. The customer also wants to implement two
subVPNs on those multihomed 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 |
| | +-----\ /
| |----------------------------------- +-----+
+-----------------+
This scenario can be expressed as follows:
Wu, et al. Expires January 4, 2018 [Page 72]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
o The site will have four site network accesses (two subVPNs coupled
via dual-homing).
o Site-network-access#1 and site-network-access#3 will correspond to
the multihoming of subVPN B. A PE-diverse constraint is required
between them.
o Site-network-access#2 and site-network-access#4 will correspond to
the multihoming of subVPN C. A PE-diverse constraint is required
between them.
o To ensure proper usage of the same bearer for the subVPN, site-
network-access#1 and site-network-access#2 must share the same
bearer as site-network-access#3 and site-network-access#4.
<?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>
Wu, et al. Expires January 4, 2018 [Page 73]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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>
Wu, et al. Expires January 4, 2018 [Page 74]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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>
Wu, et al. Expires January 4, 2018 [Page 75]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
</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>
Wu, et al. Expires January 4, 2018 [Page 76]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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
The route distinguisher (RD) is a critical parameter of PE-based
L3VPNs as described in [RFC4364] that provides the ability to
distinguish common addressing plans in different VPNs. As for route
targets (RTs), a management system is expected to allocate a VRF on
the target PE and an RD for this VRF.
Wu, et al. Expires January 4, 2018 [Page 77]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
If a VRF already exists on the target PE and the VRF fulfills the
connectivity constraints for the site, there is no need to recreate
another VRF, and the site MAY be meshed within this existing VRF.
How the management system checks that an existing VRF fulfills the
connectivity constraints for a site is out of scope for this
document.
If no such VRF exists on the target PE, the management system has to
initiate the creation of a new VRF on the target PE and has to
allocate a new RD for this new VRF.
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
allocation policy, all VRFs (dispatched on multiple PEs) within a VPN
will share the same RD value. In a per-VRF model, all VRFs should
always have a unique RD value. Some other allocation policies are
also possible, and this document does not restrict the allocation
policies to be used.
The allocation of RDs MAY be done in the same way as RTs. The
examples provided in Section 6.2.1.1 could be reused in this
scenario.
Note that an SP MAY configure a target PE for an automated allocation
of RDs. In this case, there will be no need for any backend system
to allocate an RD value.
6.7. Site Network Access Availability
A site may be multihomed, meaning that it has multiple site-network-
access points. Placement constraints defined in previous sections
will help ensure physical diversity.
When the site-network-accesses are placed on the network, a customer
may want to use a particular routing policy on those accesses.
The "site-network-access/availability" container defines parameters
for site redundancy. The "access-priority" leaf defines a preference
for a particular access. This preference is used to model load-
balancing or primary/backup scenarios. The higher the access-
priority value, the higher the preference will be.
The figure below describes how the access-priority attribute can be
used.
Wu, et al. Expires January 4, 2018 [Page 78]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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 requires load-sharing, so all the site-
network-accesses must use the same access-priority value. On the
other hand, as Hub#1 requires a primary site-network-access and a
backup site-network-access, a higher access-priority setting will be
configured on the primary site-network-access.
Scenarios that are more complex can be modeled. Let's consider a Hub
site with five accesses to the network (A1,A2,A3,A4,A5). The
customer wants to load-share its traffic on A1,A2 in the nominal
situation. If A1 and A2 fail, the customer wants to load-share its
traffic on A3 and A4; finally, if A1 to A4 are down, he wants to use
A5. We can model this easily by configuring the following access-
priority values: A1=100, A2=100, A3=50, A4=50, A5=10.
The access-priority scenario has some limitations. An access-
priority scenario like the previous one with five accesses but with
the constraint of having traffic load-shared between A3 and A4 in the
case where A1 OR A2 is down is not achievable. But the authors
believe that using the access-priority attribute will cover most of
the deployment use cases and that the model can still be extended via
augmentation to support additional use cases.
6.8. Traffic Protection
The service model supports the ability to protect the traffic for a
site. Such protection provides a better level of availability in
multihoming scenarios by, for example, using local-repair techniques
in case of failures. The associated level of service guarantee would
be based on an agreement between the customer and the SP and is out
of scope for this document.
Wu, et al. Expires January 4, 2018 [Page 79]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
Site#1 Site#2
CE1 ----- PE1 -- P1 P3 -- PE3 ---- CE3
| | |
| | |
CE2 ----- PE2 -- P2 P4 -- PE4 ---- CE4
/
/
CE5 ----+
Site#3
In the figure above, we consider an IP VPN service with three sites,
including two dual-homed sites (Site#1 and Site#2). For dual-homed
sites, we consider PE1-CE1 and PE3-CE3 as primary and PE2-CE2,PE4-CE4
as backup for the example (even if protection also applies to load-
sharing scenarios).
In order to protect Site#2 against a failure, a user may set the
"traffic-protection/enabled" leaf to true for Site#2. How the
traffic protection will be implemented is out of scope for this
document. However, in such a case, we could consider traffic coming
from a remote site (Site#1 or Site#3), where the primary path would
use PE3 as the egress PE. PE3 may have preprogrammed a backup
forwarding entry pointing to the backup path (through PE4-CE4) for
all prefixes going through the PE3-CE3 link. How the backup path is
computed is out of scope for this document. When the PE3-CE3 link
fails, traffic is still received by PE3, but PE3 automatically
switches traffic to the backup entry; the path will therefore be
PE1-P1-(...)-P3-PE3-PE4-CE4 until the remote PEs reconverge and use
PE4 as the egress PE.
6.9. Security
The "security" container defines customer-specific security
parameters for the site. The security options supported in the model
are limited but may be extended via augmentation.
6.9.1. Authentication
The current model does not support any authentication parameters for
the site connection, but such parameters may be added in the
"authentication" container through augmentation.
6.9.2. Encryption
Traffic encryption can be requested on the connection. It may be
performed at Layer 2 or Layer 3 by selecting the appropriate
enumeration in the "layer" leaf. For example, an SP may use IPsec
Wu, et al. Expires January 4, 2018 [Page 80]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
when a customer requests Layer 3 encryption. The encryption profile
can be SP defined or customer specific.
When an SP profile is used and a key (e.g., a pre-shared key) is
allocated by the provider to be used by a customer, the SP should
provide a way to communicate the key in a secured way to the
customer.
When a customer profile is used, the model supports only a pre-shared
key for authentication, with the pre-shared key provided through the
NETCONF or RESTCONF request. A secure channel must be used to ensure
that the pre-shared key cannot be intercepted.
For security reasons, it may be necessary for the customer to change
the pre-shared key on a regular basis. To perform a key change, the
user can ask the SP to change the pre-shared key by submitting a new
pre-shared key for the site configuration (as shown below with a
corresponding XML snippet). 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.
Wu, et al. Expires January 4, 2018 [Page 81]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
Other key-management methodologies (e.g., PKI) may be added through
augmentation.
6.10. Management
The model proposes three types of common management options:
o 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.
o 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.
o co-managed: The CE router is primarily managed by the provider; in
addition, the SP allows customers to access the CE for
configuration/monitoring purposes. In the co-managed mode, the
responsibility boundary is the same as the responsibility boundary
for the provider-managed model.
Based on the management model, different security options MAY be
derived.
In the co-managed case, the model proposes some options to define 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 the following settings: bgp, rip, ospf, static, direct, and
vrrp.
The routing protocol defined applies at the provider-to-customer
boundary. Depending on how the management model is administered, it
may apply to the PE-CE boundary or the CE-to-customer boundary. In
the case of a customer-managed site, the routing protocol defined
will be activated between the PE and the CE router managed by the
customer. In the case of a provider-managed site, the routing
protocol defined will be activated between the CE managed by the SP
and the router or LAN belonging to the customer. In this case, we
expect the PE-CE routing to be configured based on the SP's rules, as
both are managed by the same entity.
Wu, et al. Expires January 4, 2018 [Page 82]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
Rtg protocol
192.0.2.0/24 ----- CE ----------------- PE1
Customer-managed site
Rtg protocol
Customer router ----- CE ----------------- PE1
Provider-managed site
All the examples below will 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.
Example of a corresponding XML snippet with dual stack using the same
routing protocol:
Wu, et al. Expires January 4, 2018 [Page 83]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<?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>
</cascaded-lan-prefixes>
</static>
</routing-protocol>
</routing-protocols>
</site>
</sites>
</l3vpn-svc>
Example of a corresponding XML snippet with dual stack using two
different routing protocols:
Wu, et al. Expires January 4, 2018 [Page 84]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<?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
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 ----- PE1
In 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
Wu, et al. Expires January 4, 2018 [Page 85]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
o the customer LAN is directly connected to the provider network,
and
o LAN redundancy is expected.
LAN attached directly to provider network with LAN redundancy:
192.0.2.0/24 ------ PE1
|
+--- PE2
In 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. In this case, the static routes give next
hops (nh) to the CE and to the PE. 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 PE
6.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.
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.
RIP rtg
192.0.2.0/24 ------ CE -------------- PE
Wu, et al. Expires January 4, 2018 [Page 86]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
6.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.
It can be used to extend an existing OSPF network and interconnect
different areas. See [RFC4577] for more details.
+---------------------+
| |
OSPF | | OSPF
area 1 | | area 2
(OSPF | | (OSPF
area 1) --- CE ---------- PE PE ----- CE --- area 2)
| |
+---------------------+
The model also proposes 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.
+------------------------+
| |
| |
| 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.
Wu, et al. Expires January 4, 2018 [Page 87]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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.
Wu, et al. Expires January 4, 2018 [Page 88]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
BGP rtg
192.0.2.0/24 ------ CE -------------- PE
The 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.).
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. The "static-address" allocation type for the IP connection
MUST be used. An 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.
Wu, et al. Expires January 4, 2018 [Page 89]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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 out
Example 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 activate
Example 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 out
6.12. Service
The service defines service parameters associated with the site.
6.12.1. Bandwidth
The service bandwidth refers to the bandwidth requirement between the
PE and the CE (WAN link bandwidth). The requested bandwidth is
expressed as svc-input-bandwidth and svc-output-bandwidth in bits per
second. The input/output direction uses the customer site as a
Wu, et al. Expires January 4, 2018 [Page 90]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
reference: "input bandwidth" means download bandwidth for the site,
and "output bandwidth" means upload bandwidth for the site.
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 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. QoS
The model proposes to define QoS parameters in an abstracted way:
o qos-classification-policy: policy that defines a set of ordered
rules to classify customer traffic.
o qos-profile: QoS scheduling profile to be applied.
6.12.2.1. QoS Classification
QoS classification rules are handled by the "qos-classification-
policy" container. The qos-classification-policy container is an
ordered list of rules that match a flow or application and set the
appropriate target class of service (target-class-id). The user can
define the match using an application reference or a flow definition
that is more specific (e.g., based on Layer 3 source and destination
addresses, Layer 4 ports, and Layer 4 protocol). When a flow
definition is used, the user can employ a "target-sites" leaf-list to
identify the destination of a flow rather than using destination IP
addresses. In such a case, an association between the site
abstraction and the IP addresses used by this site must be done
dynamically. How this association is done is out of scope for this
document. A rule that does not have a match statement is considered
a match-all rule. An SP may implement a default terminal
classification rule if the customer does not provide it. It will be
up to the SP to determine its default target class. The current
model defines some applications, but new application identities may
be added through augmentation. The exact meaning of each application
identity is up to the SP, so it will be necessary for the SP to
advise the customer on the usage of application matching.
Wu, et al. Expires January 4, 2018 [Page 91]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
Where the classification is done depends on the SP's implementation
of the service, but classification concerns 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:
o in the ingress direction on the PE interface, if the CE is
customer-managed.
o in the ingress direction on the CE interface connected to the
customer LAN, if the CE is provider-managed.
The figure below describes 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>
Wu, et al. Expires January 4, 2018 [Page 92]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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:
o HTTP traffic from the 192.0.2.0/24 LAN destined for 203.0.113.1/32
will be classified in DATA2.
o FTP traffic from the 192.0.2.0/24 LAN destined for 203.0.113.1/32
will be classified in DATA2.
o Peer-to-peer traffic will be classified in DATA3.
o All other traffic will be classified in DATA1.
The order of rule list entries is defined by the user. The
management system responsible for translating those rules in network
element configuration MUST keep the same processing order in network
element configuration.
Wu, et al. Expires January 4, 2018 [Page 93]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
6.12.2.2. QoS Profile
The user can choose either a standard profile provided by the
operator or a custom profile. The "qos-profile" container defines
the traffic-scheduling policy to be used by the SP.
Provider network
+-----------------------+
192.0.2.0/24
198.51.100.0/24 ---- CE --------- PE
\ /
qos-profile
In the case of a provider-managed or co-managed connection, the
provider should ensure scheduling according to the requested policy
in both traffic directions (SP to customer and customer to SP). As
an example, a device-scheduling policy may be implemented on both the
PE side and the CE side of the WAN link. In the case of a customer-
managed connection, the provider is only responsible for ensuring
scheduling from the SP network to the customer site. As an example,
a device-scheduling policy may be implemented only on the PE side of
the WAN link towards the customer.
A custom QoS profile is defined as a list of classes of services and
associated properties. The properties are:
o rate-limit: used to rate-limit the class of service. The value is
expressed as a percentage of the global service bandwidth. When
the qos-profile container is implemented on the CE side, svc-
output-bandwidth is taken into account as a reference. When it is
implemented on the PE side, svc-input-bandwidth is used.
o latency: used to define the latency constraint of the class. The
latency constraint can be expressed as the lowest possible latency
or a latency boundary expressed in milliseconds. How this latency
constraint will be fulfilled is up to the SP's implementation of
the service: a 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.
o jitter: used to define the jitter constraint of the class. The
jitter constraint can be expressed as the lowest possible jitter
or a jitter boundary expressed in microseconds. How this jitter
constraint will be fulfilled is up to the SP's implementation of
the service: a 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.
Wu, et al. Expires January 4, 2018 [Page 94]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
o bandwidth: used to define a guaranteed amount of bandwidth for the
class of service. It is expressed as a percentage. The
"guaranteed-bw-percent" parameter uses available bandwidth as a
reference. When the qos-profile container is implemented on the
CE side, svc-output-bandwidth is taken into account as a
reference. When it is implemented on the PE side, svc-input-
bandwidth is used. By default, the bandwidth reservation is only
guaranteed at the access level. The user can use the "end-to-end"
leaf to request an end-to-end bandwidth reservation, including
across the MPLS transport network. (In other words, the SP will
activate something in the MPLS core to ensure that the bandwidth
request from the customer will be fulfilled by the MPLS core as
well.) How this is done (e.g., RSVP reservation, controller
reservation) is out of scope for this document.
In addition, due to network conditions, some constraints may not be
completely fulfilled by the SP; in this case, the SP should advise
the customer about the limitations. How this communication is done
is out of scope for this document.
Example of service configuration using a standard QoS profile with
the following corresponding 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>
Wu, et al. Expires January 4, 2018 [Page 95]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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>
<location-reference>L1</location-reference>
</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>
Wu, et al. Expires January 4, 2018 [Page 96]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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>
Example of service configuration using a custom QoS profile with the
following corresponding 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>
Wu, et al. Expires January 4, 2018 [Page 97]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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>
<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>
Wu, et al. Expires January 4, 2018 [Page 98]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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>
The custom QoS profile for Site1 defines a REAL_TIME class with a
latency constraint expressed as the lowest possible latency. It also
defines two data classes -- DATA1 and DATA2. The two classes express
a latency boundary constraint as well as a bandwidth reservation, as
the REAL_TIME class is rate-limited to 10% of the service bandwidth
(10% of 100 Mbps = 10 Mbps). In cases where congestion occurs, the
REAL_TIME traffic can go up to 10 Mbps (let's assume that only 5 Mbps
are consumed). DATA1 and DATA2 will share the remaining bandwidth
(95 Mbps) according to their percentage. So, the DATA1 class will be
served with at least 76 Mbps of bandwidth, while the DATA2 class will
be served with at least 4.75 Mbps. The latency boundary information
of the data class may help the SP define a specific buffer tuning or
a specific routing within the network. The maximum percentage to be
used is not limited by this model but MUST be limited by the
management system according to the policies authorized by the SP.
Wu, et al. Expires January 4, 2018 [Page 99]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
6.12.3. Multicast
The "multicast" container defines the type of site in the customer
multicast service topology: source, receiver, or both. These
parameters will help the management system optimize the multicast
service. Users can also define the type of multicast relationship
with the customer: router (requires a protocol such as PIM), host
(IGMP or MLD), or both. An address family (IPv4, IPv6, or both) can
also be defined.
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.
Wu, et al. Expires January 4, 2018 [Page 100]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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.
Wu, et al. Expires January 4, 2018 [Page 101]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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
Wu, et al. Expires January 4, 2018 [Page 102]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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.
Wu, et al. Expires January 4, 2018 [Page 103]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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.
Wu, et al. Expires January 4, 2018 [Page 104]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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>
Wu, et al. Expires January 4, 2018 [Page 105]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
</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>
Wu, et al. Expires January 4, 2018 [Page 106]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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>
<mask>30</mask>
</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
Wu, et al. Expires January 4, 2018 [Page 107]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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
Wu, et al. Expires January 4, 2018 [Page 108]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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
Wu, et al. Expires January 4, 2018 [Page 109]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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 + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
Wu, et al. Expires January 4, 2018 [Page 110]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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.
Wu, et al. Expires January 4, 2018 [Page 111]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<?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>
Wu, et al. Expires January 4, 2018 [Page 112]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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>
Wu, et al. Expires January 4, 2018 [Page 113]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
</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>
<mask>24</mask>
</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>
<mask>64</mask>
</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>
Wu, et al. Expires January 4, 2018 [Page 114]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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
Wu, et al. Expires January 4, 2018 [Page 115]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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.
Wu, et al. Expires January 4, 2018 [Page 116]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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 Modules
As expressed in Section 5, this service model is intended to be
instantiated in a management system and not directly on network
elements.
Wu, et al. Expires January 4, 2018 [Page 117]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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 models
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).
Wu, et al. Expires January 4, 2018 [Page 118]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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>
Wu, et al. Expires January 4, 2018 [Page 119]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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>
<mask>24</mask>
</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>
Wu, et al. Expires January 4, 2018 [Page 120]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
<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:route-distinguisher>
100:1546542343
</l3vpn-network:route-distinguisher>
<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>
Wu, et al. Expires January 4, 2018 [Page 121]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
</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@2017-06-29.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;
}
organization
"IETF L3SM Working Group";
contact
"WG List: <mailto:l3sm@ietf.org>
Editor:
L3SM WG
Chairs:
Adrian Farrel, Qin Wu
";
Wu, et al. Expires January 4, 2018 [Page 122]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
description
"This YANG module defines a generic service configuration
model for Layer 3 VPNs. This model is common across all
vendor implementations.";
revision 2017-06-29 {
description
"First revision of RFC8049.";
reference
"RFC xxxx: YANG Data Model for L3VPN Service Delivery";
}
/* 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 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 {
Wu, et al. Expires January 4, 2018 [Page 123]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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 */
Wu, et al. Expires January 4, 2018 [Page 124]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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.
Wu, et al. Expires January 4, 2018 [Page 125]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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;
Wu, et al. Expires January 4, 2018 [Page 126]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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 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.
Wu, et al. Expires January 4, 2018 [Page 127]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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.";
Wu, et al. Expires January 4, 2018 [Page 128]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
}
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
Wu, et al. Expires January 4, 2018 [Page 129]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
"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
Wu, et al. Expires January 4, 2018 [Page 130]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
"Base identity for routing protocol type.";
}
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.";
}
Wu, et al. Expires January 4, 2018 [Page 131]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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 address-scope-type {
description
"Base identity for address scope.";
}
identity global-address {
base address-scope-type;
description
"Use global address.";
Wu, et al. Expires January 4, 2018 [Page 132]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
}
identity link-local-address {
base address-scope-type;
description
"Use link local address.";
}
/* 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.";
}
}
description
"Choice for cloud access policy.";
}
container authorized-sites {
list authorized-site {
key site-id;
leaf site-id {
type leafref {
path "/l3vpn-svc/sites/site/site-id";
}
description
"Site ID for each authorized site.";
}
description
"List of authorized sites.";
}
description
"Configuration of authorized sites.";
}
Wu, et al. Expires January 4, 2018 [Page 133]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
container denied-sites {
list denied-site {
key site-id;
leaf site-id {
type leafref {
path "/l3vpn-svc/sites/site/site-id";
}
description
"Site ID for each denied site.";
}
description
"List of denied sites.";
}
description
"Configuration of denied sites.";
}
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 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.";
}
Wu, et al. Expires January 4, 2018 [Page 134]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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.";
}
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;
}
Wu, et al. Expires January 4, 2018 [Page 135]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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.";
}
Wu, et al. Expires January 4, 2018 [Page 136]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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.";
Wu, et al. Expires January 4, 2018 [Page 137]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
}
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.";
Wu, et al. Expires January 4, 2018 [Page 138]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
}
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.
Wu, et al. Expires January 4, 2018 [Page 139]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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;
Wu, et al. Expires January 4, 2018 [Page 140]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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
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.";
}
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
Wu, et al. Expires January 4, 2018 [Page 141]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
"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 {
Wu, et al. Expires January 4, 2018 [Page 142]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
type inet:port-number;
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 must be higher than lower boundary.";
}
description
"Upper boundary for port.";
}
description
"Match on Layer 4 src port range.";
}
leaf l4-dst-port {
type inet:port-number;
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.";
}
Wu, et al. Expires January 4, 2018 [Page 143]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
description
"Match on Layer 4 dst port range.";
}
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 PE's perspective, the service input
bandwidth of the connection.";
}
leaf svc-output-bandwidth {
type uint64;
units bps;
mandatory true;
description
"From the PE's perspective, the service output
bandwidth of the connection. ";
}
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.";
Wu, et al. Expires January 4, 2018 [Page 144]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
}
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 3107) 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.";
}
Wu, et al. Expires January 4, 2018 [Page 145]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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 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 {
mandatory true;
description
"Choice for QoS profile.
Can be standard profile or customized profile.";
Wu, et al. Expires January 4, 2018 [Page 146]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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 rate-limit {
type uint8;
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.";
}
Wu, et al. Expires January 4, 2018 [Page 147]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
}
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 uint8;
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.";
}
Wu, et al. Expires January 4, 2018 [Page 148]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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 {
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.";
}
Wu, et al. Expires January 4, 2018 [Page 149]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
}
mandatory true;
description
"Layer on which encryption is applied.";
}
container encryption-profile {
choice profile {
mandatory true;
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 customer.";
}
}
description
"Type of keys to be used.";
}
}
description
"Choice of encryption profile, the encryption
profile can be provider profile or customer profile.";
}
description
"Profile of encryption to be applied.";
}
description
"Encryption parameters.";
}
description
"This grouping defines encryption parameters for a site.";
Wu, et al. Expires January 4, 2018 [Page 150]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
}
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 {
Wu, et al. Expires January 4, 2018 [Page 151]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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 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. The default value is
set to 1 assigned to the PE-CE link.";
}
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;
Wu, et al. Expires January 4, 2018 [Page 152]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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
"AS number.";
}
leaf-list address-family {
type address-family;
min-elements "1";
description
"If BGP is used on this site, this node
contains 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.";
Wu, et al. Expires January 4, 2018 [Page 153]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
}
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
Wu, et al. Expires January 4, 2018 [Page 154]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
"Configuration specific to static routing.";
}
container rip {
when "derived-from-or-self(../type, 'l3vpn-svc:rip')" {
description
"Only applies when 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 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 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.";
}
Wu, et al. Expires January 4, 2018 [Page 155]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
grouping site-attachment-ip-connection {
container ip-connection {
container ipv4 {
if-feature ipv4;
leaf address-allocation-type {
type identityref {
base address-allocation-type;
}
must "current() != 'slaac' and current() != 'provider-dhcp-slaac'" {
error-message "SLAAC is only applicable to IPv6";
}
description
"Defines how addresses are allocated.";
}
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;
mandatory true;
description
"Address of provider side";
}
leaf mask {
type uint8 {
range "0..31";
}
mandatory true;
description
"Subnet mask expressed in bits. The value zero
means unspecified (by the customer)";
}
choice address-assign {
default number;
case number {
leaf number-of-dynamic-address {
type uint8;
default 1;
description
"Describes the number of IP addresses the customer requires.";
}
}
case explicit {
container customer-addresses {
list address-group {
key "group-id";
Wu, et al. Expires January 4, 2018 [Page 156]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
leaf group-id {
type string;
description
"Group-id the list of start-to-end address belongs to.";
}
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.";
}
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 provider is required to implement
DHCP relay function.";
}
leaf provider-address {
type inet:ipv4-address;
mandatory true;
description
"Address of provider side";
}
leaf mask {
type uint8 {
range "0..31";
}
description
"Subnet mask expressed in bits. The value zero
means unspecified (by the customer)";
Wu, et al. Expires January 4, 2018 [Page 157]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
}
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;
mandatory true;
description
"IPv4 Address List of provider side. When protocol
allocation type is static, provider address must be configured";
}
leaf customer-address {
type inet:ipv4-address;
mandatory true;
description
"IPv4 Address of customer side.";
}
leaf mask {
type uint8 {
range "0..31";
}
mandatory true;
description
"Subnet mask expressed in bits. ";
}
description
"Describes IPv4 addresses used.";
}
description
"IPv4-specific parameters.";
}
container ipv6 {
if-feature ipv6;
Wu, et al. Expires January 4, 2018 [Page 158]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
leaf address-allocation-type {
type identityref {
base address-allocation-type;
}
default static-address;
description
"Defines how addresses are allocated.";
}
leaf address-scope-type {
type identityref {
base address-scope-type;
}
default "global-address";
description
"Define address scope.";
}
container provider-dhcp {
when "../address-allocation-type = 'l3vpn-svc:provider-dhcp' "+
"or ../address-allocation-type "+"= 'l3vpn-svc:provider-dhcp-slaac'" {
description
"Only applies when addresses are allocated by DHCP.";
}
leaf provider-address {
type inet:ipv6-address;
mandatory true;
description
"Address of provider side";
}
leaf mask {
type uint8 {
range "0..127";
}
mandatory true;
description
"Subnet mask expressed in bits. The value zero
means unspecified (by the customer)";
}
choice address-assign {
default number;
case number {
leaf number-of-dynamic-address {
type uint8;
default 1;
description
"Describes the number of IP addresses the customer requires.";
}
}
case explicit {
Wu, et al. Expires January 4, 2018 [Page 159]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
container customer-addresses {
list address-group {
key "group-id";
leaf group-id {
type string;
description
"Group-id the list of start-to-end address belongs to.";
}
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.";
}
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 provider is required to implement
DHCP relay function.";
}
leaf provider-address {
type inet:ipv6-address;
mandatory true;
description
"Address of provider side";
}
leaf mask {
type uint8 {
range "0..127";
}
Wu, et al. Expires January 4, 2018 [Page 160]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
description
"Subnet mask expressed in bits. The value zero
means unspecified (by the customer)";
}
container customer-dhcp-servers {
leaf-list server-ip-address {
type inet:ipv6-address;
description
"This node contains IP address of
customer DHCP server.If 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;
mandatory true;
description
"IPv6 Address of provider side.When protocol
allocation type is static, provider address must be configured";
}
leaf customer-address {
type inet:ipv6-address;
mandatory true;
description
"IPv6 Address of customer side.";
}
leaf mask {
type uint8 {
range "0..127";
}
mandatory true;
description
"Subnet mask expressed in bits.";
}
description
Wu, et al. Expires January 4, 2018 [Page 161]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
"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.";
}
}
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 OAM mechanisms used on the connection.
BFD is set as a fault detection mechanism, but the 'oam' container
Wu, et al. Expires January 4, 2018 [Page 162]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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 true;
description
"Enables IPv4 multicast.";
}
leaf ipv6 {
if-feature ipv6;
type boolean;
default false;
description
"Enables IPv6 multicast.";
}
description
"Defines protocol to carry multicast.";
}
Wu, et al. Expires January 4, 2018 [Page 163]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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 {
Wu, et al. Expires January 4, 2018 [Page 164]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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 {
type inet:ip-address;
description
"Management address.";
}
description
"Management configuration. Applicable only for
co-managed device.";
}
description
"Device configuration.";
}
description
"List of devices requested by customer.";
}
description
Wu, et al. Expires January 4, 2018 [Page 165]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
"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; In case
of multiVPN, whether the logical accesses of the sites belong
to the same set of VPNs or each logical accesses map 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.";
}
list entries {
key id;
leaf id {
type svc-id;
description
"Unique identifier for the policy entry.";
}
container filter {
choice lan {
default lan-tag;
case lan-tag {
leaf-list lan-tag {
type string;
description
"List of 'lan-tag' items to be matched.Lan-tag
is Internal tag to be used in VPN policies ";
}
}
case prefixes {
leaf-list ipv4-lan-prefix {
if-feature ipv4;
Wu, et al. Expires January 4, 2018 [Page 166]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
type inet:ipv4-prefix;
description
"List of IPv4 prefixes as LAN Prefixes to be matched.";
}
leaf-list ipv6-lan-prefix {
if-feature ipv6;
type inet:ipv6-prefix;
description
"List of IPv6 prefixes as LAN prefixes to be matched.";
}
}
description
"Choice of ways to do LAN matching.";
}
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.";
}
container vpn {
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.";
}
Wu, et al. Expires January 4, 2018 [Page 167]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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
Wu, et al. Expires January 4, 2018 [Page 168]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
"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.";
}
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.";
}
Wu, et al. Expires January 4, 2018 [Page 169]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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 a 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;
}
Wu, et al. Expires January 4, 2018 [Page 170]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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;
Wu, et al. Expires January 4, 2018 [Page 171]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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.";
}
description
"Container for Valid Provider Identifies.";
}
description
"Grouping for VPN Profile configuration.";
}
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 which actually uses vpn service.
In the case that any intermediary (e.g. Tier-2 provider
or partner) sells the vpn service to their enduser
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/commitioning
and operation for the service.
";
}
leaf vpn-service-topology {
type identityref {
base vpn-topology;
}
default any-to-any;
description
Wu, et al. Expires January 4, 2018 [Page 172]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
"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.";
Wu, et al. Expires January 4, 2018 [Page 173]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
}
}
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
Wu, et al. Expires January 4, 2018 [Page 174]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
"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
The YANG module defined in this document MAY be accessed via the
RESTCONF protocol [RFC8040] or the NETCONF protocol [RFC6241]. The
lowest RESTCONF or NETCONF layer requires that the transport-layer
protocol provide both data integrity and confidentiality; see
Section 2 in [RFC8040] and Section 2 in [RFC6241]. The client MUST
carefully examine the certificate presented by the server to
Wu, et al. Expires January 4, 2018 [Page 175]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
determine if it meets the client's expectations, and the server MUST
authenticate client access to any protected resource. The client
identity derived from the authentication mechanism used is subject to
the NETCONF Access Control Model (NACM) [RFC6536]. Other protocols
that are used to access this YANG module are also required to support
similar security mechanisms.
The data nodes defined in the "ietf-l3vpn-svc" YANG module MUST be
carefully created, read, updated, or deleted as appropriate. The
entries in the lists below include customer-proprietary or
confidential information; therefore, access to confidential
information MUST be limited to authorized clients, and other clients
MUST NOT be permitted to access the information.
o /l3vpn-svc/vpn-services/vpn-service
o /l3vpn-svc/sites/site
The data model proposes some security parameters than can be extended
via augmentation as part of the customer service request; those
parameters are described in Section 6.9.
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.
This document adds a new YANG module name in the "YANG Module Names"
registry [RFC7950]:
Name: ietf-l3vpn-svc
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
Prefix: l3vpn-svc
Reference: RFC 8049
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,
<http://www.rfc-editor.org/info/rfc2119>.
Wu, et al. Expires January 4, 2018 [Page 176]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005,
<http://www.rfc-editor.org/info/rfc4026>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://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, <http://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,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<http://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,
<http://www.rfc-editor.org/info/rfc6241>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://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,
<http://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,
<http://www.rfc-editor.org/info/rfc7950>.
Wu, et al. Expires January 4, 2018 [Page 177]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<http://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,
<http://www.rfc-editor.org/info/rfc8049>.
12.2. Informative References
[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,
<http://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,
<http://www.rfc-editor.org/info/rfc4760>.
Appendix A. 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
provided useful review to this document.
Jan Lindblad reviewed the first release of RFC8049 and found some
bugs and His thorough YANG Doctor review on the YANG Model is
valuable input to revision of RFC8049. David ball also provided a
second review on published RFC8049.
Many thanks to these people.
Appendix B. 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 bis.
Appendix C. Open Issues
o The algorithm for encryption customer profile is still a string.
However it is customer profile not provider profile.
Wu, et al. Expires January 4, 2018 [Page 178]
Internet-Draft YANG Data Model for L3VPN Service Delivery July 2017
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
Wu, et al. Expires January 4, 2018 [Page 179]