Internet DRAFT - draft-l3vpn-service-yang
draft-l3vpn-service-yang
xxx Working Group S. Litkowski
Internet-Draft Orange Business Service
Intended status: Standards Track R. Shakir
Expires: August 27, 2015 BT
L. Tomotaki
Verizon
K. D'Souza
ATT
February 23, 2015
YANG Data Model for L3VPN service delivery
draft-l3vpn-service-yang-00
Abstract
This document defines a YANG data model that can be used to deliver a
Layer 3 Provider Provisioned VPN service. The document is limited to
the BGP PE-based VPNs as described in [RFC4110] and [RFC4364]. This
model is intended to be instantiated at management system to deliver
the overall service. This model is not a configuration model to be
used directly on network elements. This model provides an abstracted
view of the Layer 3 IPVPN service configuration components. It will
be up to a management system to take this as an input and use
specific configurations models to configure the different network
elements to deliver the service. How configuration of network
elements is done is out of scope of the document.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Litkowski, et al. Expires August 27, 2015 [Page 1]
Internet-Draft l3vpn-svc-cfg February 2015
This Internet-Draft will expire on August 27, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Layer 3 IP VPN service model . . . . . . . . . . . . . . . . 4
4. Service data model usage . . . . . . . . . . . . . . . . . . 4
5. Design of the Data Model . . . . . . . . . . . . . . . . . . 5
5.1. VPN service overview . . . . . . . . . . . . . . . . . . 9
5.1.1. VPN service topology . . . . . . . . . . . . . . . . 9
5.1.1.1. Route Target allocation . . . . . . . . . . . . . 9
5.1.1.2. Any to any . . . . . . . . . . . . . . . . . . . 10
5.1.1.3. Hub and Spoke . . . . . . . . . . . . . . . . . . 11
5.1.1.4. Hub and Spoke disjoint . . . . . . . . . . . . . 12
5.1.2. Cloud access . . . . . . . . . . . . . . . . . . . . 12
5.1.3. Multicast service . . . . . . . . . . . . . . . . . . 15
5.2. Site overview . . . . . . . . . . . . . . . . . . . . . . 15
5.2.1. Deciding where to connect the site . . . . . . . . . 16
5.2.1.1. Site location . . . . . . . . . . . . . . . . . . 16
5.2.1.2. Site availability . . . . . . . . . . . . . . . . 17
5.2.1.3. Site diversity . . . . . . . . . . . . . . . . . 19
5.2.1.4. Route Distinguisher and VRF allocation . . . . . 21
5.2.2. VPN policy . . . . . . . . . . . . . . . . . . . . . 21
5.2.3. Security . . . . . . . . . . . . . . . . . . . . . . 22
5.2.4. Management . . . . . . . . . . . . . . . . . . . . . 22
5.2.5. Attachment . . . . . . . . . . . . . . . . . . . . . 23
5.2.5.1. Bearer . . . . . . . . . . . . . . . . . . . . . 23
5.2.5.2. Connection . . . . . . . . . . . . . . . . . . . 23
5.2.6. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.7. Service . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.7.1. QoS . . . . . . . . . . . . . . . . . . . . . . . 31
Litkowski, et al. Expires August 27, 2015 [Page 2]
Internet-Draft l3vpn-svc-cfg February 2015
5.2.7.2. Multicast . . . . . . . . . . . . . . . . . . . . 36
5.2.7.3. Traffic protection . . . . . . . . . . . . . . . 36
5.2.8. Customer specific information . . . . . . . . . . . . 37
5.2.8.1. Customer cascaded LANs with provider managed CE . 37
5.2.8.2. Customer LANs with provider managed CE . . . . . 38
5.2.8.3. Customer LANs with customer managed CE . . . . . 38
5.3. Using configuration templates . . . . . . . . . . . . . . 38
6. Service model usage example . . . . . . . . . . . . . . . . . 41
7. Interaction with Other YANG Modules . . . . . . . . . . . . . 46
8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 50
9. To do list / Open questions / Open issues . . . . . . . . . . 75
10. Security Considerations . . . . . . . . . . . . . . . . . . . 76
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 76
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 76
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76
14. Normative References . . . . . . . . . . . . . . . . . . . . 76
Appendix A. Example: NETCONF <get> Reply . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77
1. Introduction
This document defines a YANG data model for Layer 3 IPVPN service
configuration.
1.1. Tree diagram
A simplified graphical representation of the data model is presented
in Section 5.
The meaning of the symbols in these diagrams is as follows:
o Brackets "[" and "]" enclose list keys.
o Curly braces "{" and "}" contain names of optional features that
make the corresponding node conditional.
o Abbreviations before data node names: "rw" means configuration
(read-write), and "ro" state data (read-only).
o Symbols after data node names: "?" means an optional node and "*"
denotes a "list" or "leaf-list".
o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not
shown.
Litkowski, et al. Expires August 27, 2015 [Page 3]
Internet-Draft l3vpn-svc-cfg February 2015
2. Definitions
Customer Edge (CE) Device: The equipment on the customer side of the
SP-customer boundary (the customer interface).
Provider Edge (PE) Device: The equipment on the SP side of the SP-
customer boundary (the customer interface).
PE-Based VPNs: The PE devices know that certain traffic is VPN
traffic. They forward the traffic (through tunnels) based on the
destination IP address of the packet, and optionally on based on
other information in the IP header of the packet. The PE devices are
themselves the tunnel endpoints. The tunnels may make use of various
encapsulations to send traffic over the SP network (such as, but not
restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels).
3. Layer 3 IP VPN service model
A Layer 3 IPVPN service is a collection of sites that are authorized
to exchange traffic between each other over a shared IP
infrastructure. This layer 3 VPN service model aims at providing a
common understanding on how the corresponding IP VPN service is to be
deployed over the shared infrastructure. This service model is
limited to BGP PE-Based VPNs as described in [RFC4110] and [RFC4364].
4. Service data model usage
Litkowski, et al. Expires August 27, 2015 [Page 4]
Internet-Draft l3vpn-svc-cfg February 2015
L3VPN-SVC |
MODEL |
|
+------------------+ +-----+
| Orchestration | < --- > | OSS |
+------------------+ +-----+
| |
+----------------+ |
| Config manager | |
+----------------+ |
| |
| Netconf/CLI ...
| |
+------------------------------------------------+
Network
+++++++
+ AAA +
+++++++
+++++++ Bearer ++++++++ ++++++++ +++++++
+ CEA + ------- + PE A + + PE B + ----- + CEB +
+++++++ Cnct ++++++++ ++++++++ +++++++
Site A Site B
The idea of the L3 IPVPN service model is to propose an abstracted
interface to manage configuration of components of a L3VPN service.
A typical usage is to use this model as an input for an orchestration
layer who will be responsible to translate it to orchestrated
configuration of network elements who will be part of the service.
The network elements can be routers, but also servers (like AAA), and
not limited to these examples. The configuration of network elements
may be done by CLI, or by NetConf/RestConf coupled with specific
configuration YANG data models (BGP, VRF, BFD ...) or any other way.
The usage of this service model is not limited to this example, it
can be used by any component of the management system but not
directly by network elements.
5. Design of the Data Model
The YANG module is divided in two main containers : vpn-svc, sites.
The vpn-svc defines global parameters for the VPN service for a
specific customer.
Litkowski, et al. Expires August 27, 2015 [Page 5]
Internet-Draft l3vpn-svc-cfg February 2015
A site is composed of a customer edge router (CE) attached to a
provider edge router (PE). The attachment is done through a bearer
with a connection (transport protocol) on top. The bearer refers to
physical properties of the attachment while the connection refers to
more protocol oriented properties.
Authorization of traffic exchange is done through what we call a VPN
policy or VPn topology defining routing exchange rules between sites.
The figure below describe the overall structure of the YANG module:
module: ietf-l3vpn-svc
+--rw l3vpn-svc
+--rw vpn-svc* [name]
| +--rw name string
| +--rw id? uint32
| +--rw customer-name? string
| +--rw topology? identityref
| +--rw cloud-access* [cloud-identifier]
| | +--rw cloud-identifier string
| | +--rw authorized-sites* [site-id]
| | | +--rw site-id leafref
| | +--rw denied-sites* [site-id]
| | | +--rw site-id leafref
| | +--rw nat-enabled? boolean
| | +--rw customer-nat-address? inet:ipv4-address
| +--rw multicast
| +--rw tree-flavor* identityref
| +--rw rp
| | +--rw ipv4-address? inet:ipv4-address
| | +--rw ipv6-address? inet:ipv6-address
| +--rw rp-discovery? identityref
| +--rw anycast-rp-location* string
+--rw sites* [site-id]
+--rw template? boolean
+--rw site-id string
+--rw native-vpn? leafref
+--rw site-type? identityref
+--rw apply-template? leafref
+--rw location
| +--rw city-code? string
| +--rw country-code? string
+--rw site-diversity
| +--rw type? enumeration
| +--rw site-group* uint32
+--rw security
| +--rw apply-template? leafref
| +--rw authentication
Litkowski, et al. Expires August 27, 2015 [Page 6]
Internet-Draft l3vpn-svc-cfg February 2015
| +--rw encryption
| +--rw access-control-list
+--rw availability
| +--rw availability-type
| | +--rw service-type? identityref
| | +--rw access-type? identityref
| +--rw loadsharing-type? identityref
+--rw attachment
| +--rw apply-template? leafref
| +--rw bearer
| | +--rw type? string
| | +--rw bearer-reference? string
| +--rw connection
| +--rw ipv4
| | +--rw address-allocation-type? identityref
| | +--rw subnet-prefix? inet:ipv4-prefix
| +--rw ipv6
| | +--rw address-allocation-type? string
| | +--rw subnet-prefix? inet:ipv6-prefix
| +--rw routing-protocols* [type]
| +--rw type identityref
| +--rw ospf
| | +--rw address-family* identityref
| | +--rw area-address? yang:dotted-quad
| | +--rw metric? uint16
| | +--rw sham-link* [target-site]
| | +--rw target-site leafref
| | +--rw metric? uint16
| +--rw bgp
| | +--rw address-family* identityref
| +--rw static
| | +--rw address-family* identityref
| +--rw rip
| | +--rw address-family* identityref
| +--rw vrrp
| | +--rw address-family* identityref
| +--rw bfd-enabled? boolean
+--rw service
| +--rw apply-template? leafref
| +--rw qos
| | +--rw qos-classification-policy
| | | +--rw rules* [id]
| | | +--rw id uint16
| | | +--rw match
| | | | +--rw ipv4-src-prefix? inet:ipv4-prefix
| | | | +--rw ipv6-src-prefix? inet:ipv6-prefix
| | | | +--rw ipv4-dst-prefix? inet:ipv4-prefix
| | | | +--rw ipv6-dst-prefix? inet:ipv6-prefix
Litkowski, et al. Expires August 27, 2015 [Page 7]
Internet-Draft l3vpn-svc-cfg February 2015
| | | | +--rw l4-src-port? uint16
| | | | +--rw l4-dst-port? uint16
| | | | +--rw l4-protocol? union
| | | +--rw target-class-id? string
| | +--rw std-qos-profile? string
| | +--rw custom-qos-profile
| | +--rw class* [class-id]
| | +--rw class-id string
| | +--rw rate-limit? uint8
| | +--rw priority-level? uint8
| | +--rw guaranteed-bw-percent? uint8
| +--rw svc-bandwidth? uint32
| +--rw svc-mtu? uint16
| +--rw traffic-protection
| | +--rw link-local-protection? boolean
| | +--rw node-local-protection? boolean
| | +--rw node-global-protection? boolean
| +--rw mpls
| | +--rw signalling-type? enumeration
| +--rw multicast
| +--rw site-type? enumeration
+--rw management
| +--rw type? identityref
| +--rw management-transport? identityref
| +--rw address? union
+--rw vpn-policy
| +--rw import-policy
| | +--rw vpn* [vpn]
| | +--rw vpn leafref
| +--rw export-policy
| +--rw entries* [id]
| +--rw id uint32
| +--rw lan-prefixes
| | +--rw ipv4-lan-prefixes* [lan]
| | | +--rw lan inet:ipv4-prefix
| | +--rw ipv6-lan-prefixes* [lan]
| | +--rw lan inet:ipv6-prefix
| +--rw lan-tag* string
| +--rw vpn* leafref
+--rw maximum-routes
| +--rw address-family* [af]
| +--rw af identityref
| +--rw maximum-routes? uint32
+--rw customer-specific-information
+--rw name? string
+--rw autonomous-system? uint32
+--rw interface? string
+--rw customer-lan-connection* [address]
Litkowski, et al. Expires August 27, 2015 [Page 8]
Internet-Draft l3vpn-svc-cfg February 2015
| +--rw address union
| +--rw lan-protocol? identityref
+--rw cascaded-lan-prefixes
+--rw ipv4-lan-prefixes* [lan]
| +--rw lan inet:ipv4-prefix
| +--rw lan-tag? string
| +--rw next-hop? inet:ipv4-address
+--rw ipv6-lan-prefixes* [lan]
+--rw lan inet:ipv6-prefix
+--rw lan-tag? string
+--rw next-hop? inet:ipv6-address
5.1. VPN service overview
The vpn-svc top container contains generic informations about the VPN
service. The name of the vpn-svc refers to an internal reference for
this VPN service, while customer name refers to a more explicit
reference to the customer. An identifier (id) is also present for
information systems and configuration that requires this information.
This identifier is purely internal to the organization responsible
for the VPN service. The vpn-svc name and id must be unique.
5.1.1. VPN service topology
The type of topology of the VPN is required for configuration.
Current proposal supports : any-to-any, hub and spoke (where hubs can
exchange traffic), and hub and spoke disjoint (where hubs cannot
exchange traffic). New topologies could be added by augmentation.
5.1.1.1. Route Target allocation
Layer 3 PE-based VPN is built using route-targets as described in
[RFC4364]. It is expected management system to allocate
automatically set of route-targets upon a VPN service creation
request. How management system allocates route-targets is out of
scope of the document but multiple ways could be envisaged as
described below.
Litkowski, et al. Expires August 27, 2015 [Page 9]
Internet-Draft l3vpn-svc-cfg February 2015
Management system
<---------------------------------------------------->
Request RT
+-----------------------+ Topo a2a +-------------+
RestConf | | -----> | |
User ------------- | Service Orchestration | | Network OSS |
l3vpn-svc | | <----- | |
model +-----------------------+ Response +-------------+
RT1,RT2
In the example above, a service orchestration, owning the
instantiation of this service model, request route-targets to the
network OSS. Based on the requested VPN topology, the network OSS
replies with one or multiple route-targets. The interface between
this service orchestration and network OSS is out of scope of this
document.
+---------------------------+
RestConf | |
User ------------- | Service Orchestration |
l3vpn-svc | |
model | |
| RT pool : 10:1->10:10000 |
| RT pool : 20:50->20:5000 |
+---------------------------+
In the example above, a service orchestration, owning the
instantiation of this service model, owns one or more pools of route-
target (filled by service provider) that can be allocated. Based on
the requested VPN topology, it will allocate one or multiple route-
targets from the pool.
The mechanism displayed above are just examples and should not be
considered as exhaustive list of solutions.
5.1.1.2. Any to any
+------------------------------------------------------------+
| VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 |
| |
| VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 |
+------------------------------------------------------------+
Figure - Any to any VPN topology
Litkowski, et al. Expires August 27, 2015 [Page 10]
Internet-Draft l3vpn-svc-cfg February 2015
In the any to any topology, all VPN sites can discuss between each
other without any restriction. It is expected that the management
system that owns a any to any IPVPN service request through this
model, needs to assign and then configure the VRF and route-targets
on the appropriate PEs. In case of any to any, in general a single
route-target is required and every VRF imports and exports this
route-target.
5.1.1.3. Hub and Spoke
+-------------------------------------------------------------+
| Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
| +----------------------------------+
| |
| +----------------------------------+
| Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+
Figure - Hub and Spoke VPN topology
In the hub and spoke topology, all spoke sites can discuss only with
Hub sites but not between each other. Hubs can discuss also between
each other. It is expected that the management system that owns a
any to any IPVPN service request through this model, needs to assign
and then configure the VRF and route-targets on the appropriate PEs.
In case of hub and spoke, in general a two route-targets are required
(one route-target for Hub routes, one route-target for spoke routes).
A Hub VRF, connecting Hub sites, will export Hub routes with Hub
route-target, and will import Spoke routes through Spoke route-
target. It will also import the Hub route-target to permit Hub to
Hub communication. A Spoke VRF, connecting Spoke sites, will export
Spoke routes with Spoke route-target, and will import Hub routes
through Hub route-target.
The management system must take into account Hub and Spoke
connections constraints. For example, if management system decides
to mesh a spoke site and a hub site on the same PE, it needs to mesh
connections in different VRFs as displayed in the figure below.
Hub_Site ------- (VRF_Hub) PE1
(VRF_Spoke)
/ |
Spoke_Site1 -------------------+ |
|
Spoke_Site2 -----------------------+
Litkowski, et al. Expires August 27, 2015 [Page 11]
Internet-Draft l3vpn-svc-cfg February 2015
5.1.1.4. Hub and Spoke disjoint
+-------------------------------------------------------------+
| Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
+--------------------------+ +-------------------------------+
| |
+--------------------------+ +-------------------------------+
| Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+
Figure - Hub and Spoke disjoint VPN topology
In the hub and spoke disjoint topology, all spoke sites can discuss
only with Hub sites but not between each other. Hubs cannot discuss
between each other. It is expected that the management system that
owns a any to any IPVPN service request through this model, needs to
assign and then configure the VRF and route-targets on the
appropriate PEs. In case of hub and spoke, in general a two route-
targets are required (one route-target for Hub routes, one route-
target for spoke routes). A Hub VRF, connecting Hub sites, will
export Hub routes with Hub route-target, and will import Spoke routes
through Spoke route-target. A Spoke VRF, connecting Spoke sites,
will export Spoke routes with Spoke route-target, and will import Hub
routes through Hub route-target.
The management system must take into account Hub and Spoke
connections constraints as in the previous case.
5.1.2. Cloud access
The proposed model provides cloud access configuration through the
cloud-access container. Internet access can typically be considered
as cloud access service. The cloud-access container provides
parameters for network address translation and authorization rules.
A cloud identifier is used to reference the target service. This
identifier is local to each administration.
If NAT is required to access to the cloud, the nat-enabled leaf must
be set to true. A NAT address can be provided in customer-nat-
address, in case the customer is providing the public IP address for
the cloud access. If service provider is providing the NAT address,
customer-nat-address may not be necessary as it can be picked from a
service provider pool.
By default, all sites in the IPVPN must be authorized to access to
the cloud. In case restrictions are required, a user may configure
the authorized-sites and denied-sites list. The authorization-sites
Litkowski, et al. Expires August 27, 2015 [Page 12]
Internet-Draft l3vpn-svc-cfg February 2015
defines the list of sites authorized for cloud access. The denied-
sites defines the list of sites denied for cloud access. The model
supports both "deny all expect" and "accept all expect"
authorization.
The "deny all expect" behavior is obtained by filling only the
authorized-sites. All the sites listed will be authorized, all
others will be denied.
The "accept all expect" behavior is obtained by filling only the
denied-sites. All the sites listed will be denied, all others will
be authorized.
Defining both denied-sites and authorized-sites must be processed as
"deny all expect", so the denied-sites will have not effect.
How the restrictions will be configured on network elements is out of
scope of this document and will be specific to each deployment.
IPVPN
++++++++++++++++++++++++++++++++ +++++++++++
+ Site 3 + --- + Cloud1 +
+ Site 1 + +++++++++++
+ +
+ Site 2 + --- ++++++++++++
+ + + Internet +
+ Site 4 + ++++++++++++
++++++++++++++++++++++++++++++++
|
++++++++++
+ Cloud2 +
++++++++++
In the example above, we may configure the global VPN to access
Internet by creating a cloud-access pointing to the cloud identifier
for Internet service. No authorized-sites will be configured as all
sites are required to access to Internet. NAT-enabled will be set to
true and a nat-address will be configured.
Litkowski, et al. Expires August 27, 2015 [Page 13]
Internet-Draft l3vpn-svc-cfg February 2015
<vpn-svc>
<name>ZKITYHJ054687</name>
<id>12456487</id>
<customer-name>CUSTOMER_1</customer-name>
<topology>any-to-any</topology>
<cloud-access>
<cloud-identifier>51</cloud-identifier>
<nat-enabled>true</nat-enabled>
<nat-address>1.1.1.1</nat-address>
</cloud-access>
</vpn-svc>
If Site1 and Site2 requires access to Cloud1, a new cloud-access will
be created pointing to the cloud identifier of Cloud1. Authorized
sites will be filled with reference to Site1 and Site2.
<vpn-svc>
<name>ZKITYHJ054687</name>
<id>12456487</id>
<customer-name>CUSTOMER_1</customer-name>
<topology>any-to-any</topology>
<cloud-access>
<cloud-identifier>1111111</cloud-identifier>
<authorized-sites>
<site-id>site1</site-id>
<site-id>site2</site-id>
</authorized-sites>
</cloud-access>
</vpn-svc>
If all sites except Site1 requires access to Cloud2, a new cloud-
access will be created pointing to the cloud identifier of Cloud2.
denied-sites will be filled with reference to Site1.
<vpn-svc>
<name>ZKITYHJ054687</name>
<id>12456487</id>
<customer-name>CUSTOMER_1</customer-name>
<topology>any-to-any</topology>
<cloud-access>
<cloud-identifier>22222222</cloud-identifier>
<denied-sites>
<site-id>site1</site-id>
</denied-sites>
</cloud-access>
</vpn-svc>
Litkowski, et al. Expires August 27, 2015 [Page 14]
Internet-Draft l3vpn-svc-cfg February 2015
5.1.3. Multicast service
Multicast in IP VPN is described in [RFC6513].
If IPVPN supports multicast service, it is expected to provide inputs
on global multicast parameters.
The user of this model will need to fill the flavor of trees that
will be used by customer within the IPVPN (Customer tree). The
proposed model supports ASM, SSM and BiDirectional trees (and can be
augmented). Multiple flavors of tree can be supported
simultaneously.
(SSM tree)
Recv (IGMPv3) -- Site2 ------- PE2
PE1 --- Site1 --- Source1
\
---- Source2
(ASM tree)
Recv (IGMPv2) -- Site3 ------- PE3
(SSM tree)
Recv (IGMPv3) -- Site4 ------- PE4
/
Recv (IGMPv2) -- Site5 --------
(ASM tree)
In case of ASM flavor, this model requires to fill the rp and rp-
discovery parameters. The rp-discovery supports the auto-rp, static-
rp, anycast-rp and bsr-rp modes.
5.2. Site overview
The L3VPN service is really attached to the notion of sites. A site
is composed of some characteristics :
o Unique identifier (site-id) : to uniquely identify the site within
the overall network infrastructure. The identifier is a string
permitting to any encoding for the local administration of the VPN
service.
o Location (location) : site location informations to permit easy
retrieval on nearest available ressources.
o Site constraints (site-diversity) : site-diversity container
permit to define some constraints for the setup of the site, for
Litkowski, et al. Expires August 27, 2015 [Page 15]
Internet-Draft l3vpn-svc-cfg February 2015
example : PE disjointness or PoP disjointness. A site-group
identifier permit to manage the disjointness. Two sites with the
same group and requiring PE disjointness cannot be connected on
the same PE.
o Site availability (site-availability) : permit to define the
availability service type (single, loadsharing, primary/backup
scenarios) and also the access-type within the service (single,
primary, backup ...).
o Native VPN (native-vpn) and site-type : reference the vpn-svc, the
site is belonging to. The site-type defines the role of the site
within the native VPN topology (e.g. Hub, Spoke ...).
o Management (management) : defines the model of management of the
site, for example : comanaged, customer managed or provider
managed.
o Attachment (attachment) : defines parameters of the attachment of
the site, especially bearer, connection and service parameters.
The site configuration is viewed as a global entity, we assume that
it is mostly the role of the management to split the parameters
between the different elements within the network. For example, in
the case of the attachment configuration, the management system needs
to split the overall parameters between PE configuration and CE
configuration.
5.2.1. Deciding where to connect the site
The management system will have to decide where to connect the site
in the provider network (PE, aggregation switch ...). This decision
may be based on any constraint that are up to the service provider :
least load, distance ... The current model proposes some parameters
that will help the management system to decide where to attach the
customer site.
5.2.1.1. Site location
The location information provided in this model may be used by a
management system to decide the target PE to mesh the site.
Litkowski, et al. Expires August 27, 2015 [Page 16]
Internet-Draft l3vpn-svc-cfg February 2015
PoP#1 (New York)
+---------+
| PE1 |
Site #1 ---... | PE2 |
(Atlantic City) | PE3 |
+---------+
PoP#2 (Washington)
+---------+
| PE4 |
| PE5 |
| PE6 |
+---------+
PoP#3 (Philadelphia)
+---------+
| PE7 |
Site #2 ---... | PE2 |
(Reston) | PE9 |
+---------+
In the example below, the management system may decide to mesh Site
#1 on a PE from Philadelphia PoP for distance reason. It may also
take in account resources available on PEs to decide the exact target
PE (least load). In case of shortest distance PE used, it may also
decide to mesh Site #2 on Washington PoP.
5.2.1.2. Site availability
The site availability defines parameters for the site redundancy.
The YANG model proposes three models of redundancy (service-type)
that may be extended by augmentation :
o single : single homing scenario, no attachment redundancy
required.
o primary-backup : dual homing scenario, one attachment is primary,
when the attachment goes down, traffic goes to the backup
attachment.
o loadsharing : multihoming scenario, both attachment are used at
the same time. How loadsharing is done is not part of service-
type.
The site availability also defines access-type which defines the role
of the site in the availability system. The YANG model proposes four
models of access-type :
Litkowski, et al. Expires August 27, 2015 [Page 17]
Internet-Draft l3vpn-svc-cfg February 2015
o single-access : used to indicate the single access function. Used
for single-homed sites and coupled with "single" service-type.
o primary-access : used to indicate the primary access in a primary-
backup service-type.
o backup-access : used to indicate the backup access in a primary-
backup service-type.
o loadsharing-access : used to indicate any access in a loadsharing
service-type.
The figure below describes how site availability attributes can be
used.
Hub#1 LAN Hub#2 LAN
| primary-backup loadsharing |
| primary-access loadsharing-access |
|--- CE1 ------- PE1 PE3 --------- CE3 --- |
| |
| |
|--- CE2 ------- PE2 PE4 --------- CE4 --- |
| primary-backup loadsharing |
backup-access loadsharing-access
PE5
| single
| single-access
|
CE5
|
Spoke#1 site
In case of loadsharing, the YANG model proposes to define the
loadsharing policy using loadsharing-type. The model proposes the
following types that could be augmented. These option may be used on
any remote sites (single, primary-backup ...) facing a loadsharing
site.
o loadsharing-ibgp : loadbalancing will be done between multiple
received iBGP paths.
o loadsharing-eibgp : loadbalancing will be done between multiple
received iBGP paths or eBGP paths : typical application is when a
remote site is connected on the same PE than the hub requiring
loadsharing.
Litkowski, et al. Expires August 27, 2015 [Page 18]
Internet-Draft l3vpn-svc-cfg February 2015
Considering the diagram above, to enable loadsharing for Hub#2 sites,
Hub#1 sites and Spoke#1 site can be configured with loadsharing-ibgp
as loadsharing-type. If a Spoke#2 site was connected also on PE4,
Spoke#2 site may be configured with loadsharing-eibgp as loadsharing-
type.
Hub#2 LAN
loadsharing |
loadsharing-access |
PE3 --------- CE3 --- |
|
|
PE4 --------- CE4 --- |
| loadsharing |
| loadsharing-access
|
| single
| single-access
| loadsharing-eibgp
|
CE6
|
Spoke#2 site
The site availability will have an impact on site meshing location,
as dual homing may require meshing at least on different network
elements (see next section).
5.2.1.3. Site diversity
The site diversity defines what is the acceptable fate sharing level
in case multiple sites for a single VPN must be provisioned in a
common location. The site diversity introduces the notion of site-
group. Sites belonging to the same site-group cannot share the same
fate. We propose to introduce two constraints :
PoP diverse : site belonging to the same site-group must be
provisioned on different PoPs.
PE diverse : site belonging to the same site-group must be
provisioned on different PE routers.
How these diversity constraints are applied is out of scope of the
document. As an example, the management system receiving the request
for diversity, may exchange information with some OSS components to
define the best target PEs based on location and ressource
availability.
Litkowski, et al. Expires August 27, 2015 [Page 19]
Internet-Draft l3vpn-svc-cfg February 2015
Consider a dual homed hub site, it is desirable for redundancy to
provision the two VPN access connections on two different PEs or two
different PoPs.
PoP#1
+---------+
| PE1 |
Hub_Site_primary ------ | PE2 |
| PE3 |
+---------+
PoP#2
+---------+
| PE4 |
Hub_Site_backup ------- | PE5 |
| PE6 |
+---------+
In a PoP diverse scenario, the management system may decide to mesh
Hub_Site_primary on any PE of PoP#1 and Hub_Site_backup on any PE of
PoP#2. In a PE diverse scenario, if the management system decides to
mesh Hub_Site_primary on PE1, it is require to mesh Hub_Site_backup
on any PE different from PE1.
Site diversity is not limited to multihoming scenarios. If a company
has multiple small branch offices (single homed) that requires to be
connected in the same location, it is desirable to dispatch the
attachment on multiple PEs. So in case of PE crash, only some
offices will be impacted.
PoP#1
+---------+
| PE1 |
Office#1 ---... | PE2 |
Office#2 ---... | PE3 |
Office#3 ---... | PE4 |
Office#...--... +---------+
Office#100--...
In the figure above, it may be good to mesh 25 offices on each PE of
PoP#1 to prevent concentration of two many customer offices on common
network elements.
Litkowski, et al. Expires August 27, 2015 [Page 20]
Internet-Draft l3vpn-svc-cfg February 2015
5.2.1.4. Route Distinguisher and VRF allocation
Route distinguisher is also a critical parameter of PE-based L3VPN as
described in [RFC4364] that will permit to distinguish common
addressing plans in different VPNs. As for Route-targets, it is
expected management system to allocate a VRF on the target PE and a
route-distinguisher for this VRF.
If a VRF exists on the target PE, and the VRF fulfils 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 fulfils the
connectivity constraints for a site is out of scope of this document.
If no VRF exists on the target PE, filling the site constraints, the
management system will have to initiate a new VRF creation on the
target PE and will have to allocate a new route distinguisher for
this new VRF.
The management system may apply a per-VPN or per-VRF allocation
policy for the route-distinguisher depending of the service provider
policy. In a per-VPN allocation policy, all VRFs (dispatched on
multiple PEs) within a VPN will share the same route distinguisher
value. In a per-VRF model, all VRFs will always have a unique route-
distinguisher value.
Allocation of route-distinguisher may be done in the same way as the
route-targets. The example provided in Section 5.1.1.1 could be
reused.
5.2.2. VPN policy
The VPN policy defines the route exchange between multiple VPNs. A
vpn-policy configuration is not required if there is no inter VPN
relations. Indeed the VPN policy already exists from the topology of
the VPN, and the management system using this service model must
derive the VRF configuration from the VPN topology. The vpn-policy
container only defines relations with VPNs that are not the native
vpn. In case, a vpn-policy is defined, the management system will
built the route-target policy configuration from a combination of
both the vpn-policy and the vpn-topology.
Litkowski, et al. Expires August 27, 2015 [Page 21]
Internet-Draft l3vpn-svc-cfg February 2015
+--------------------------------------------------------------+
| VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 |
+--------------------------------------------------------------+
+--------------------------------------------------------------+
| VPN2_Site1 ------ PE3 PE4 ------ VPN2_Site2 |
+----------------------------------+ |
| |
+------------------------------------------------------------+ |
| VPN3_Site1 ------ PE5 | PE6 ------ VPN3_Site2 | |
+------------------------------------------------------------+ |
| |
+---------------------------+
Let us consider two existing vpn service VPN1 and VPN2 with a any-to-
any topology. When the vpn services are provisioned a route-target
value will be affected by the OSS of the service provider for these
VPNs. Let's call RT1 the route-target of VPN1,and RT2 the route-
target of VPN2. Now we consider a new VPN service VPN3 (any to any)
that must be provisioned, RT3 will be allocated by the OSS for proper
configuration on network elements.
Consider a site#1 in VPN3 that must communicate only in VPN3, in this
case, there is no need to specify any vpn-policy for site#1, as
site#1 will be provisioned using the native-vpn policy which is any-
to-any in VPN3. VRF on PE5 for VPN3 will be so provisioned by the
management system using RT3 value as import and export value.
Consider a site#2 in VPN3 that must communicate in VPN3, and a
specific LAN LAN1 must communicate with VPN2, in this case, we need
to define for site#2 a vpn-policy that imports VPN2 and exports LAN1
to VPN2. VRF on PE6 for VPN3 will be so provisioned by the
management system using RT3 value as import and RT3 as export value
plus RT2 for LAN1 prefix.
5.2.3. Security
Security container defines customer specific security parameters for
the site. This section will be detailled in future revision.
5.2.4. Management
The model proposes three types of common management options :
o comanaged : the CE router is managed by the provider and also by
the customer.
o provider-managed : the CE router is managed only by the provider.
Litkowski, et al. Expires August 27, 2015 [Page 22]
Internet-Draft l3vpn-svc-cfg February 2015
o customer-managed : the CE router is managed only by the customer.
Based on the management model, different security options may be
derived.
In case of "provider-managed" or "comanaged", the model proposes some
option to define the management transport protocol (IPv4 or IPv6) and
the associated management address.
5.2.5. Attachment
The attachment defines how the service is connected on the network
and is splitted in three class of parameters :
o bearer : defines physical parameters of the attachment.
o connection : defines protocol parameters of the attachment
(transport layer and routing protocols).
5.2.5.1. Bearer
TBD.
5.2.5.2. Connection
The connection defines the protocol parameters of the attachment
(IPv4 and IPv6) as well as routing.
5.2.5.2.1. IP addressing
IP subnet can be configured for either transport protocols. For a
dual stack connection, two subnets will be provided, one for each
transport layer.
The address-allocation-type will help in defining how the address
allocation must be done. The current model proposes three ways of IP
address allocation :
o pe-dhcp : the PE router will provide DHCP service for CE router,
this is applicable to both IPv4 and IPv6 addressing.
o static-address : Addresses will be assigned manually on both
sides, this is applicable to both IPv4 and IPv6 addressing.
o slaac : enables stateless address autoconfiguration ([RFC4862]).
This is applicable only for IPv6.
Litkowski, et al. Expires August 27, 2015 [Page 23]
Internet-Draft l3vpn-svc-cfg February 2015
5.2.5.2.2. Routing protocols
Routing-protocol defines which routing protocol must be activated
between the provider edge and the customer. The current model
support : bgp, rip, rip-ng, ospf, static, direct, vrrp.
Rtg protocol
10.0.0.0/24 ----- CE ----------------- PE1
If the CE is comanaged or provider managed, the management system
will be required to configure the routing protocol on both side on
the connnection.
| L3VPN SVC model
|
+------------+
+ Mgt system +
+------------+
/ \
/ \ Routing protocol config
/ \ (CLI, Netconf ...)
/ Rtg protocol \
10.0.0.0/24 ----- CE ----------------- PE1
Routing protocol config - provider managed or comanaged CE
If the CE is customer managed, the management system will be required
to configure the routing protocol only the PE router.
| L3VPN SVC model
|
+------------+
+ Mgt system +
+------------+
\
\ Routing protocol config
\ (CLI, Netconf ...)
Rtg protocol \
10.0.0.0/24 ----- CE ----------------- PE1
Routing protocol config - customer managed CE
Litkowski, et al. Expires August 27, 2015 [Page 24]
Internet-Draft l3vpn-svc-cfg February 2015
5.2.5.2.2.1. Dual stack handling
All routing protocol types support dual stack by using address-family
leaf-list.
Example of Dual stack using the same routing protocol :
<routing-protocol>
<type>static</type>
<static>
<address-family>ipv4-unicast</address-family>
<address-family>ipv6-unicast</address-family>
</static>
</routing-protocol>
Example of Dual stack using two different routing protocols :
<routing-protocol>
<type>rip</type>
<rip>
<address-family>ipv4-unicast</address-family>
</rip>
</routing-protocol>
<routing-protocol>
<type>ospf</type>
<ospf>
<address-family>ipv6-unicast</address-family>
</ospf>
</routing-protocol>
5.2.5.2.2.2. Direct LAN connection onto SP network
Routing-protocol "direct" must be used when a customer LAN is
directly connected to the provider network and must be advertised in
the IPVPN.
LAN attached directly to provider network :
10.0.0.0/24 ----- PE1
5.2.5.2.2.3. Direct LAN connection onto SP network with redundancy
Routing-protocol "vrrp" must be used when a customer LAN is directly
connected to the provider network and must be advertised in the IPVPN
and LAN redundancy is expected.
Litkowski, et al. Expires August 27, 2015 [Page 25]
Internet-Draft l3vpn-svc-cfg February 2015
LAN attached directly to provider network with LAN redundancy:
10.0.0.0/24 ------ PE1
|
+-- PE2
5.2.5.2.2.4. Static routing
Routing-protocol "static" may be used when a customer LAN is
connected to the provider network through a CE router and must be
advertised in the IPVPN.
Static rtg
10.0.0.0/24 ------ CE -------------- PE
| |
| Static route 10.0.0.0/24 nh CE
Static route 0.0.0.0/0 nh PE
5.2.5.2.2.5. RIP routing
Routing-protocol "rip" may be used when a customer LAN is connected
to the provider network through a CE router and must be advertised in
the IPVPN.
In case of dual stack, the management system will be responsible to
configure rip (including right version number) and rip-ng instances
on network elements.
RIP rtg
10.0.0.0/24 ------ CE -------------- PE
5.2.5.2.2.6. OSPF routing
Routing-protocol "ospf" may be used when a customer LAN is connected
to the provider network through a CE router and must be advertised in
the IPVPN.
It can be used to extend an existing OSPF network and interconnect
different areas. See [RFC4577] for more details.
Litkowski, et al. Expires August 27, 2015 [Page 26]
Internet-Draft l3vpn-svc-cfg February 2015
+---------------------+
| |
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 to check if
there is already a shamlink configured for this VPN and area between
the same pair of PEs. If there is no existing shamlink, the
management system will provision it, this shamlink may be reused by
other sites.
+------------------------+
| |
| |
| PE (--shamlink--)PE |
| | | |
+----|----------------|--+
| OSPF area1 | OSPF area 1
| |
CE1 CE2
| |
(OSPF area1) (OSPF area1)
| |
+----------------+
Regarding Dual stack support, user may decide to fill both IPv4 and
IPv6 address families, if both protocols should be routed through
OSPF. As OSPF is using two different protocol for IPv4 and IPv6, the
management system will need to configure both ospf version 2 and
version 3 on the PE-CE link.
Example of OSPF routing parameters in service model.
Litkowski, et al. Expires August 27, 2015 [Page 27]
Internet-Draft l3vpn-svc-cfg February 2015
<routing-protocol>
<type>ospf</type>
<ospf>
<area-address>1.1.1.1</area-address>
<address-family>ipv4-unicast</address-family>
<address-family>ipv6-unicast</address-family>
</ospf>
</routing-protocol>
Example of PE configuration done by management system :
router ospf 10
area 0.0.0.0
interface Ethernet0/0
!
router ospfv3 10
area 0.0.0.0
interface Ethernet0/0
!
5.2.5.2.2.7. BGP routing
Routing-protocol "bgp" may be used when a customer LAN is connected
to the provider network through a CE router and must be advertised in
the IPVPN.
BGP rtg
10.0.0.0/24 ------ CE -------------- PE
The AS numbers, peerings addressing will be derived from connection
parameters or customer-specific-information as well as internal
knowledge of SP.
In case of dual stack access, user may request BGP routing for both
IPv4 and IPv6 by filling both address-families. It will be up to SP
and management system to decide how to decline the configuration (two
BGP sessions, single, multisession ...).
The service configuration below actives BGP on PE-CE link for both
IPv4 and IPv6.
Litkowski, et al. Expires August 27, 2015 [Page 28]
Internet-Draft l3vpn-svc-cfg February 2015
<routing-protocol>
<type>bgp</type>
<bgp>
<address-family>ipv4-unicast</address-family>
<address-family>ipv6-unicast</address-family>
<bgp>
</routing-protocol>
This service configuration can be derived by management system into
multiple flavors depending on SP flavor.
Example #1 of PE configuration done by management system (single session IPv4 transport) :
router bgp 100
neighbor 1.0.0.2 remote-as 65000
address-family ipv4 vrf Cust1
neighbor 1.0.0.2 activate
address-family ipv6 vrf Cust1
neighbor 1.0.0.2 activate
neighbor 1.0.0.2 route-map SET-NH-IPV6 out
Example #2 of PE configuration done by management system (two sessions) :
router bgp 100
neighbor 1.0.0.2 remote-as 65000
neighbor 2001::2 remote-as 65000
address-family ipv4 vrf Cust1
neighbor 1.0.0.2 activate
address-family ipv6 vrf Cust1
neighbor 2001::2 activate
Example #3 of PE configuration done by management system (multisession) :
router bgp 100
neighbor 1.0.0.2 remote-as 65000
neighbor 1.0.0.2 multisession per-af
address-family ipv4 vrf Cust1
neighbor 1.0.0.2 activate
address-family ipv6 vrf Cust1
neighbor 1.0.0.2 activate
neighbor 1.0.0.2 route-map SET-NH-IPV6 out
5.2.6. MPLS
In case of Carrier Supporting Carrier (CsC), a customer may want to
build MPLS service using an IPVPN as transport layer.
Litkowski, et al. Expires August 27, 2015 [Page 29]
Internet-Draft l3vpn-svc-cfg February 2015
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 IPVPN service but has no transport
infrastructure between its PoPs. ISP1 uses an IPVPN as transport
infrastructure (belonging to another provider) between its PoPs. The
link between CE1_ISP1/PE1 and CE2_ISP1/PE2 must so be MPLS enabled.
In the proposed model, LDP or BGP can be used as MPLS signalling
protocol. In case of LDP, an IGP routing protocol must also be
activated. In case of BGP signalling, BGP must also be configured as
routing-protocol.
Litkowski, et al. Expires August 27, 2015 [Page 30]
Internet-Draft l3vpn-svc-cfg February 2015
5.2.7. Service
The service defines service parameters associated with the site.
5.2.7.1. QoS
The model proposes to define QoS parameters in an abstracted way :
o qos-classification-policy : define a set of ordered rules to
classify customer traffic.
o std-qos-profile : provider standard outgoing QoS profile to be
applied. This is a reference to a well known profile in Service
provider administration.
o custom-qos-profile : defines customer specific profiles.
5.2.7.1.1. QoS classification
QoS classification rules are handled by qos-classification-policy.
The qos-classification-policy is an ordered list of rules that match
a flow and set the appropriate target class of service (target-class-
id). The match criterions provide a basic infrastructure for
defining flows : layer 3 source and destination address, layer 4
ports, layer 4 protocol.
Where the classification is done depends on the SP implementation of
the service, but classification concerns the flow coming from the
customer site and entering the network.
Provider network
+-----------------------+
10.0.0.0/24
11.0.0.0/24 ---- CE --------- PE
Traffic flow
---------->
In the figure above, the management system can decide :
o if the CE is customer managed, to implement the classification
rule in the ingress direction on the PE interface.
o if the CE is provider managed, to implement the classification
rule in the ingress direction on the CE interface connected to
customer LAN.
Litkowski, et al. Expires August 27, 2015 [Page 31]
Internet-Draft l3vpn-svc-cfg February 2015
The figure below describes a sample service description of qos-
classification for a site :
<service>
<qos>
<qos-classification-policy>
<rules>
<id>1</id>
<match>
<ipv4-src-prefix>10.0.0.0/24</ipv4-src-prefix>
<ipv4-dst-prefix>1.1.1.1/32</ipv4-dst-prefix>
<l4-dst-port>80</l4-dst-port>
<l4-protocol>tcp</l4-protocol>
</match>
<target-class-id>DATA2</target-class-id>
</rules>
<rules>
<id>2</id>
<match>
<ipv4-src-prefix>10.0.0.0/24</ipv4-src-prefix>
<ipv4-dst-prefix>1.1.1.1/32</ipv4-dst-prefix>
<l4-dst-port>21</l4-dst-port>
<l4-protocol>tcp</l4-protocol>
</match>
<target-class-id>DATA2</target-class-id>
</rules>
<rules>
<id>3</id>
<target-class-id>DATA1</target-class-id>
</rules>
</qos-classification-policy>
</qos>
</service>
In the example above :
o HTTP traffic from 10.0.0.0/24 LAN destinated to 1.1.1.1/32 will be
classified in DATA2.
o FTP traffic from 10.0.0.0/24 LAN destinated to 1.1.1.1/32 will be
classified in DATA2.
o All other traffic will be classified in DATA1.
The order of rules is really important. The management system
responsible for translating those rules in network element
configuration must keep the same processing order in element
Litkowski, et al. Expires August 27, 2015 [Page 32]
Internet-Draft l3vpn-svc-cfg February 2015
configuration. The order of rule is defined by the "id" leaf. The
lowest "id" must be processed first.
5.2.7.1.2. QoS profile
std-qos-profile and custom-qos-profile define output QoS profiles to
be used between PE and CE.
Provider network
+-----------------------+
10.0.0.0/24
11.0.0.0/24 ---- CE --------- PE
\ /
qos-profile
std-qos-profile and custom-qos-profile cannot be used at the same
time. If both are present, the management system should keep only
the custom-qos-profile.
A custom-qos-profile is defined as a list of class 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.
o priority-level : used to define priorities between class of
services. The value of the priority to be used is dependant of
each administration. The higher the priority-level is, the higher
the priority of the class will be. Priority-level is used to
define strict priority queueing. A priority-level 250 class will
be served before a priority-level 100 class until there is no more
packet to process or until rate-limit does not allow anymore
packets from the higher priority class.
o guaranteed-bw-percent : used to define a guaranteed amount of
bandwidth for the class of service. It is expressed as a
percentage. The guaranteed-bw-percent uses available bandwidth at
the priority-level of the class.
Example of service configuration using a standard qos profile :
Litkowski, et al. Expires August 27, 2015 [Page 33]
Internet-Draft l3vpn-svc-cfg February 2015
<sites>
<site-id>1245HRTFGJGJ154654</site-id>
<native-vpn>VPN1</native-vpn>
<site-type>any-to-any-site</site-type>
<service>
<svc-bandwidth>100000000</svc-bandwidth>
<qos>
<std-qos-profile>PLATINUM</std-qos-profile>
</qos>
</service>
</sites>
<sites>
<site-id>555555AAAA2344</site-id>
<native-vpn>VPN1</native-vpn>
<site-type>any-to-any-site</site-type>
<service>
<svc-bandwidth>2000000</svc-bandwidth>
<qos>
<std-qos-profile>GOLD</std-qos-profile>
</qos>
</service>
</sites>
Example of service configuration using a custom qos profile :
<sites>
<site-id>Site1</site-id>
<native-vpn>VPN1</native-vpn>
<site-type>any-to-any-site</site-type>
<service>
<svc-bandwidth>100000000</svc-bandwidth>
<qos>
<custom-qos-profile>
<class>
<class-id>REAL_TIME</class-id>
<rate-limit>10</rate-limit>
<priority-level>10</priority-level>
</class>
<class>
<class-id>DATA</class-id>
<priority-level>5</priority-level>
</class>
</custom-qos-profile>
</qos>
</service>
</sites>
<sites>
Litkowski, et al. Expires August 27, 2015 [Page 34]
Internet-Draft l3vpn-svc-cfg February 2015
<site-id>Site2</site-id>
<native-vpn>VPN1</native-vpn>
<site-type>any-to-any-site</site-type>
<service>
<svc-bandwidth>2000000</svc-bandwidth>
<qos>
<custom-qos-profile>
<class>
<class-id>REAL_TIME</class-id>
<rate-limit>30</rate-limit>
<priority-level>10</priority-level>
</class>
<class>
<class-id>DATA1</class-id>
<priority-level>5</priority-level>
<guaranteed-bw-percent>80</guaranteed-bw-percent>
</class>
<class>
<class-id>DATA2</class-id>
<priority-level>5</priority-level>
<guaranteed-bw-percent>20</guaranteed-bw-percent>
</class>
</custom-qos-profile>
</qos>
</service>
</sites>
The custom-qos-profile for site1 defines that traffic from REAL_TIME
class will have a higher priority than traffic from DATA class. The
REAL_TIME traffic will be rate-limit to 10% of the service bandwidth
(10% of 100Mbps = 10Mbps) to let some place for DATA traffic.
The custom-qos-profile for site2 defines that traffic from REAL_TIME
class will have a higher priority than traffic from data traffic.
Data traffic will be splitted in two class of service DATA1 and DATA2
that will share bandwidth between them according to the percentage of
guaranteed-bw-percent. The maximum of 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 service provider. The
REAL_TIME traffic will be rate-limit to 30% of the service bandwidth
(30% of 100Mbps = 30Mbps) to let some place for data traffic. In
case of congestion of the access, the REAL_TIME traffic can go up to
30Mbps (Let's assume that 20Mbps only are consumed). The DATA1 and
DATA2 will share remaining bandwidth (80Mbps) according to their
percentage. So DATA1 will be served with at least 64Mbps of
bandwidth.
Litkowski, et al. Expires August 27, 2015 [Page 35]
Internet-Draft l3vpn-svc-cfg February 2015
5.2.7.2. Multicast
The multicast section defines the type of site in the customer
multicast topology : source, receiver, or both. These parameters
will help management system to optimize the multicast service.
5.2.7.3. Traffic protection
The service model supports the ability to protect traffic from or to
a site.
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 IPVPN service with three sites
including two dual homed sites (site #1 and #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 loadsharing scenarios.)
In order to protect Site#2 for a PE-CE link failure, a service
provider may configure link-local-protection on the primary access of
site#2 (PE3-CE3). In such case, if we consider traffic coming from a
remote site (site #1 or site#3), primary path is to use PE3 as egress
PE. PE3 has preprogrammed a backup forwarding entry pointing to
backup path (through PE4-CE4) for all prefixes going through PE3-CE3
link. How backup path is computed is out of scope of the document.
When PE3-CE3 link fails, traffic is still received by PE3 but PE3
switch automatically traffic to the backup entry, path will so be
PE1-P1-(...)-P3-PE3-PE4-CE4 until remote PEs reconverge and use PE4
as egress PE.
In order to protect Site#2 for a egress PE node failure, a service
provider may configure node-local-protection on the primary access of
site#2 (PE3-CE3). This protection flavor is so called egress PE node
protection. In such case, if we consider traffic coming from a
remote site (site #1 or site#3), primary path is to use PE3 as egress
PE. P3 has preprogrammed a backup forwarding entry pointing to
Litkowski, et al. Expires August 27, 2015 [Page 36]
Internet-Draft l3vpn-svc-cfg February 2015
backup path. How backup path is computed is out of scope of the
document. When PE3 node fails, traffic is still received by P3 but
P3 switch automatically traffic to the backup entry, path will so be
PE1-P1-(...)-P3-P4-PE4-CE4 until remote PEs reconverge and use PE4 as
egress PE.
In order to protect Site#2 for a egress PE node failure, another
flavor of protection can be used, a service provider may configure
node-global-protection on all remote sites. This protection flavor
is generally called PIC Edge (Prefix Independent Convergence for
Edge). In such case, if we consider traffic coming from a remote
site (site #1 or site#3), primary path is to use PE3 as egress PE.
All remote PEs (PE1,PE2) have preprogrammed a backup forwarding entry
pointing to backup path (through PE4). How backup path is computed
is out of scope of the document. When PE3 node fails, remote PEs
detect through IGP convergence that PE3 is no more reachable and
decide to switch automatically traffic to the backup entry, path will
so be PE1-P1-(...)-P4-PE4-CE4. In this case, as BGP convergence is
involved, there is no other need of reconvergence.
5.2.8. Customer specific information
Customer specific informations are used to store informations owned
by customers. The customer may have some LANs directly connected to
CE routers managed by Service providers. In this case, customer
needs to allocate IP addresses from its LAN addressing plan for the
CE router. This is the purpose of the customer-lan-connection list
which provides information about addresses allocated from each
customer LAN connected to the CE router.
In case, provider needs to route some LAN that are cascaded behind
those connected LANs, cascaded-lan-prefixes can be used. In this
version of the document, static routing is assumed between CE and
customer LANs.
5.2.8.1. Customer cascaded LANs with provider managed CE
10.0.0.0/24 ---- CustFW1 ---- 1.0.0.0/24 --- CE1 ----- PE1
/
10.0.1.0/24 ----
In the example above, CE1 owned by service provider is attached to
1.0.0.0/24 LAN of the customer. Customer allocated 10.0.0.254 for
CE1, this information will have to be reported as a customer-lan-
connection in the service model. Customer also have two LANs
cascaded behind a firewall (10.0.0.0/24 and 10.0.1.0/24), those LANs
Litkowski, et al. Expires August 27, 2015 [Page 37]
Internet-Draft l3vpn-svc-cfg February 2015
must be routed within the IPVPN. cascaded-lan-prefixes must be used
to fill those informations. The IP address of the firewall must be
filled as nexthop of those LANs.
5.2.8.2. Customer LANs with provider managed CE
10.0.0.0/24 ---- CE1 ----- PE1
/
10.0.1.0/24 ----
In the example above, CE1 owned by service provider is attached to
1.0.0.0/24 LAN of the customer. Customer allocated 10.0.0.254 and
10.0.1.254 for CE1, this information will have to be reported as a
customer-lan-connection in the service model.
5.2.8.3. Customer LANs with customer managed CE
10.0.0.0/24 ---- CE1 ----- PE1
/
10.0.1.0/24 ----
In the example above, CE1 owned by customer is attached to 1.0.0.0/24
LAN. The service provider only have to deal with routing with
customer CE, the routing-protocol information on the connection will
define this.
5.3. Using configuration templates
The proposed model supports the creation and application of
configuration templates for sites.
A template can be configured by creating a new site with the template
leaf equal to true. This means that the site is not a real site and
its just a configuration template.
Multiple template sites can be configured. Templates can be applied
at multiple levels referenced by apply-template leaf. The apply-
template references the site-id of the template to be called. The
location of the apply-template within the sites hierarchy defines
which parameters must be inherited. For example, if apply-template
is done on service container of a site, only service container
parameters (and childs) from the template will be applied.
Apply-template cannot be used within a template.
<sites>
Litkowski, et al. Expires August 27, 2015 [Page 38]
Internet-Draft l3vpn-svc-cfg February 2015
<site-id>Template-VoiceCoS-Cust1</site-id>
<template>true</template>
<service>
<qos>
<custom-qos-profile>
<class>
<class-id>REAL_TIME</class-id>
<rate-limit>30</rate-limit>
<priority-level>10</priority-level>
</class>
<class>
<class-id>DATA1</class-id>
<priority-level>5</priority-level>
<guaranteed-bw-percent>80</guaranteed-bw-percent>
</class>
<class>
<class-id>DATA2</class-id>
<priority-level>5</priority-level>
<guaranteed-bw-percent>20</guaranteed-bw-percent>
</class>
</custom-qos-profile>
</qos>
</service>
</sites>
<sites>
<site-id>Template-VPNsite-Customer1</site-id>
<native-vpn>VPN1</native-vpn>
<site-type>any-to-any-site</site-type>
<template>true</template>
<service>
<qos>
<std-qos-profile>PLATINUM</std-qos-profile>
</qos>
</service>
<attachment>
<connection>
<routing-protocol>
<name>static</name>
<type>static</type>
</routing-protocol>
</connection>
</attachment>
<vpn-policy>
<import-policy>
<vpn>Service_VPN1</vpn>
</import-policy>
Litkowski, et al. Expires August 27, 2015 [Page 39]
Internet-Draft l3vpn-svc-cfg February 2015
<export-policy>
<entries>
<lan-tag>VOICE</lan-tag>
<vpn>Service_VPN1</vpn>
</entries>
</export-policy>
</vpn-policy>
</sites>
Template sites permit to define configuration blocks that will be
inherited by one or multiple sites in order to speed up
configuration. For example, if all the sites of an IPVPN service
have the almost same configuration (routing-protocol, qos, management
...), a template can be created and each site of the VPN will
reference the template. If a site has some particular parameters,
specific parameters within the site must always override parameters
derived from template.
The example above defines two site templates :
o Template-VPNsite-Customer1 that will be used to configure all the
VPN sites for customer 1.
o Template-VoiceCoS-Cust1 that will be used to configure some
special CoS policy on some specific accesses of the VPN.
In the example below, all sites of VPN1 are inheriting basic
configuration from template Template-VPNsite-Customer1. Some
specific parameters like svc-bandwidth are also defined for each
site. For Site 4 and 5 , specific QoS parameters are required, a new
template Template-VoiceCoS-Cust1 is applied at service level for
these two sites, overriding the service parameters from the Template-
VPNsite-Customer1 template.
Litkowski, et al. Expires August 27, 2015 [Page 40]
Internet-Draft l3vpn-svc-cfg February 2015
<sites>
<site-id>Site1</site-id>
<apply-template>Template-VPNsite-Customer1</apply-template>
<service>
<svc-bandwidth>5000000</svc-bandwidth>
</service>
</sites>
<sites>
<site-id>Site2</site-id>
<apply-template>Template-VPNsite-Customer1</apply-template>
<service>
<svc-bandwidth>20000000</svc-bandwidth>
</service>
</sites>
<sites>
<site-id>Site3</site-id>
<apply-template>Template-VPNsite-Customer1</apply-template>
<service>
<svc-bandwidth>30000000</svc-bandwidth>
</service>
</sites>
<sites>
<site-id>Site4</site-id>
<apply-template>Template-VPNsite-Customer1</apply-template>
<service>
<apply-template>Template-VoiceCoS-Cust1</apply-template>
<svc-bandwidth>100000000</svc-bandwidth>
</service>
</sites>
<sites>
<site-id>Site5</site-id>
<apply-template>Template-VPNsite-Customer1</apply-template>
<service>
<apply-template>Template-VoiceCoS-Cust1</apply-template>
<svc-bandwidth>450000000</svc-bandwidth>
</service>
</sites>
6. Service model usage example
As explained in Section 4, 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.
Litkowski, et al. Expires August 27, 2015 [Page 41]
Internet-Draft l3vpn-svc-cfg February 2015
This section provides an example on how a management system can use
this model to configure an IPVPN service on network elements.
The example wants to achieve the provisionning of a VPN service for 3
sites using hub and spoke topology. One of the site will be dual
homed and loadsharing is expected.
+-------------------------------------------------------------+
| Hub_Site ------ PE1 PE2 ------ Spoke_Site1 |
| | +----------------------------------+
| | |
| | +----------------------------------+
| Hub_Site ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+
The following XML describes the overall simplified service
configuration of this VPN.
<vpn-svc>
<name>VPN1</name>
<id>12456487</id>
<customer-name>CUSTOMER1</customer-name>
<topology>hub-spoke</topology>
</vpn-svc>
When receiving the request for provisionning the VPN service, the
management system will internally (or through discussion with other
OSS component) allocates VPN route-targets. In this specific case
two RTs will be allocated (100:1 for Hub and 100:2 for Spoke). The
output below describes the configuration of Spoke1.
<sites>
<site-id>Spoke_Site1</site-id>
<native-vpn>VPN1</native-vpn>
<site-type>spoke-site</site-type>
<site-diversity>
<type>pe-diverse</type>
<site-group>100</site-group>
</site-diversity>
<location>
<city-code>NY</city-code>
<country-code>US</country-code>
</location>
<attachment>
<connection>
<ipv4>
<subnet-prefix>1.0.0.0/30</subnet-prefix>
</ipv4>
Litkowski, et al. Expires August 27, 2015 [Page 42]
Internet-Draft l3vpn-svc-cfg February 2015
<routing-protocol>
<type>bgp</type>
<bgp>
<address-family>ipv4-unicast</address-family>
</bgp>
</routing-protocol>
</connection>
</attachment>
<management>
<type>provider-managed</type>
<management-transport>ipv4-unicast</management-transport>
<address>10.46.1.1</address>
</management>
<service>
<svc-bandwidth>450000000</svc-bandwidth>
</service>
<customer-specific-information>
<customer-lan-connection>
<address>44.10.0.254</address>
<lan-protocol>ipv4-unicast</lan-protocol>
</customer-lan-connection>
<cascaded-lan-prefixes>
<ipv4-lan-prefixes>
<lan>44.10.5.0/24</lan>
<nexthop>44.10.0.253</nexthop>
</ipv4-lan-prefixes>
<ipv4-lan-prefixes>
<lan>44.10.6.0/24</lan>
<nexthop>44.10.0.253</nexthop>
</ipv4-lan-prefixes>
<ipv4-lan-prefixes>
<lan>44.10.7.0/24</lan>
<nexthop>44.10.0.253</nexthop>
</ipv4-lan-prefixes>
</cascaded-lan-prefixes>
</customer-specific-information>
</sites>
When receiving the request for provisionning Spoke1 site, the
management system must allocate network ressources for this site. It
must first decide the target network elements to provision the
access, and especially the PE router (and may be an aggregation
switch). As described in Section 5.2.1, the management system may
use the location information and must use the site-diversity
constraint to find the appropriate PE. In this case, we consider
Spoke1 requires PE diversity with Hub and that management system
allocate PEs based on lowest distance. Based on the location
information, the management system finds the available PEs in the
Litkowski, et al. Expires August 27, 2015 [Page 43]
Internet-Draft l3vpn-svc-cfg February 2015
nearest area of the customer and picks one that fits the site-
diversity constraint.
When the PE is chosen, management system needs to allocate interface
ressources on the node, one interface is so picked from the PE
available pool. The management system can start provisionning the PE
node by using any mean (Netconf, CLI, ...). The management system
will check if a VRF is already present that fits the needs. If not,
it will provision the VRF : Route distinguisher will come from
internal allocation policy model, route-targets are coming from the
native-vpn configuration of the site (management system allocated
some RTs for the VPN). As the site is a spoke site (site-type), the
management system knows which RT must be imported and exported. As
the site is provider managed, some management route-targets 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 for provider managed
route-target export 100:2
!
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 derived from the subnet-prefix of the
connection. One address will be picked from the subnet for the PE,
another will be used for the CE configuration. Routing protocols
will also be configured on the PE, bgp will be used as requested in
the service model. Peering addresses will be derived from subnet-
prefix. PE AS number is well known and as CE is provider managed, CE
AS number can be automatically allocated by the management system.
Some provider standard configuration templates may also be added.
Litkowski, et al. Expires August 27, 2015 [Page 44]
Internet-Draft l3vpn-svc-cfg February 2015
Example of generated PE configuration :
interface Ethernet1/1/0.10
encapsulation dot1q 10
ip vrf forwarding Customer1
ip address 1.0.0.1 255.255.255.252 <---- Comes from subnet-prefix
ip access-group STD-PROTECT-IN <---- Standard SP configuration
!
router bgp 100
address-family ipv4 vrf Customer1
neighbor 1.0.0.2 remote-as 65000 <---- Comes from subnet-prefix
and allocated CE ASN
neighbor 1.0.0.2 route-map STD in <---- Standard SP configuration
neighbor 1.0.0.2 filter-list 10 in <---- Standard SP configuration
!
ip route vrf Customer1 10.46.1.1 255.255.255.255 1.0.0.2 tag 50
! 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 uploaded
to the node by manual operation before sending the CE to customer
premise. The CE configuration will be built as for the PE. Based on
the CE type (vendor/model) allocated to the customer and bearer
information, the management system knows which interface must be
configured on the CE. Interface parameters like IP addressing are
derived from subnet-prefix taking into account how management system
distributes addresses between PE and CE within the subnet. Routing
protocol configuration is done as for the PE, in this example, bgp
peering address is retrieved from subnet prefix and internal
allocation policy, remote AS number is well known. LAN addresses
will be added to the configuration and exported to BGP. This will
permit to produce a plug'n'play configuration for the CE.
Litkowski, et al. Expires August 27, 2015 [Page 45]
Internet-Draft l3vpn-svc-cfg February 2015
Example of generated CE configuration :
interface Loopback10
description "Administration"
ip address 10.46.1.1 255.255.255.255
!
interface FastEthernet10
description "WAN"
ip address 1.0.0.2 255.255.255.252 <---- Comes from subnet-prefix
!
interface FastEthernet11
description "LAN"
ip address 44.10.0.254 255.255.255.252 <---- Comes from
customer-lan-connection
!
router bgp 65000
redistribute static route-map STATIC2BGP <---- Standard SP
configuration
neighbor 1.0.0.1 remote-as 100 <---- Comes from subnet-prefix
and allocated CE ASN
!
route-map STATIC2BGP permit 10
match tag 10
!
ip route 44.10.5.0 255.255.255.0 44.10.0.253 tag 10
ip route 44.10.6.0 255.255.255.0 44.10.0.253 tag 10
ip route 44.10.7.0 255.255.255.0 44.10.0.253 tag 10
7. Interaction with Other YANG Modules
As expressed in Section 4, this service module is intended to be
instantiated in management system and not directly on network
elements.
It will be the role of the management system to configure the network
elements. The management system may be modularized, 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.
Litkowski, et al. Expires August 27, 2015 [Page 46]
Internet-Draft l3vpn-svc-cfg February 2015
L3VPN-SVC |
service model |
|
+----------------------+
| Service component | service datastore
+----------------------+
|
|
+----------------------+
+----| Config component |-------+
/ +----------------------+ \ Network
/ / \ \ Configuration models
/ / \ \
/ / \ \
+++++++ ++++++++ ++++++++ +++++++
+ CEA + ------- + PE A + + PE B + ----- + CEB + Configuration
+++++++ ++++++++ ++++++++ +++++++ datastore
Site A Site B
In the previous sections, we provided some example of translation of
service provisioning request to router configuration lines as
illustration. In the NetConf/Yang ecosystem, it will be expected
NetConf/YANG to be used between configuration component and network
elements to configure the requested service on these elements.
In this framework, it is expected from standardization to also work
on specific configuration YANG modelization of service components on
network elements. There will be so a strong relation 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.
Authors of this document are expecting definition of YANG models for
network elements on this non exhaustive list of items :
o VRF definition including VPN policy expression.
o Physical interface.
o IP layer (IPv4, IPv6).
o QoS : classification, profiles...
o Routing protocols : support of configuration of all protocols
listed in the document, as well as routing policies associated
with these protocols.
Litkowski, et al. Expires August 27, 2015 [Page 47]
Internet-Draft l3vpn-svc-cfg February 2015
o Multicast VPN.
o Network Address Translation.
o ...
Example of VPN site request at service level using this model :
<sites>
<site-id>Site A</site-id>
<native-vpn>VPN1</native-vpn>
<site-type>any-to-any-site</site-type>
<attachment>
<connection>
<ipv4>
<address-allocation-type>static-address</address-allocation-type>
<subnet-prefix>1.0.0.0/30</subnet-prefix>
</ipv4>
<routing-protocol>
<name>static</name>
<type>static</type>
</routing-protocol>
</connection>
</attachment>
<customer-specific-information>
<cascaded-lan-prefixes>
<ipv4-lan-prefixes>
<lan>44.10.5.0/24</lan>
<nexthop>44.10.0.253</nexthop>
</ipv4-lan-prefixes>
</cascaded-lan-prefixes>
</customer-specific-information>
</sites>
In the service example above, it is expected that the service
component requests to the configuration component of the management
system the configuration of the service elements. If we consider
that service component selected a PE (PE A) as 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
configuration of PE-A may look like this :
Litkowski, et al. Expires August 27, 2015 [Page 48]
Internet-Draft l3vpn-svc-cfg February 2015
<if:interfaces>
<if:interface>
<if:name>eth0</if:name>
<if:type>ianaift:ethernetCsmacd</if:type>
<if:description>
Link to CEA.
</if:description>
<ip:ipv4>
<ip:address>
<ip:ip>1.0.0.1</ip:ip>
<ip:prefix-length>30</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:vrf</rt:type>
<rt:description>VRF for CustomerA</rt:description>
<l3vpn:route-distinguisher>100:1546542343</l3vpn:route-distinguisher>
<l3vpn:import-rt>100:1</l3vpn:import-rt>
<l3vpn:export-rt>100:1</l3vpn:export-rt>
<rt:interfaces>
<rt:interface>
<rt:name>eth0</rt:name>
</rt:interface>
</rt:interfaces>
<rt:routing-protocols>
<rt:routing-protocol>
<rt:type>rt:static</rt:type>
<rt:name>st0</rt:name>
<rt:static-routes>
<v4ur:ipv4>
<v4ur:route>
<v4ur:destination-prefix>44.10.5.0/24</v4ur:destination-prefix>
<v4ur:next-hop>
<v4ur:next-hop-address>1.0.0.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>
Litkowski, et al. Expires August 27, 2015 [Page 49]
Internet-Draft l3vpn-svc-cfg February 2015
8. YANG Module
<CODE BEGINS> file "ietf-l3vpn-svc@2015-02-18.yang"
module ietf-l3vpn-svc {
namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
prefix l3vpn-svc;
import ietf-routing {
prefix "rt";
}
import ietf-inet-types {
prefix inet;
}
import ietf-yang-types {
prefix yang;
}
organization
"IETF xxx Working Group";
contact
"WG List: <mailto:@ietf.org>
Editor:
";
description
"The YANG module defines a generic service configuration model for
Layer 3 VPN common across all of the vendor implementations.";
revision 2015-02-05 {
description "Initial revision.";
reference "draft-...";
}
identity management {
description
"Base identity for site management scheme.";
}
identity comanaged {
base management;
description
Litkowski, et al. Expires August 27, 2015 [Page 50]
Internet-Draft l3vpn-svc-cfg February 2015
"Base identity for comanaged 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 pe-dhcp {
base address-allocation-type;
description
"PE router provides DHCP service to CE.";
}
identity static-address {
base address-allocation-type;
description
"PE-CE addressing is static.";
}
identity slaac {
base address-allocation-type;
description
"Use IPv6 SLAAC.";
}
identity site-availability {
description
"Base identity for site availability.";
}
identity loadsharing {
base site-availability;
description
"Identity for loadsharing site.";
}
identity loadsharing-ibgp {
base loadsharing;
description
"Identity for ECMP ibgp based loadsharing site.";
}
Litkowski, et al. Expires August 27, 2015 [Page 51]
Internet-Draft l3vpn-svc-cfg February 2015
identity loadsharing-eibgp {
base loadsharing;
description
"Identity for ECMP eibgp based loadsharing site.";
}
identity primary-backup {
base site-availability;
description
"Identity for primary-backup site.";
}
identity single {
base site-availability;
description
"Identity for single site.";
}
identity access-availability-type {
description
"base identity for access-availability-type";
}
identity primary-access {
base access-availability-type;
description
"Identity for primary access type.";
}
identity backup-access {
base access-availability-type;
description
"Identity for backup access type.";
}
identity single-access {
base access-availability-type;
description
"Identity for single access type.";
}
identity loadsharing-access {
base access-availability-type;
description
"Identity for loadsharing access type.";
}
identity site-type {
description
"Base identity for site type.";
}
identity any-to-any-site {
base site-type;
description
Litkowski, et al. Expires August 27, 2015 [Page 52]
Internet-Draft l3vpn-svc-cfg February 2015
"Site in a any to any IPVPN.";
}
identity spoke-site {
base site-type;
description
"Spoke Site in a Hub & Spoke IPVPN.";
}
identity hub-site {
base site-type;
description
"Hub Site in a Hub & Spoke IPVPN.";
}
identity vpn-topology {
description
"Base identity for VPN topology.";
}
identity any-to-any {
base vpn-topology;
description
"Identity for any to any VPN topology.";
}
identity hub-spoke {
base vpn-topology;
description
"Identity for Hub'n'Spoke VPN topology.";
}
identity hub-spoke-disjoint {
base vpn-topology;
description
"Identity for Hub'n'Spoke VPN topology
where Hubs cannot talk between 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
Litkowski, et al. Expires August 27, 2015 [Page 53]
Internet-Draft l3vpn-svc-cfg February 2015
"Identity for ASM tree type.";
}
identity bidir-tree-type {
base multicast-tree-type;
description
"Identity for BiDir 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 anycast-rp {
base multicast-rp-discovery-type;
description
"Base identity for anycast rp type.";
}
identity bsr-rp {
base multicast-rp-discovery-type;
description
"Base identity for BDR discovery type.";
}
identity routing-protocol-type {
description
"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.";
Litkowski, et al. Expires August 27, 2015 [Page 54]
Internet-Draft l3vpn-svc-cfg February 2015
}
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 rip-ng {
base routing-protocol-type;
description
"Identity for RIPng protocol type.";
}
identity vrrp {
base routing-protocol-type;
description
"Identity for VRRP protocol type.
This is to be used when LAn are directly connected
to provider Edge routers.";
}
identity direct {
base routing-protocol-type;
description
"Identity for direct protocol type.
.";
}
identity l4-protocol-type {
description
"Base identity for Layer 4 protocol type.";
}
identity tcp {
base l4-protocol-type;
description
"TCP protocol type.";
}
identity udp {
base l4-protocol-type;
description
Litkowski, et al. Expires August 27, 2015 [Page 55]
Internet-Draft l3vpn-svc-cfg February 2015
"UDP protocol type.";
}
identity icmp {
base l4-protocol-type;
description
"icmp protocol type.";
}
identity icmp6 {
base l4-protocol-type;
description
"icmp v6 protocol type.";
}
identity gre {
base l4-protocol-type;
description
"GRE protocol type.";
}
identity ipip {
base l4-protocol-type;
description
"IPinIP protocol type.";
}
identity hop-by-hop {
base l4-protocol-type;
description
"Hop by Hop IPv6 header type.";
}
identity routing {
base l4-protocol-type;
description
"Routing IPv6 header type.";
}
identity esp {
base l4-protocol-type;
description
"ESP header type.";
}
identity ah {
base l4-protocol-type;
description
"AH header type.";
}
container l3vpn-svc {
list vpn-svc {
key name;
Litkowski, et al. Expires August 27, 2015 [Page 56]
Internet-Draft l3vpn-svc-cfg February 2015
leaf name {
type string;
description
"Name of the VPN.";
}
leaf id {
type uint32;
description
"VPN identifier. Local administration meaning.";
}
leaf customer-name {
type string;
description
"Name of the customer.";
}
leaf topology {
type identityref {
base vpn-topology;
}
description
"VPN topology.";
}
list cloud-access {
key cloud-identifier;
leaf cloud-identifier {
type string;
description
"Identification of cloud service. Local
admin meaning.";
}
list authorized-sites {
key site-id;
leaf site-id {
type leafref {
path "../../../../sites/site-id";
}
description
"Site ID.";
}
description
"List of authorized sites.";
}
list denied-sites {
key site-id;
Litkowski, et al. Expires August 27, 2015 [Page 57]
Internet-Draft l3vpn-svc-cfg February 2015
leaf site-id {
type leafref {
path "../../../../sites/site-id";
}
description
"Site ID.";
}
description
"List of denied sites.";
}
leaf nat-enabled {
type boolean;
description
"Control if NAT is required or not.";
}
leaf customer-nat-address {
type inet:ipv4-address;
description
"NAT address to be used in case of public or shared cloud.
This is to be used in case customer is providing the public address.";
}
description
"Cloud access configuration.";
}
container multicast {
leaf-list tree-flavor {
type identityref {
base multicast-tree-type;
}
description
"Type of tree to be used.";
}
container rp {
leaf ipv4-address {
type inet:ipv4-address;
description
"Management address";
}
leaf ipv6-address {
type inet:ipv6-address;
description
"Management address";
}
description
"Defines the address of the RendezvousPoint.";
}
leaf rp-discovery {
Litkowski, et al. Expires August 27, 2015 [Page 58]
Internet-Draft l3vpn-svc-cfg February 2015
type identityref {
base multicast-rp-discovery-type;
}
description
"Type of RP discovery used.";
}
leaf-list anycast-rp-location {
type string;
description
"Encodes the location of the RPs in anycast RP
deployment.";
}
description
"Multicast global parameters for the VPN service.";
}
description "
List of VPN services.
";
}
list sites {
key site-id;
leaf template {
type boolean;
default false;
description
"Defines if the site is a real site,
or a configuration template.";
}
leaf site-id {
type string;
description
"Identifier of the site.";
}
leaf native-vpn {
type leafref {
path "../../vpn-svc/name";
}
description
"Reference to associated VPN.";
}
leaf site-type {
Litkowski, et al. Expires August 27, 2015 [Page 59]
Internet-Draft l3vpn-svc-cfg February 2015
type identityref {
base site-type;
}
description
"Type of site.";
}
leaf apply-template {
type leafref {
path "../../sites/site-id";
}
description
"It we would be good to ensure that site-id is template type";
}
container location {
leaf city-code {
type string;
description
"City of the site.";
}
leaf country-code {
type string;
description
"Country of the site.";
}
description
"Location of the site.";
}
container site-diversity {
leaf type {
type enumeration {
enum "pop-diverse" {
description
"The access must use another PoP compared
to other accesses in the same group.";
}
enum "pe-diverse" {
description
"The access must use another PE compared
to other accesses in the same group.";
}
}
description
"Diversity constraint type.";
}
Litkowski, et al. Expires August 27, 2015 [Page 60]
Internet-Draft l3vpn-svc-cfg February 2015
leaf-list site-group {
type uint32;
description
"IDs of group.";
}
description
"Diversity constraint type.";
}
container security {
leaf apply-template {
type leafref {
path "../../../sites/site-id";
}
description
"It we would be good to ensure that site-id is template type";
}
container authentication {
description
"Authentication parameters";
}
container encryption {
description
"Encryption parameters.";
}
container access-control-list {
description
"Access control list.";
}
description
"Site specific security parameters.";
}
container availability {
container availability-type {
leaf service-type {
type identityref {
base site-availability;
}
description
"Type of availability, ex : single, backup, loadsharing";
}
leaf access-type {
type identityref {
base access-availability-type;
}
description
"Access type within the service.";
Litkowski, et al. Expires August 27, 2015 [Page 61]
Internet-Draft l3vpn-svc-cfg February 2015
}
description
"Availability solution parameters";
}
leaf loadsharing-type {
type identityref {
base loadsharing;
}
description
"Loadsharing flavor.";
}
description
"Site availability parameters.";
}
container attachment {
leaf apply-template {
type leafref {
path "../../../sites/site-id";
}
description
"It we would be good to ensure that site-id is
template type";
}
container bearer {
leaf type {
type string;
description
"Type of bearer Ethernet, DSL, Wireless ...
Operator specific.";
}
leaf bearer-reference {
type string;
description
"This is an internal reference for the service
provider.";
}
description
"Bearer specific parameters. To be augmented.";
}
container connection {
container ipv4 {
leaf address-allocation-type {
type identityref {
base address-allocation-type;
}
description
"Defines how addresses are allocated.
Need to be detailed further.";
Litkowski, et al. Expires August 27, 2015 [Page 62]
Internet-Draft l3vpn-svc-cfg February 2015
}
leaf subnet-prefix {
type inet:ipv4-prefix;
description
"Interco subnet.";
}
description
"IPv4 specific parameters";
}
container ipv6 {
leaf address-allocation-type {
type string;
description
"Defines how addresses are allocated.
Need to be detailled further.";
}
leaf subnet-prefix {
type inet:ipv6-prefix;
description
"Interco subnet.";
}
description
"IPv6 specific parameters";
}
list routing-protocols {
key type;
leaf type {
type identityref {
base routing-protocol-type;
}
description
"Type of routing protocol.";
}
container ospf {
when "type = 'ospf'" {
description
"Only applies when protocol is OSPF.";
}
leaf-list address-family {
type identityref {
base rt:address-family;
}
description
Litkowski, et al. Expires August 27, 2015 [Page 63]
Internet-Draft l3vpn-svc-cfg February 2015
"Address family to be activated.";
}
leaf area-address {
type yang:dotted-quad;
description
"Area address.";
}
leaf metric {
type uint16;
description
"Metric of PE-CE link.";
}
list sham-link {
key target-site;
leaf target-site {
type leafref {
path "../../../../../../../sites/site-id";
}
description
"Target site for the sham link
connection.";
}
leaf metric {
type uint16;
description
"Metric of the sham link.";
}
description
"Creates a shamlink with another site";
}
description
"OSPF specific configuration.";
}
container bgp {
when "type = 'bgp'" {
description
"Only applies when protocol is BGP.";
}
leaf-list address-family {
type identityref {
base rt:address-family;
}
description
"Address family to be activated.";
}
description
Litkowski, et al. Expires August 27, 2015 [Page 64]
Internet-Draft l3vpn-svc-cfg February 2015
"BGP specific configuration.";
}
container static {
when "type = 'static'" {
description
"Only applies when protocol is static.";
}
leaf-list address-family {
type identityref {
base rt:address-family;
}
description
"Address family to be activated.";
}
description
"Static routing specific configuration.";
}
container rip {
when "type = 'rip'" {
description
"Only applies when protocol is RIP.";
}
leaf-list address-family {
type identityref {
base rt:address-family;
}
description
"Address family to be activated.";
}
description
"RIP routing specific configuration.";
}
container vrrp {
when "type = 'vrrp'" {
description
"Only applies when protocol is VRRP.";
}
leaf-list address-family {
type identityref {
base rt:address-family;
}
description
"Address family to be activated.";
}
description
Litkowski, et al. Expires August 27, 2015 [Page 65]
Internet-Draft l3vpn-svc-cfg February 2015
"VRRP routing specific configuration.";
}
leaf bfd-enabled {
type boolean;
description
"BFD activation";
}
description
"List of routing protocols used on the site. Need to be augmented.";
}
description
"Defines connection parameters.";
}
description
"Parameters of the attachement.";
}
container service {
leaf apply-template {
type leafref {
path "../../../sites/site-id";
}
description
"It we would be good to ensure that site-id is
template type";
}
container qos {
container qos-classification-policy {
list rules {
key id;
leaf id {
type uint16;
description
"ID of the rule.";
}
container match {
leaf ipv4-src-prefix {
type inet:ipv4-prefix;
description
"Match on IPv4 src address.";
}
leaf ipv6-src-prefix {
type inet:ipv6-prefix;
description
Litkowski, et al. Expires August 27, 2015 [Page 66]
Internet-Draft l3vpn-svc-cfg February 2015
"Match on IPv6 src address.";
}
leaf ipv4-dst-prefix {
type inet:ipv4-prefix;
description
"Match on IPv4 dst address.";
}
leaf ipv6-dst-prefix {
type inet:ipv6-prefix;
description
"Match on IPv6 dst address.";
}
leaf l4-src-port {
type uint16;
description
"Match on layer 4 src port.";
}
leaf l4-dst-port {
type uint16;
description
"Match on layer 4 dst port.";
}
leaf l4-protocol {
type union {
type uint8;
type identityref {
base l4-protocol-type;
}
}
description
"Match on IPv4 protocol field or IPv6 nextheader field.";
}
description
"Describe flow matching criterions.";
}
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
"Need to express marking rules ...";
Litkowski, et al. Expires August 27, 2015 [Page 67]
Internet-Draft l3vpn-svc-cfg February 2015
}
leaf std-qos-profile {
type string;
description
"QoS profile to be used";
}
container custom-qos-profile {
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 class must be rate limited. Expressed as
percentage of the svc-bw.";
}
leaf priority-level {
type uint8;
description
"Defines the level of the class in term of priority queueing.
The higher the level is the higher is the priority.";
}
leaf guaranteed-bw-percent {
type uint8;
units percent;
description
"To be used to define the guaranteed BW in percent of the svc-bw
available at the priority-level.";
}
description
"List of class of services.";
}
description
"Custom qos profile.";
}
description
"QoS configuration.";
}
leaf svc-bandwidth {
type uint32;
Litkowski, et al. Expires August 27, 2015 [Page 68]
Internet-Draft l3vpn-svc-cfg February 2015
units bps;
description
"Service bandwidth of the connection.";
}
leaf svc-mtu {
type uint16;
units bytes;
description
"MTU at service level.";
}
container traffic-protection {
leaf link-local-protection {
type boolean;
description
"Enables protection of PE-CE link.";
}
leaf node-local-protection {
type boolean;
description
"Enables protection against local PE node failure.";
}
leaf node-global-protection {
type boolean;
description
"Enables protection against remote PE node failure.
This is also called PIC Edge.
";
}
description
"Fast reroute service parameters for the site.";
}
container mpls {
leaf signalling-type {
type enumeration {
enum "ldp" {
description
"Use LDP as signalling
protocol between PE and CE.";
}
enum "bgp" {
description
"Use BGP 3107 as signalling
protocol between PE and CE.
In this case, bgp must be also configured
as routing-protocol.
";
}
Litkowski, et al. Expires August 27, 2015 [Page 69]
Internet-Draft l3vpn-svc-cfg February 2015
}
description
"MPLS signalling type.";
}
description
"This container is used when customer provides MPLS based services.
This is used in case of Carrier Supporting Carrier.";
}
container multicast {
leaf site-type {
type enumeration {
enum receiver-only {
description
"The site has only receivers.";
}
enum source-only {
description
"The site has only sources.";
}
enum source-receiver {
description
"The site has both sources & receivers.";
}
}
description
"Type of multicast site.";
}
description
"Multicast parameters for the site.";
}
description
"Service parameters on the attachement.";
}
container management {
leaf type {
type identityref {
base management;
}
description
"Management type of the connection.";
}
leaf management-transport {
type identityref {
base rt:address-family;
}
description
Litkowski, et al. Expires August 27, 2015 [Page 70]
Internet-Draft l3vpn-svc-cfg February 2015
"Transport protocol used for management.";
}
leaf address {
type union {
type inet:ipv4-address;
type inet:ipv6-address;
}
description
"Management address";
}
description
"Management configuration";
}
container vpn-policy {
container import-policy {
list vpn {
key vpn;
leaf vpn {
type leafref {
path "../../../../../vpn-svc/name";
}
description
"Reference to an IPVPN.";
}
description
"List of VPN service reference.";
}
description
"Import policy.";
}
container export-policy {
list entries {
key id;
leaf id {
type uint32;
description
"Unique identifier for
the export policy entry.";
}
container lan-prefixes {
list ipv4-lan-prefixes {
key lan;
leaf lan {
Litkowski, et al. Expires August 27, 2015 [Page 71]
Internet-Draft l3vpn-svc-cfg February 2015
type inet:ipv4-prefix;
description
"Lan prefixes.";
}
description "
List of LAN prefixes for the site.
";
}
list ipv6-lan-prefixes {
key lan;
leaf lan {
type inet:ipv6-prefix;
description
"Lan prefixes.";
}
description "
List of LAN prefixes for the site.
";
}
description
"LAN prefixes from the customer.";
}
leaf-list lan-tag {
type string;
description
"List of lan-tags to be matched.";
}
leaf-list vpn {
type leafref {
path "../../../../../vpn-svc/name";
}
description
"Reference to an IPVPN.";
}
description
"List of entries for export policy.";
}
description
"Export policy.";
}
description
"Define attachment to VPNs that are not the
attachment VPN.
Use to permit multiple VPN sites.";
}
Litkowski, et al. Expires August 27, 2015 [Page 72]
Internet-Draft l3vpn-svc-cfg February 2015
container maximum-routes {
list address-family {
key af;
leaf af {
type identityref {
base rt: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
"Define maximum-routes for the VRF.";
}
container customer-specific-information {
leaf name {
type string;
description
"Name of the customer router.";
}
leaf autonomous-system {
type uint32;
description
"AS number.";
}
leaf interface {
type string;
description
"Interface reference of the access.";
}
list customer-lan-connection {
key "address";
leaf address {
type union {
type inet:ipv4-address;
type inet:ipv6-address;
}
Litkowski, et al. Expires August 27, 2015 [Page 73]
Internet-Draft l3vpn-svc-cfg February 2015
description
"Address given by the customer on its LAN
for the SP router.";
}
leaf lan-protocol {
type identityref {
base rt:address-family;
}
description
"Transport protocol used on LAN.";
}
description
"List of customer LAN to be connected directly on the CE.";
}
container cascaded-lan-prefixes {
list ipv4-lan-prefixes {
key lan;
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
"Nexthop address to use at customer side.";
}
description "
List of LAN prefixes for the site.
";
}
list ipv6-lan-prefixes {
key lan;
leaf lan {
type inet:ipv6-prefix;
description
"Lan prefixes.";
}
leaf lan-tag {
type string;
description
Litkowski, et al. Expires August 27, 2015 [Page 74]
Internet-Draft l3vpn-svc-cfg February 2015
"Internal tag to be used in vpn policies.";
}
leaf next-hop {
type inet:ipv6-address;
description
"Nexthop address to use at customer side.";
}
description "
List of LAN prefixes for the site.
";
}
description
"LAN prefixes from the customer.";
}
description
"Customer premise configuration.";
}
description "List of sites.";
}
description
"Main container for L3VPN service configuration.";
}
}
<CODE ENDS>
9. To do list / Open questions / Open issues
Open questions :
o Do we need to handle service chaining for the L3VPN service ?
Open issues :
o
TODO :
o Security items
o Bearer details
o ...
Litkowski, et al. Expires August 27, 2015 [Page 75]
Internet-Draft l3vpn-svc-cfg February 2015
10. Security Considerations
TBD.
11. Contributors
12. Acknowledgements
TBD.
13. IANA Considerations
TBD.
14. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4110, July 2005.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[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, June 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012.
Litkowski, et al. Expires August 27, 2015 [Page 76]
Internet-Draft l3vpn-svc-cfg February 2015
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, March
2012.
Appendix A. Example: NETCONF <get> Reply
This section gives an example of a reply to the NETCONF <get> request
for a device that implements the data model defined in this document.
The example is written in XML.
Authors' Addresses
Stephane Litkowski
Orange Business Service
Email: stephane.litkowski@orange.com
Rob Shakir
BT
Email: rob.shakir@bt.com
Luis Tomotaki
Verizon
Email: luis.tomotaki@verizon.com
Kevin D'Souza
ATT
Email: kd6913@att.com
Litkowski, et al. Expires August 27, 2015 [Page 77]