draft-ietf-opsawg-l3sm-l3nm-02.txt   draft-ietf-opsawg-l3sm-l3nm-03.txt 
OPSAWG S. Barguil OPSAWG S. Barguil
Internet-Draft O. Gonzalez de Dios, Ed. Internet-Draft O. Gonzalez de Dios, Ed.
Intended status: Standards Track Telefonica Intended status: Standards Track Telefonica
Expires: September 10, 2020 M. Boucadair Expires: October 5, 2020 M. Boucadair
Orange Orange
L. Munoz L. Munoz
Vodafone Vodafone
A. Aguado A. Aguado
Nokia Nokia
March 09, 2020 April 03, 2020
A Layer 3 VPN Network YANG Model A Layer 3 VPN Network YANG Model
draft-ietf-opsawg-l3sm-l3nm-02 draft-ietf-opsawg-l3sm-l3nm-03
Abstract Abstract
This document defines a L3 VPN Network YANG Data model, called L3NM This document defines a L3VPN Network YANG Model (L3NM) that can be
that can be used to manage the provisioning of Layer 3 VPN services used to manage the provisioning of Layer 3 Virtual Private Network
within a Service Provider Network. The module is meant to be used by (VPN) services within a Service Provider's network. The model
a Network Controller to derive the configuration information that provides a network-centric view of L3VPN services.
will be sent to relevant network devices.
The L3VPN Network YANG Model (L3NM) can also facilitates the L3NM is meant to be used by a Network Controller to derive the
communication between a service orchestrator and a network configuration information that will be sent to relevant network
controller/orchestrator. The model provides a network-centric view devices. The model can also facilitate the communication between a
of the L3VPN services. service orchestrator and a network controller/orchestrator.
The L3NM YANG module is aimed at managing BGP PE-based Layer 3 VPNs L3NM focuses on BGP PE-based Layer 3 VPNs as described in RFCs 4026,
as described in RFCs 4026, 4110 and 4364 and Multicast VPNs as 4110 and 4364 and Multicast VPNs as described in RFCs 6037, 6513 and
described in RFCs 6037, 6513 and 7988. 7988.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Please update these statements within the document with the RFC Please update these statements within the document with the RFC
number to be assigned to this document: number to be assigned to this document:
o "This version of this YANG module is part of RFC XXXX;" o "This version of this YANG module is part of RFC XXXX;"
o "RFC XXXX: Layer 3 VPN Network Model"; o "RFC XXXX: Layer 3 VPN Network Model";
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2020. This Internet-Draft will expire on October 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 50 skipping to change at page 2, line 50
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Reference Architecture . . . . . . . . . . . . . . . . . . . 6 4. Reference Architecture . . . . . . . . . . . . . . . . . . . 6
5. Relation with other YANG Models . . . . . . . . . . . . . . . 8 5. Relation with other YANG Models . . . . . . . . . . . . . . . 8
6. Description of the L3NM YANG Module . . . . . . . . . . . . . 10 6. Description of the L3NM YANG Module . . . . . . . . . . . . . 10
6.1. Overall Structure of the Module . . . . . . . . . . . . . 10 6.1. Overall Structure of the Module . . . . . . . . . . . . . 10
6.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 10 6.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 10
6.3. Modeling a Layer 3 VPN Service . . . . . . . . . . . . . 11 6.3. Modeling a Layer 3 VPN Service . . . . . . . . . . . . . 11
6.3.1. Service Status . . . . . . . . . . . . . . . . . . . 12 6.3.1. Service Status . . . . . . . . . . . . . . . . . . . 12
6.3.2. VPN Node . . . . . . . . . . . . . . . . . . . . . . 13 6.3.2. VPN Node . . . . . . . . . . . . . . . . . . . . . . 13
6.3.2.1. Node Status . . . . . . . . . . . . . . . . . . . 15 6.3.2.1. Node Status . . . . . . . . . . . . . . . . . . . 16
6.3.2.2. VPN Network Access . . . . . . . . . . . . . . . 15 6.3.2.2. RT/RD Assignment/auto-assignment . . . . . . . . 16
6.3.2.2.1. Connection . . . . . . . . . . . . . . . . . 17 6.3.2.3. VPN Network Access . . . . . . . . . . . . . . . 17
6.3.2.2.2. IP Connections . . . . . . . . . . . . . . . 20 6.3.2.3.1. Connection . . . . . . . . . . . . . . . . . 18
6.3.2.2.3. CE PE Routing Protocols . . . . . . . . . . . 22 6.3.2.3.2. IP Connections . . . . . . . . . . . . . . . 22
6.3.2.3. Multicast . . . . . . . . . . . . . . . . . . . . 26 6.3.2.3.3. Security . . . . . . . . . . . . . . . . . . 24
6.3.3. Concept of Import/Export Profiles . . . . . . . . . . 28 6.3.2.3.4. CE PE Routing Protocols . . . . . . . . . . . 25
6.3.4. Underlay Transport . . . . . . . . . . . . . . . . . 28 6.3.2.3.5. Services . . . . . . . . . . . . . . . . . . 29
7. L3NM Module Tree Structure . . . . . . . . . . . . . . . . . 28 6.3.2.4. Multicast . . . . . . . . . . . . . . . . . . . . 31
8. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 39 6.3.3. Concept of Import/Export Profiles . . . . . . . . . . 33
8.1. Enterprise L3 VPN Services . . . . . . . . . . . . . . . 39 6.3.4. Underlay Transport . . . . . . . . . . . . . . . . . 33
8.2. Multi-Domain Resource Management . . . . . . . . . . . . 39 7. L3NM Module Tree Structure . . . . . . . . . . . . . . . . . 33
8.3. Management of Multicast services . . . . . . . . . . . . 39 8. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 43
9. L3VPN Examples . . . . . . . . . . . . . . . . . . . . . . . 40 8.1. Enterprise L3 VPN Services . . . . . . . . . . . . . . . 43
9.1. 4G VPN Provissioning Example . . . . . . . . . . . . . . 40 8.2. Multi-Domain Resource Management . . . . . . . . . . . . 43
9.2. Multicast VPN Provisioning Example . . . . . . . . . . . 44 8.3. Management of Multicast services . . . . . . . . . . . . 44
10. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 46 9. L3VPN Examples . . . . . . . . . . . . . . . . . . . . . . . 44
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 108 9.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 44
12. Security Considerations . . . . . . . . . . . . . . . . . . . 109 9.2. Multicast VPN Provisioning Example . . . . . . . . . . . 48
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 110 10. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 50
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 110 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 110
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 111 12. Security Considerations . . . . . . . . . . . . . . . . . . . 110
15.1. Normative References . . . . . . . . . . . . . . . . . . 111 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 112
15.2. Informative References . . . . . . . . . . . . . . . . . 112 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 112
Appendix A. Implementation Status . . . . . . . . . . . . . . . 113 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 113
A.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 113 15.1. Normative References . . . . . . . . . . . . . . . . . . 113
A.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 114 15.2. Informative References . . . . . . . . . . . . . . . . . 114
A.3. Infinera Implementation . . . . . . . . . . . . . . . . . 118 Appendix A. Implementation Status . . . . . . . . . . . . . . . 115
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 118 A.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 115
A.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 116
A.3. Infinera Implementation . . . . . . . . . . . . . . . . . 119
A.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 120
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 122
1. Introduction 1. Introduction
[RFC8299] defines an L3VPN Service YANG data Model (L3SM) that can be [RFC8299] defines an L3VPN Service YANG data Model (L3SM) that can be
used for communication between customers and network operators. Such used for communication between customers and network operators. Such
model is focused on describing the customer view of the VPN services, model is focused on describing the customer view of the VPN services,
and provides an abstracted view of the customer's requested services. and provides an abstracted view of the customer's requested services.
That approach limits the usage of the L3SM module to the role of a That approach limits the usage of the L3SM module to the role of a
Customer Service Model, according to the terminology defined in Customer Service Model, according to the terminology defined in
[RFC8309]. [RFC8309].
skipping to change at page 9, line 45 skipping to change at page 9, line 45
activation and provisioning of the VPN service will involve a activation and provisioning of the VPN service will involve a
variety of device modules to tweak the required functions for the variety of device modules to tweak the required functions for the
delivery of the service. These functions are supported by the VPN delivery of the service. These functions are supported by the VPN
nodes and can be managed using device YANG modules. A non- nodes and can be managed using device YANG modules. A non-
comprehensive list of such device YANG modules is provided below: comprehensive list of such device YANG modules is provided below:
* Routing management ([RFC8349]) * Routing management ([RFC8349])
* BGP ([I-D.ietf-idr-bgp-model]) * BGP ([I-D.ietf-idr-bgp-model])
* PIM ([I-D.liu-pim-yang]) * PIM ([I-D.ietf-pim-yang])
* NAT management ([RFC8512]) * NAT management ([RFC8512])
* QoS management ([I-D.ietf-rtgwg-qos-model]) * QoS management ([I-D.ietf-rtgwg-qos-model])
* ACL ([RFC8519]) * ACL ([RFC8519])
How L3NM is used to derive device-specific actions is How L3NM is used to derive device-specific actions is
implementation-specific. implementation-specific.
6. Description of the L3NM YANG Module 6. Description of the L3NM YANG Module
The L3NM module ('ietf-l3vpn-ntw') is meant to manage L3 VPNs in a The L3NM module ('ietf-l3vpn-ntw') is meant to manage L3 VPNs in a
service provider network. In particular, the 'ietf-l3vpn-ntw' module service provider network. In particular, the 'ietf-l3vpn-ntw' module
can be used to create, modify, and retrieve L3VPN Services of a can be used to create, modify, and retrieve L3VPN Services of a
network. network.
The detailed tree structure is provided in Figure 15. The detailed tree structure is provided in Figure 17.
6.1. Overall Structure of the Module 6.1. Overall Structure of the Module
The 'ietf-l3vpn-ntw' module uses two main containers: 'vpn-services' The 'ietf-l3vpn-ntw' module uses two main containers: 'vpn-services'
and 'vpn-profiles' (see Figure 3). and 'vpn-profiles' (see Figure 3).
The 'vpn-services' container maintains the set of VPN services The 'vpn-services' container maintains the set of VPN services
managed within the service provider's network. 'vpn-service' is the managed within the service provider's network. 'vpn-service' is the
data structure that abstracts a VPN service (Section 6.3). data structure that abstracts a VPN service (Section 6.3).
skipping to change at page 11, line 36 skipping to change at page 11, line 36
The 'vpn-service' is the data structure that abstracts a VPN Service The 'vpn-service' is the data structure that abstracts a VPN Service
in the Service Provider Network. Each 'vpn-service' is uniquely in the Service Provider Network. Each 'vpn-service' is uniquely
identified by an identifier: 'vpn-id'. Such 'vpn-id' is only identified by an identifier: 'vpn-id'. Such 'vpn-id' is only
meaningful locally within the Network controller. meaningful locally within the Network controller.
In order to facilitate the identification of the service, 'customer- In order to facilitate the identification of the service, 'customer-
name' and 'description' attributes may be provided. name' and 'description' attributes may be provided.
The 'vpn-service' parameters are: The 'vpn-service' parameters are:
o service-status: Allows the control of the operative and o 'service-status': Allows the control of the operative and
administrative status of the service as a whole. administrative status of the service as a whole.
o vpn-id: Unique identifier of the L3VPN Service within L3NM scope. o 'vpn-id': Is an identifier that is used to uniquely identify the
L3VPN Service within L3NM scope.
o l3sm-vpn-id: Refers to the L3SNM Id of this service. This o 'l3sm-vpn-id': Refers to an identifier of L3SM service. This
identifier allows to easily correlate the service as built in the identifier allows to easily correlate the (network) service as
network with a service request. built in the network with a service order.
o vpn-service-topology: Typical network topologies are supported. o 'vpn-service-topology': Indicates the network topology for the
Hub-Spoke, Any-to-Any, and Custom. Real deployment on the network service: Hub-Spoke, Any-to-Any, and Custom. The deployment on the
is defined by the correct usage of import and export profiles network is defined by the correct usage of import and export
profiles
o ie-profiles: Define reusable import/export policies for the same o 'ie-profiles': Defines reusable import/export policies for the
VPN-Service. Described in detail in Section 6.3.3 same 'vpn-service'. More details are provided in Section 6.3.3
o Underlay-Transport: Describes the preference for the transport o 'underlay-transport': Describes the preference for the transport
technology to carry the traffic of the VPN-Service. technology to carry the traffic of the VPN service.
A VPN service is typically built by adding instances of 'vpn-node' to A VPN service is typically built by adding instances of 'vpn-node' to
the 'vpn-nodes' container. The 'vpn-node' is an abstraction that the 'vpn-nodes' container. The 'vpn-node' is an abstraction that
represents a set of policies applied to a network node and that represents a set of policies applied to a network node and that
belong to a single 'vpn-service'. belong to a single 'vpn-service'.
A 'vpn-node' contains 'vpn-network-accesses', which are the A 'vpn-node' contains 'vpn-network-accesses', which are the
interfaces attached to the VPN by which the customer traffic is interfaces attached to the VPN by which the customer traffic is
received. Therefore, the customer sites are connected to the 'vpn- received. Therefore, the customer sites are connected to the 'vpn-
network-accesses'. Note that, as this is a network data model, the network-accesses'. Note that, as this is a network data model, the
skipping to change at page 13, line 25 skipping to change at page 13, line 25
| +--ro status? operational-type | +--ro status? operational-type
| +--ro timestamp? yang:date-and-time | +--ro timestamp? yang:date-and-time
... ...
Figure 6: VPN Service Status Tree Structure Figure 6: VPN Service Status Tree Structure
6.3.2. VPN Node 6.3.2. VPN Node
The 'vpn-node' is an abstraction that represents a set of common The 'vpn-node' is an abstraction that represents a set of common
policies applied on a given network node (tipcally, a PE) and belong policies applied on a given network node (tipcally, a PE) and belong
to one L3 VPN Service. In order to indicate the network node where to one L3 VPN service. In order to indicate the network nodes where
the 'vpn-node' applies the 'ne-id' must be indicated. The 'vpn-node' the 'vpn-node' applies, the 'ne-id' must be indicated. The 'vpn-
includes a parameter to indicate in which network node it is applied. node' includes a parameter to indicate the network node on which it
In the case that the 'ne-id' points to a specific PE, the 'vpn-node' is applied. In the case that the 'ne-id' points to a specific PE,
will likely be mapped into a VRF in the node. However, the model the 'vpn-node' will likely be mapped into a VRF in the node.
also allows to point to an abstract node. In this case, the network However, the model also allows to point to an abstract node. In this
controller will decide how to split the 'vpn-node' into VRFs. case, the network controller will decide how to split the 'vpn-node'
Additionally the 'vpn-node' parameters are: into VRFs. Soem 'vpn-node' parameters are listed below:
o status: Allows the control of the operative and administrative
status of the 'vpn-node'.
o local-autonomous-system: Autonomous system of locally configured o local-autonomous-system: Refers to the autonomous system number
in the instance. It can be overwritten for specific purposes in that is locally configured in the instance. It can be overwritten
the CE-PE BGP session. for specific purposes in the CE-PE BGP session.
o maximum-routes: Max-number of prefixes allowed in the vpn-node o maximum-routes: Set the maximum number of prefixes allowed in the
instance. 'vpn-node' instance. This value is typically set in the service
request.
o rd and vpn-targets: For the cases the logical resources are o 'rd' and 'vpn-targets': For the cases the logical resources are
managed outside the network controller, the model allows to managed outside the network controller, the model allows to
explicitely indicate the logical resources such as Route targets explicitely indicate the logical resources such as Route targets
(RTs) and Route Distinguishers (RDs) (RT,RD). (RTs) and Route Distinguishers (RDs) (RT,RD).
o Multicast: Enable multicast traffic inside the vpn. Detailed o Multicast: Enable multicast traffic inside the VPN. Refer to
description in Section 6.3.2.3 Section 6.3.2.4.
Under the VPN Node ('vpn-node') container, VPN Network Acesses ('vpn- Under the VPN Node ('vpn-node') container, VPN Network Acesses ('vpn-
network-access') can be created. The VPN Network Acess represents network-access') can be created. The VPN Network Acess represents
the point to which sites are connected. Note that, unlike in L3SM, the point to which sites are connected. Note that, unlike in L3SM,
the L3NM does not need to model the customer site, only the points the L3NM does not need to model the customer site, only the points
where the traffic from the site are received. Hence, the VPN Network where the traffic from the site are received. Hence, the VPN Network
access contains the connectivity information between the provider's access contains the connectivity information between the provider's
network and the customer premises. The VPN profiles ('vpn-profiles') network and the customer premises. The VPN profiles ('vpn-profiles')
have a set of routing policies than can be applied during the service have a set of routing policies than can be applied during the service
creation. creation.
skipping to change at page 14, line 33 skipping to change at page 15, line 23
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [ne-id] +--rw vpn-node* [ne-id]
+--rw vpn-node-id? union +--rw vpn-node-id? union
+--rw local-autonomous-system? inet:as-number +--rw local-autonomous-system? inet:as-number
+--rw description? string +--rw description? string
+--rw ne-id string +--rw ne-id string
+--rw router-id? inet:ip-address +--rw router-id? inet:ip-address
+--rw address-family? +--rw address-family?
| l3vpn-svc:address-family | l3vpn-svc:address-family
+--rw node-role? identityref +--rw node-role? identityref
+--rw rd? +--rw rw rd? union
| rt-types:route-distinguisher
+--rw vpn-targets +--rw vpn-targets
| +--rw vpn-target* [id] | +--rw vpn-target* [id]
| | +--rw id int8 | | +--rw id int8
| | +--rw route-targets* [route-target] | | +--rw route-targets* [route-target]
| | | +--rw route-target | | | +--rw route-target
| | | rt-types:route-target | | | rt-types:route-target
| | +--rw route-target-type | | +--rw route-target-type
| | rt-types:route-target-type | | rt-types:route-target-type
| +--rw vpn-policies | +--rw vpn-policies
| +--rw import-policy? leafref | +--rw import-policy? leafref
skipping to change at page 15, line 41 skipping to change at page 16, line 30
+--rw vpn-nodes +--rw vpn-nodes
| +--rw vpn-node* [ne-id] | +--rw vpn-node* [ne-id]
| +--rw ne-id string | +--rw ne-id string
| ... | ...
| +--rw status | +--rw status
| | +--rw admin-enabled? boolean | | +--rw admin-enabled? boolean
| | +--ro oper-status? operational-type | | +--ro oper-status? operational-type
Figure 8: Node Status Tree Structure Figure 8: Node Status Tree Structure
6.3.2.2. VPN Network Access 6.3.2.2. RT/RD Assignment/auto-assignment
For the cases the logical resources are managed outside the network
controller, the model allows to explicitely indicate the logical
resources such as Route targets (RTs) and Route Distinguishers (RDs)
(RT,RD).
Three possible behaviors are needed to fulfil the identified use
cases:
o The network controller auto-assigns logical resources (RTs, RDs).
This can apply for new services deployment.
o The Network Operator/Service orchestrator assigns explicitly the
RTs and RDs. This case will fit with a brownfield scenario where
some existing services needs to be updated by the network
operators.
o The Network Operator/Service orchestrator explicitly wants NO RT/
RD to be assigned. This case will fit in VRF-Lite scenarios, CE
testing inside the Network or just for troubleshooting pruposes.
Thus a union between two yang data types are included in order to
support this scenarios. So, if the leaf is not created in the Yang
the expected behavior is the auto-assigns. If the Leaf is created
with a valid rd value it will be explicitly assign in the VPN Node
and if the leaf is created with an empty value, the RD value will not
be deployed in the VPN node.
6.3.2.3. VPN Network Access
A 'vpn-network-access' represents an entry point to a VPN service A 'vpn-network-access' represents an entry point to a VPN service
(Figure 9). In other words, this container encloses the parameters (Figure 9). In other words, this container encloses the parameters
that describe the access information for the traffic that belongs to that describe the access information for the traffic that belongs to
a particular L3VPN. As such, every 'vpn-network-access' MUST belong a particular L3VPN. As such, every 'vpn-network-access' MUST belong
to one and only one 'vpn-node'. to one and only one 'vpn-node'.
A 'vpn-network-access' includes information such as the connection on A 'vpn-network-access' includes information such as the connection on
which the access is defined (see Section 6.3.2.2.1), the which the access is defined (see Section 6.3.2.3.1), the
encapsulation of the traffic, policies that are applied on the encapsulation of the traffic, policies that are applied on the
access, etc. access, etc.
A provisioning Network Controller (PNC) [RFC8453] will accept VPN A provisioning Network Controller (PNC) [RFC8453] will accept VPN
requests containing this construct, using the enclosed data to: requests containing this construct, using the enclosed data to:
configure the router's interface to include the parameters described configure the router's interface to include the parameters described
at the 'vpn-network-access', include the given interface into a VRF, at the 'vpn-network-access', include the given interface into a VRF,
configuring policies or schedulers for processing the incoming configuring policies or schedulers for processing the incoming
traffic, etc. traffic, etc.
skipping to change at page 17, line 5 skipping to change at page 18, line 43
| +--rw security | +--rw security
| | ... | | ...
| +--rw routing-protocols | +--rw routing-protocols
| | ... | | ...
| +--rw service | +--rw service
| ... | ...
| ... | ...
Figure 9: VPN Network Access Tree Structure Figure 9: VPN Network Access Tree Structure
6.3.2.2.1. Connection 6.3.2.3.1. Connection
The definition of a L3VPN is commonly specified not only at the IP The definition of a L3VPN is commonly specified not only at the IP
layer, but also requires to identify parameters at the Ethernet layer, but also requires to identify parameters at the Ethernet
layer, such as encapsulation type (e.g., VLAN, QinQ, QinAny, VxLAN, layer, such as encapsulation type (e.g., VLAN, QinQ, QinAny, VxLAN,
etc.). The 'connection' container represents and groups the set of etc.). The 'connection' container represents and groups the set of
L2 connectivity from where the traffic of the L3VPN in a particular L2 connectivity from where the traffic of the L3VPN in a particular
VPN Network access is coming. VPN Network access is coming.
Additionally, the bearer-reference and the pseudowire termination are Additionally, the bearer-reference and the pseudowire termination are
supported. supported.
skipping to change at page 20, line 5 skipping to change at page 22, line 5
A site, as per [RFC4176] represents a VPN customer's location that is A site, as per [RFC4176] represents a VPN customer's location that is
connected to the Service Provider network via a CE-PE link, which can connected to the Service Provider network via a CE-PE link, which can
access at least one VPN. The connection from the site to the Service access at least one VPN. The connection from the site to the Service
Provider network is the bearer. Every site is associated with a list Provider network is the bearer. Every site is associated with a list
of bearers. A bearer is the layer two connections with the site. In of bearers. A bearer is the layer two connections with the site. In
the module it is assumed that the bearer has been allocated by the the module it is assumed that the bearer has been allocated by the
Service Provider at the service orchestration step. The bearer is Service Provider at the service orchestration step. The bearer is
associated to a network element and a port. Hence, a bearer is just associated to a network element and a port. Hence, a bearer is just
a bearer-reference to allow the translation between L3SM and L3NM. a bearer-reference to allow the translation between L3SM and L3NM.
6.3.2.2.2. IP Connections 6.3.2.3.2. IP Connections
IP connection container (Figure 12) has the parameters of the 'vpn- IP connection container (Figure 12) has the parameters of the 'vpn-
network-access' addressing information. The address allocated in network-access' addressing information. The address allocated in
this container would represent the PE interface address this container would represent the PE interface address
configuration. The IP connection container is designed to support configuration. The IP connection container is designed to support
both IPv4 and IPv6. It also supports three options for IP address both IPv4 and IPv6. It also supports three options for IP address
assignment: Provider DHCP, DHCP relay, and static addressing. assignment: Provider DHCP, DHCP relay, and static addressing.
In the case of the static addressing, the model supports the In the case of the static addressing, the model supports the
assignment of several IP addresses in the same 'vpn-network-access'. assignment of several IP addresses in the same 'vpn-network-access'.
skipping to change at page 22, line 39 skipping to change at page 24, line 39
| | +--rw profile-name? leafref | | +--rw profile-name? leafref
| +--rw security | +--rw security
| | ... | | ...
| +--rw routing-protocols | +--rw routing-protocols
| | ... | | ...
| +--rw service | +--rw service
| ... | ...
Figure 12: IP Connection Tree Structure Figure 12: IP Connection Tree Structure
6.3.2.2.3. CE PE Routing Protocols 6.3.2.3.3. Security
The 'security' container specifies the authentication and the
encryption to be applied for a given VPN network access (Figure 13).
module: ietf-l3vpn-ntw
+--rw l3vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
+--rw vpn-id l3vpn-svc:svc-id
+ ...
+--rw vpn-node* [ne-id]
+--rw ne-id string
+ ...
+--rw vpn-network-accesses
| +--rw vpn-network-access* [id]
| +--rw id
| | l3vpn-svc:svc-id
| + ...
| +--rw connection
| | ...
| +--rw ip-connection
| | ...
| +--rw security
| | +--rw authentication
| | +--rw encryption {l3vpn-svc:encryption}?
| | | +--rw enabled? boolean
| | | +--rw layer? enumeration
| | +--rw encryption-profile
| | +--rw (profile)?
| | | +--:(provider-profile)
| | | | +--rw profile-name? leafref
| | | +--:(customer-profile)
| | | +--rw algorithm? string
| | +--rw (key-type)?
| | +--:(psk)
| | +--rw preshared-key? string
| +--rw routing-protocols
| | ...
| +--rw service
| ...
| ...
Figure 13: Security Tree Structure
6.3.2.3.4. CE PE Routing Protocols
The model allows the Provider to configure one or more routing The model allows the Provider to configure one or more routing
protocols associated with a particular 'vpn-network-access' protocols associated with a particular 'vpn-network-access'
(Figure 13). This protocol will run between the PE and the CE. A (Figure 14). This protocol will run between the PE and the CE. A
routing protocol instance MUST have a type (e.g., bgp, ospf) and an routing protocol instance MUST have a type (e.g., bgp, ospf) and an
identifier. The identifier is necessary when multiple instances of identifier. The identifier is necessary when multiple instances of
the same protocol have to be configured. the same protocol have to be configured.
When configuring multiple instances of the same routing protocol, When configuring multiple instances of the same routing protocol,
this does not automatically imply that, from a device configuration this does not automatically imply that, from a device configuration
perspective, there will be parallel instances (multiple processes) perspective, there will be parallel instances (multiple processes)
running. It will be up to the implementation to use the most running. It will be up to the implementation to use the most
appropriate deployment model. As an example, when multiple BGP peers appropriate deployment model. As an example, when multiple BGP peers
need to be implemented, multiple instances of BGP must be configured need to be implemented, multiple instances of BGP must be configured
skipping to change at page 26, line 21 skipping to change at page 29, line 28
| | | inet:ipv6-address | | | inet:ipv6-address
| | +--rw rip {l3vpn-svc:rtg-rip}? | | +--rw rip {l3vpn-svc:rtg-rip}?
| | | +--rw address-family* | | | +--rw address-family*
| | | l3vpn-svc:address-family | | | l3vpn-svc:address-family
| | +--rw vrrp {l3vpn-svc:rtg-vrrp}? | | +--rw vrrp {l3vpn-svc:rtg-vrrp}?
| | +--rw address-family* | | +--rw address-family*
| | l3vpn-svc:address-family | | l3vpn-svc:address-family
| +--rw service | +--rw service
| ... | ...
Figure 13: Routing Tree Structure Figure 14: Routing Tree Structure
6.3.2.3. Multicast 6.3.2.3.5. Services
The 'services' container specifies the service parameter to apply for
a give VPN network access (Figure 15). The following attributes are
defined:
o TBC
module: ietf-l3vpn-ntw
+--rw l3vpn-ntw
+--rw vpn-profiles
| ...
+--rw vpn-services
+--rw vpn-service* [vpn-id]
+--rw vpn-id l3vpn-svc:svc-id
+ ...
+--rw vpn-node* [ne-id]
+--rw ne-id string
+ ...
+--rw vpn-network-accesses
| +--rw vpn-network-access* [id]
| +--rw id
| | l3vpn-svc:svc-id
| + ...
| +--rw connection
| | ...
| +--rw ip-connection
| | ...
| +--rw security
| | ...
| +--rw routing-protocols
| | ...
| +--rw service
| +--rw svc-input-bandwidth uint64
| +--rw svc-output-bandwidth uint64
| +--rw svc-mtu uint16
| +--rw qos {l3vpn-svc:qos}?
| | +--rw qos-classification-policy
| | | +--rw rule* [id]
| | | +--rw id
| | | | string
| | | +--rw (match-type)?
| | | | +--:(match-flow)
| | | | | +--rw (l3)?
| | | | | | +--:(ipv4)
| | | | | | | ...
| | | | | | +--:(ipv6)
| | | | | | ...
| | | | | +--rw (l4)?
| | | | | +--:(tcp)
| | | | | | ...
| | | | | +--:(udp)
| | | | | ...
| | | | +--:(match-application)
| | | | +--rw match-application?
| | | | identityref
| | | +--rw target-class-id?
| | | string
| | +--rw qos-profile
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile? leafref
| | | +--rw direction? identityref
| | +--:(custom)
| | ...
| +--rw carrierscarrier
| | {l3vpn-svc:carrierscarrier}?
| | +--rw signalling-type? enumeration
| +--rw multicast {l3vpn-svc:multicast}?
| +--rw site-type? enumeration
| +--rw address-family
| | +--rw ipv4? boolean
| | | {l3vpn-svc:ipv4}?
| | +--rw ipv6? boolean
| | {l3vpn-svc:ipv6}?
| +--rw protocol-type? enumeration
| +--rw remote-source? boolean
| ...
Figure 15: Services Tree Structure
6.3.2.4. Multicast
Multicast MAY be enabled for a particular vpn-network-node (see Multicast MAY be enabled for a particular vpn-network-node (see
Figure 14). Figure 16).
The model supports a single type of tree (Any-Source Multicast (ASM), The model supports a single type of tree (Any-Source Multicast (ASM),
Source-Specific Multicast (SSM), or bidirectional). Source-Specific Multicast (SSM), or bidirectional).
When ASM is used, the model supports the configuration of rendez-vous When ASM is used, the model supports the configuration of rendez-vous
points (RPs). RP discovery may be 'static', 'bsr-rp', or 'auto-rp'. points (RPs). RP discovery may be 'static', 'bsr-rp', or 'auto-rp'.
When set to 'static', RP to multicast grouping mapping MUST be When set to 'static', RP to multicast grouping mapping MUST be
configured as part of the 'rp-group-mappings' container. The RP MAY configured as part of the 'rp-group-mappings' container. The RP MAY
be a provider node or a customer node. When the RP is a customer be a provider node or a customer node. When the RP is a customer
node, the RP address must be configured using the 'rp-address' leaf node, the RP address must be configured using the 'rp-address' leaf
skipping to change at page 28, line 19 skipping to change at page 33, line 11
| | +--rw rp-discovery-type? identityref | | +--rw rp-discovery-type? identityref
| | +--rw bsr-candidates | | +--rw bsr-candidates
| | +--rw bsr-candidate-address* | | +--rw bsr-candidate-address*
| | inet:ip-address | | inet:ip-address
| +--rw msdp {msdp}? | +--rw msdp {msdp}?
| +--rw enabled? boolean | +--rw enabled? boolean
| +--rw peer? inet:ip-address | +--rw peer? inet:ip-address
| +--rw local-address? inet:ip-address | +--rw local-address? inet:ip-address
+ ... + ...
Figure 14: Multicast Tree Structure Figure 16: Multicast Tree Structure
6.3.3. Concept of Import/Export Profiles 6.3.3. Concept of Import/Export Profiles
The import and export profiles construct contains a list with The import and export profiles construct contains a list with
information related with route target and distinguishers (RTs and information related with route target and distinguishers (RTs and
RDs), grouped and identified by ie-profile-id. The identifier is RDs), grouped and identified by ie-profile-id. The identifier is
then referenced in one or multiple vpn-nodes, so the PNC can identify then referenced in one or multiple vpn-nodes, so the PNC can identify
RTs and RDs to be configured in the VRF. RTs and RDs to be configured in the VRF.
6.3.4. Underlay Transport 6.3.4. Underlay Transport
skipping to change at page 28, line 45 skipping to change at page 33, line 37
TE as possible underlay transport. TE as possible underlay transport.
Other profiles can be defined in the future. Other profiles can be defined in the future.
This document does not make any assumption about the exact definition This document does not make any assumption about the exact definition
of these profiles. How such profiles are defined is deployment- of these profiles. How such profiles are defined is deployment-
specific. specific.
7. L3NM Module Tree Structure 7. L3NM Module Tree Structure
The L3NM Module Tree Structure is depicted in Figure 15. The L3NM Module Tree Structure is depicted in Figure 17.
module: ietf-l3vpn-ntw module: ietf-l3vpn-ntw
+--rw l3vpn-ntw +--rw l3vpn-ntw
+--rw vpn-profiles +--rw vpn-profiles
| +--rw valid-provider-identifiers | +--rw valid-provider-identifiers
| +--rw cloud-identifier* [id] {l3vpn-svc:cloud-access}? | +--rw cloud-identifier* [id] {l3vpn-svc:cloud-access}?
| | +--rw id string | | +--rw id string
| +--rw encryption-profile-identifier* [id] | +--rw encryption-profile-identifier* [id]
| | +--rw id string | | +--rw id string
| +--rw qos-profile-identifier* [id] | +--rw qos-profile-identifier* [id]
skipping to change at page 29, line 43 skipping to change at page 34, line 35
| | +--rw id int8 | | +--rw id int8
| | +--rw route-targets* [route-target] | | +--rw route-targets* [route-target]
| | | +--rw route-target | | | +--rw route-target
| | | rt-types:route-target | | | rt-types:route-target
| | +--rw route-target-type | | +--rw route-target-type
| | rt-types:route-target-type | | rt-types:route-target-type
| +--rw vpn-policies | +--rw vpn-policies
| +--rw import-policy? leafref | +--rw import-policy? leafref
| +--rw export-policy? leafref | +--rw export-policy? leafref
+--rw underlay-transport +--rw underlay-transport
| +--rw type? protocols-type | +--rw type* protocol-type
+--rw vpn-nodes +--rw vpn-nodes
+--rw vpn-node* [ne-id] +--rw vpn-node* [ne-id]
+--rw vpn-node-id? union +--rw vpn-node-id? union
+--rw local-autonomous-system? inet:as-number +--rw local-autonomous-system? inet:as-number
+--rw description? string +--rw description? string
+--rw ne-id string +--rw ne-id string
+--rw router-id? inet:ip-address +--rw router-id? inet:ip-address
+--rw address-family? +--rw address-family?
| l3vpn-svc:address-family | l3vpn-svc:address-family
+--rw node-role? identityref +--rw node-role? identityref
+--rw rd? +--rw rd? union
| rt-types:route-distinguisher
+--rw vpn-targets +--rw vpn-targets
| +--rw vpn-target* [id] | +--rw vpn-target* [id]
| | +--rw id int8 | | +--rw id int8
| | +--rw route-targets* [route-target] | | +--rw route-targets* [route-target]
| | | +--rw route-target | | | +--rw route-target
| | | rt-types:route-target | | | rt-types:route-target
| | +--rw route-target-type | | +--rw route-target-type
| | rt-types:route-target-type | | rt-types:route-target-type
| +--rw vpn-policies | +--rw vpn-policies
| +--rw import-policy? leafref | +--rw import-policy? leafref
skipping to change at page 37, line 5 skipping to change at page 41, line 44
| | | | | +--rw (source-port)? | | | | | +--rw (source-port)?
| | | | | | ... | | | | | | ...
| | | | | +--rw (destination-port)? | | | | | +--rw (destination-port)?
| | | | | | ... | | | | | | ...
| | | | +--:(match-application) | | | | +--:(match-application)
| | | | +--rw match-application? | | | | +--rw match-application?
| | | | identityref | | | | identityref
| | | +--rw target-class-id? | | | +--rw target-class-id?
| | | string | | | string
| | +--rw qos-profile | | +--rw qos-profile
| | +--rw (qos-profile)? | | +--rw qos-profile* [profile]
| | +--:(standard) | | +--rw profile -> /l3vpn-ntw/...
| | | +--rw profile? leafref | | +--rw direction? identityref
| | | +--rw direction? identityref
| | +--:(custom)
| | +--rw classes
| | {l3vpn-svc:qos-custom}?
| | +--rw class* [class-id]
| | +--rw class-id
| | | string
| | +--rw direction?
| | | identityref
| | +--rw rate-limit?
| | | decimal64
| | +--rw latency
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-latency?
| | | | empty
| | | +--:(boundary)
| | | +--rw jitter-boundary?
| | | uint16
| | +--rw jitter
| | | +--rw (flavor)?
| | | +--:(lowest)
| | | | +--rw use-lowest-jitter?
| | | | empty
| | | +--:(boundary)
| | | +--rw latency-boundary?
| | | uint32
| | +--rw bandwidth
| | +--rw guaranteed-bw-percent
| | | decimal64
| | +--rw end-to-end?
| | empty
| +--rw carrierscarrier | +--rw carrierscarrier
| | {l3vpn-svc:carrierscarrier}? | | {l3vpn-svc:carrierscarrier}?
| | +--rw signalling-type? enumeration | | +--rw signalling-type? enumeration
| +--rw multicast {l3vpn-svc:multicast}? | +--rw multicast {l3vpn-svc:multicast}?
| +--rw site-type? enumeration | +--rw site-type? enumeration
| +--rw address-family | +--rw address-family
| | +--rw ipv4? boolean | | +--rw ipv4? boolean
| | | {l3vpn-svc:ipv4}? | | | {l3vpn-svc:ipv4}?
| | +--rw ipv6? boolean | | +--rw ipv6? boolean
| | {l3vpn-svc:ipv6}? | | {l3vpn-svc:ipv6}?
skipping to change at page 39, line 6 skipping to change at page 43, line 13
| | +--rw rp-discovery-type? identityref | | +--rw rp-discovery-type? identityref
| | +--rw bsr-candidates | | +--rw bsr-candidates
| | +--rw bsr-candidate-address* | | +--rw bsr-candidate-address*
| | inet:ip-address | | inet:ip-address
| +--rw msdp {msdp}? | +--rw msdp {msdp}?
| +--rw enabled? boolean | +--rw enabled? boolean
| +--rw peer? inet:ip-address | +--rw peer? inet:ip-address
| +--rw local-address? inet:ip-address | +--rw local-address? inet:ip-address
+--rw node-ie-profile? leafref +--rw node-ie-profile? leafref
Figure 15 Figure 17
8. Sample Uses of the L3NM Data Model 8. Sample Uses of the L3NM Data Model
8.1. Enterprise L3 VPN Services 8.1. Enterprise L3 VPN Services
Enterprise L3VPNs are one of the most demanded services for carriers, Enterprise L3VPNs are one of the most demanded services for carriers,
and therefore, L3NM can be useful to automate the tasks of and therefore, L3NM can be useful to automate the tasks of
provisioning and maintenance of these VPNs. Templates and batch provisioning and maintenance of these VPNs. Templates and batch
processes can be built, and as a result many parameters are needed processes can be built, and as a result many parameters are needed
for the creation from scratch of a VPN that can be abstracted to the for the creation from scratch of a VPN that can be abstracted to the
skipping to change at page 40, line 23 skipping to change at page 44, line 32
backbone. Because of this, ng-MNPN is the architectural model that backbone. Because of this, ng-MNPN is the architectural model that
has been taken as the base for implementing multicast service on has been taken as the base for implementing multicast service on
L3VPN. In this scenario, BGP auto discovery is used to discover MVPN L3VPN. In this scenario, BGP auto discovery is used to discover MVPN
PE members and the customer PIM signaling is sent across provider PE members and the customer PIM signaling is sent across provider
core through MP-BGP. The multicast traffic is transported on MPLS core through MP-BGP. The multicast traffic is transported on MPLS
P2MP LSPs. All of the previous information is carried in the MCAST- P2MP LSPs. All of the previous information is carried in the MCAST-
VPN BGP NRLI. VPN BGP NRLI.
9. L3VPN Examples 9. L3VPN Examples
9.1. 4G VPN Provissioning Example 9.1. 4G VPN Provisioning Example
L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise L3VPNs are widely used to deploy 3G/4G, fixed, and enterprise
services mainly because several traffic discrimination policies can services mainly because several traffic discrimination policies can
be applied within the network to deliver to the mobile customers a be applied within the network to deliver to the mobile customers a
service that meets the SLA requiremets. service that meets the SLA requirements.
As it is shown in the Figure 16, typically, an eNodeB (CE) is As it is shown in the Figure 18, typically, an eNodeB (CE) is
directly connected to the access routers of the mobile backhaul and directly connected to the access routers of the mobile backhaul and
their logical interfaces (one or many according to the Service type) their logical interfaces (one or many according to the Service type)
are configured in a VPN that transports the packets to the mobile are configured in a VPN that transports the packets to the mobile
core platforms. In this example, a 'vpn-node' is created with two core platforms. In this example, a 'vpn-node' is created with two
'vpn-network-accesses'. 'vpn-network-accesses'.
+-------------+ +------------------+ +-------------+ +------------------+
| | | PE | | | | PE |
| | 192.168.0.2 | 10.0.0.1 | | | 192.168.0.2 | 10.0.0.1 |
| eNodeB |>--------/------->|........... | | eNodeB |>--------/------->|........... |
| | Vlan 1 | | | | | Vlan 1 | | |
| |>--------/------->|...... | | | |>--------/------->|...... | |
| | Vlan 2 | | | | | | Vlan 2 | | | |
| | Direct | +-------------+ | | | Direct | +-------------+ |
+-------------+ Routing | | vpn-node-id | | +-------------+ Routing | | vpn-node-id | |
| | 44 | | | | 44 | |
| +-------------+ | | +-------------+ |
| | | |
+------------------+ +------------------+
Figure 16: Mobile Backhaul Example Figure 18: Mobile Backhaul Example
To create a L3VPN service using the L3NM model, the followng sample To create a L3VPN service using the L3NM model, the following sample
steps can be followed: steps can be followed:
First: Create the 4G VPN Service (Figure 17). First: Create the 4G VPN Service (Figure 19).
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-l3vpn-ntw:vpn-services": { "ietf-l3vpn-ntw:vpn-services": {
"vpn-service": [ "vpn-service": [
"vpn-id": "4G", "vpn-id": "4G",
"customer-name": "mycustomer", "customer-name": "mycustomer",
"vpn-service-topology": "custom", "vpn-service-topology": "custom",
"description": "VPN to deploy 4G services" "description": "VPN to deploy 4G services"
] ]
} }
} }
Figure 17: Create VPN Service Figure 19: Create VPN Service
Second: Create a VPN Node as depicted in Figure 18. In this type of Second: Create a VPN Node as depicted in Figure 20. In this type of
service, the VPN Node is equivalent to the VRF configured in the service, the VPN Node is equivalent to the VRF configured in the
physical device ('ne-id'=10.0.0.1). physical device ('ne-id'=10.0.0.1).
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
vpn-services/vpn-service=4G vpn-services/vpn-service=4G
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-l3vpn-ntw:vpn-nodes": { "ietf-l3vpn-ntw:vpn-nodes": {
skipping to change at page 42, line 28 skipping to change at page 46, line 28
"vpn-target": [ "vpn-target": [
"id": "1", "id": "1",
"route-targets": ["route-target": "0:65550:1"], "route-targets": ["route-target": "0:65550:1"],
"route-target-type": "both" "route-target-type": "both"
} }
} }
] ]
} }
} }
Figure 18: Create VPN Node Figure 20: Create VPN Node
Finally, two VPN Network Accesses are created using the same physical Finally, two VPN Network Accesses are created using the same physical
port ('port-id'=1/1/1). Each 'vpn-network-access' has a particular port ('port-id'=1/1/1). Each 'vpn-network-access' has a particular
VLAN (1,2) to differentiante the traffic between: Sync and data VLAN (1,2) to differentiate the traffic between: Sync and data
(Figure 19). (Figure 21).
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44 vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44
content-type: application/yang-data+json content-type: application/yang-data+json
{ {
"ietf-l3vpn-ntw:vpn-network-accesses": { "ietf-l3vpn-ntw:vpn-network-accesses": {
"vpn-network-access": [ "vpn-network-access": [
{ {
"vpn-network-access-id": "1/1/1.1", "vpn-network-access-id": "1/1/1.1",
"port-id": "1/1/1", "port-id": "1/1/1",
"description": "Interface SYNC to eNODE-B", "description": "Interface SYNC to eNODE-B",
"status": {"admin-enabled": "true"}, "status": {"admin-enabled": "true"},
"vpn-network-access-type": "l3vpn-svc:point-to-point", "vpn-network-access-type": "l3vpn-svc:point-to-point",
"ip-connection": { "ip-connection": {
skipping to change at page 43, line 48 skipping to change at page 47, line 49
"routing-protocol": [ "routing-protocol": [
"id": "1", "id": "1",
"type": "l3vpn-svc:direct" "type": "l3vpn-svc:direct"
] ]
} }
} }
] ]
} }
} }
Figure 19: Create VPN Network Access Figure 21: Create VPN Network Access
9.2. Multicast VPN Provisioning Example 9.2. Multicast VPN Provisioning Example
IPTV is mainly distributed through multicast over the LANs. In the IPTV is mainly distributed through multicast over the LANs. In the
following example, PIM-SM is enabled and functional between the PE following example, PIM-SM is enabled and functional between the PE
and the CE. The PE receives multicast traffic from a CE that is and the CE. The PE receives multicast traffic from a CE that is
directly connected to the multicast source. The signaling between PE directly connected to the multicast source. The signaling between PE
and CE is achieved using BGP. Also, RP is statically configured for and CE is achieved using BGP. Also, RP is statically configured for
a multicast group. a multicast group.
+-----------+ +------+ +------+ +-----------+ +-----------+ +------+ +------+ +-----------+
| Multicast |---| CE |--/--| PE |----| Backbone | | Multicast |---| CE |--/--| PE |----| Backbone |
| source | +------+ +------+ | IP/MPLS | | source | +------+ +------+ | IP/MPLS |
+-----------+ +-----------+ +-----------+ +-----------+
Figure 20: Multicast L3VPN Service Example Figure 22: Multicast L3VPN Service Example
To configure a Multicast L3VPN service using the L3NM model the To configure a Multicast L3VPN service using the L3NM model the
procedure and the JSON with the data structure is the following: procedure and the JSON with the data structure is the following:
First, the multicast service is created (see the excerpt of the First, the multicast service is created (see the excerpt of the
request message body shown in Figure 21) request message body shown in Figure 23)
"vpn-services": { "vpn-services": {
"vpn-service": { "vpn-service": {
"vpn-id": "Multicast_IPTV", "vpn-id": "Multicast_IPTV",
"customer-name": "310", "customer-name": "310",
"vpn-service-topology": "hub-spoke", "vpn-service-topology": "hub-spoke",
"description": "Multicast IPTV VPN service" "description": "Multicast IPTV VPN service"
} }
} }
Figure 21: Create Multicast VPN Service (Excerpt of the Message Figure 23: Create Multicast VPN Service (Excerpt of the Message
Request Body) Request Body)
Then, the VPN nodes are created (see the excerpt of the request Then, the VPN nodes are created (see the excerpt of the request
message body shown in Figure 22). In this example, the VPN Node will message body shown in Figure 24). In this example, the VPN Node will
represent VRF configured in the physical device. represent VRF configured in the physical device.
"vpn-node": [ "vpn-node": [
"vpn-node-id": "500003105", "vpn-node-id": "500003105",
"ne-id": "10.250.2.202", "ne-id": "10.250.2.202",
"autonomous-system": "3816", "autonomous-system": "3816",
"description": "VRF_IPTV_MULTICAST", "description": "VRF_IPTV_MULTICAST",
"router-id": "10.250.2.202", "router-id": "10.250.2.202",
"address-family": "ipv4", "address-family": "ipv4",
"node-role": { "node-role": {
skipping to change at page 45, line 40 skipping to change at page 49, line 40
}, },
"rp-discovery": { "rp-discovery": {
"rp-discovery-type": { "rp-discovery-type": {
"l3vpn-svc:static-rp" "l3vpn-svc:static-rp"
} }
} }
} }
} }
] ]
Figure 22: Create Multicast VPN Node (Excerpt of the Message Request Figure 24: Create Multicast VPN Node (Excerpt of the Message Request
Body) Body)
Finally, create the VPN Network Access with Multicast enabled (see Finally, create the VPN Network Access with Multicast enabled (see
the excerpt of the request message body shown in Figure 23) the excerpt of the request message body shown in Figure 25)
"vpn-network-access": { "vpn-network-access": {
"vpn-network-access-id": "1/1/1", "vpn-network-access-id": "1/1/1",
"description": "Connected_to_source", "description": "Connected_to_source",
"status": { "admin-enabled": "true" }, "status": { "admin-enabled": "true" },
"vpn-network-access-type": { "vpn-network-access-type": {
"l3vpn-svc:point-to-point" "l3vpn-svc:point-to-point"
}, },
"ip-connection": { "ip-connection": {
"ipv4": { "ipv4": {
skipping to change at page 46, line 43 skipping to change at page 50, line 43
}, },
"service": { "service": {
"multicast": { "multicast": {
"multicast-site-type": "source-only", "multicast-site-type": "source-only",
"multicast-address-family": { "ipv4": "true" }, "multicast-address-family": { "ipv4": "true" },
"protocol-type": "router" "protocol-type": "router"
} }
} }
} }
Figure 23: Create VPN Network Access (Excerpt of the Message Request Figure 25: Create VPN Network Access (Excerpt of the Message Request
Body) Body)
10. L3NM YANG Module 10. L3NM YANG Module
<CODE BEGINS> file "ietf-l3vpn-ntw@2020-03.09.yang" <CODE BEGINS> file "ietf-l3vpn-ntw@2020-03.09.yang"
module ietf-l3vpn-ntw { module ietf-l3vpn-ntw {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw"; namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw";
prefix l3vpn-ntw; prefix l3vpn-ntw;
skipping to change at page 48, line 25 skipping to change at page 52, line 25
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices."; for full legal notices.";
revision 2020-03-09 { revision 2020-04-03 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A Layer 3 VPN Network YANG Model"; "RFC XXXX: A Layer 3 VPN Network YANG Model";
// RFC Ed.: replace XXXX with actual RFC number and remove
// this note
} }
/* Features */ /* Features */
feature msdp { feature msdp {
description description
"This feature indicates that msdp capabilities "This feature indicates that msdp capabilities
are supported by the VPN."; are supported by the VPN.";
} }
skipping to change at page 49, line 34 skipping to change at page 53, line 36
} }
feature vxlan { feature vxlan {
description description
"This feature indicates the support of "This feature indicates the support of
the 'vxlan' encapsulation."; the 'vxlan' encapsulation.";
} }
/* Typedefs */ /* Typedefs */
typedef protocols-type { typedef protocol-type {
type enumeration { type enumeration {
enum GRE { enum GRE {
value 0; value 0;
description description
"Transport based on GRE."; "Transport based on GRE.";
} }
enum LDP { enum LDP {
value 1; value 1;
description description
"Transport based on LDP."; "Transport based on LDP.";
skipping to change at page 56, line 24 skipping to change at page 60, line 27
} }
identity bw-type { identity bw-type {
description description
"Identity of the bandwidth type."; "Identity of the bandwidth type.";
} }
identity bw-per-cos { identity bw-per-cos {
base bw-type; base bw-type;
description description
"Bandwidth is per Class of Service (CoS)."; "Bandwidth is per CoS.";
} }
identity bw-per-port { identity bw-per-port {
base bw-type; base bw-type;
description description
"Bandwidth is per site network access."; "Bandwidth is per site network access.";
} }
identity bw-per-site { identity bw-per-site {
base bw-type; base bw-type;
skipping to change at page 56, line 50 skipping to change at page 61, line 5
identity bw-per-svc { identity bw-per-svc {
base bw-type; base bw-type;
description description
"Bandwidth is per VPN service."; "Bandwidth is per VPN service.";
} }
/* Groupings */ /* Groupings */
grouping svc-transport-encapsulation { grouping svc-transport-encapsulation {
container underlay-transport { container underlay-transport {
leaf type { leaf-list type {
type protocols-type; type protocol-type;
ordered-by user;
description description
"Protocols used to deliver an L3VPN service."; "Protocols used to deliver an L3VPN service.";
} }
description description
""; "Container for the Transport Underlay.";
} }
description description
""; "This grouping defines the type of underlay transport
for VPN service.";
} }
grouping multicast-rp-group-cfg { grouping multicast-rp-group-cfg {
choice group-format { choice group-format {
mandatory true; mandatory true;
case group-prefix { case group-prefix {
leaf group-address { leaf group-address {
type inet:ip-prefix; type inet:ip-prefix;
description description
"A single multicast group prefix."; "A single multicast group prefix.";
skipping to change at page 60, line 23 skipping to change at page 64, line 28
leaf rp-discovery-type { leaf rp-discovery-type {
type identityref { type identityref {
base l3vpn-svc:multicast-rp-discovery-type; base l3vpn-svc:multicast-rp-discovery-type;
} }
default "l3vpn-svc:static-rp"; default "l3vpn-svc:static-rp";
description description
"Type of RP discovery used."; "Type of RP discovery used.";
} }
container bsr-candidates { container bsr-candidates {
when "derived-from-or-self(../rp-discovery-type, " when "derived-from-or-self(../rp-discovery-type, "
+ "'l3vpn-ntw:bsr-rp')" { + "'l3vpn-svc:bsr-rp')" {
description description
"Only applicable if discovery type "Only applicable if discovery type
is BSR-RP."; is BSR-RP.";
} }
leaf-list bsr-candidate-address { leaf-list bsr-candidate-address {
type inet:ip-address; type inet:ip-address;
description description
"Address of candidate Bootstrap Router (BSR)."; "Address of candidate Bootstrap Router (BSR).";
} }
description description
skipping to change at page 66, line 41 skipping to change at page 70, line 44
"Identification of the class of service. "Identification of the class of service.
This identifier is internal to the administration."; This identifier is internal to the administration.";
} }
description description
"List of marking rules."; "List of marking rules.";
} }
description description
"Configuration of the traffic classification policy."; "Configuration of the traffic classification policy.";
} }
container qos-profile { container qos-profile {
choice qos-profile { list qos-profile {
key profile;
description description
"Choice for QoS profile. "QoS profile.
Can be standard profile or customized profile."; Can be standard profile or customized profile.";
case standard {
description
"Standard QoS profile.";
leaf profile { leaf profile {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-profiles/" path "/l3vpn-ntw/vpn-profiles/"
+ "valid-provider-identifiers" + "valid-provider-identifiers"
+ "/qos-profile-identifier/id"; + "/qos-profile-identifier/id";
} }
description description
"QoS profile to be used."; "QoS profile to be used.";
} }
leaf direction { leaf direction {
type identityref { type identityref {
base l3vpn-svc:qos-profile-direction; base l3vpn-svc:qos-profile-direction;
} }
default "l3vpn-svc:both"; default "l3vpn-svc:both";
description description
"The direction to which the QoS profile "The direction to which the QoS profile
is applied."; is applied.";
} }
}
case custom {
description
"Customized QoS profile.";
container classes {
if-feature "l3vpn-svc:qos-custom";
list class {
key "class-id";
leaf class-id {
type string;
description
"Identification of the class of service.
This identifier is internal to the
administration.";
}
leaf direction {
type identityref {
base l3vpn-svc:qos-profile-direction;
}
default "l3vpn-svc:both";
description
"The direction to which the QoS profile
is applied.";
}
leaf rate-limit {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units "percent";
description
"To be used if the class must be rate-limited.
Expressed as percentage of the service
bandwidth.";
}
container latency {
choice flavor {
case lowest {
leaf use-lowest-latency {
type empty;
description
"The traffic class should
use the path with the
lowest latency.";
}
}
case boundary {
leaf jitter-boundary {
type uint16;
units "msec";
default "400";
description
"The traffic class
should use a path with a
defined maximum latency.";
}
}
description
"Latency constraint
on the traffic class.";
}
description
"Latency constraint
on the traffic class.";
}
container jitter {
choice flavor {
case lowest {
leaf use-lowest-jitter {
type empty;
description
"The traffic class
should use the path with the
lowest jitter.";
}
}
case boundary {
leaf latency-boundary {
type uint32;
units "usec";
default "40000";
description
"The traffic class
should use a path with a
defined maximum jitter.";
}
}
description
"Jitter constraint on the traffic class.";
}
description
"Jitter constraint on the traffic class.";
}
container bandwidth {
leaf guaranteed-bw-percent {
type decimal64 {
fraction-digits 5;
range "0..100";
}
units "percent";
mandatory true;
description
"To be used to define the guaranteed bandwidth
as a percentage of the available service
bandwidth.";
}
leaf end-to-end {
type empty;
description
"Used if the bandwidth reservation
must be done on the MPLS network too.";
}
description
"Bandwidth constraint on the traffic class.";
}
description
"List of classes of services.";
}
description
"Container for list of classes of services.";
}
}
} }
description description
"QoS profile configuration."; "QoS profile configuration.";
} }
description description
"QoS configuration."; "QoS configuration.";
} }
description description
"This grouping defines QoS parameters for a site."; "This grouping defines QoS parameters for a site.";
} }
skipping to change at page 70, line 49 skipping to change at page 72, line 24
description description
"Encryption will occur at Layer 3. "Encryption will occur at Layer 3.
For example, IPsec may be used when For example, IPsec may be used when
a customer requests Layer 3 encryption."; a customer requests Layer 3 encryption.";
} }
} }
description description
"Layer on which encryption is applied."; "Layer on which encryption is applied.";
} }
description description
""; "Container for CE-PE security encryption.";
} }
container encryption-profile { container encryption-profile {
choice profile { choice profile {
case provider-profile { case provider-profile {
leaf profile-name { leaf profile-name {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-profiles/" path "/l3vpn-ntw/vpn-profiles/"
+ "valid-provider-identifiers" + "valid-provider-identifiers"
+ "/encryption-profile-identifier/id"; + "/encryption-profile-identifier/id";
} }
skipping to change at page 71, line 24 skipping to change at page 72, line 47
} }
} }
case customer-profile { case customer-profile {
leaf algorithm { leaf algorithm {
type string; type string;
description description
"Encryption algorithm to be used."; "Encryption algorithm to be used.";
} }
} }
description description
""; "Choice for encryption profile.";
} }
choice key-type { choice key-type {
default "psk"; default "psk";
case psk { case psk {
leaf preshared-key { leaf preshared-key {
type string; type string;
description description
"Pre-Shared Key (PSK) coming from the customer."; "Pre-Shared Key (PSK) coming from the customer.";
} }
} }
description description
"Choice of encryption profile. "Choice of encryption profile.
The encryption profile can be the provider profile The encryption profile can be the provider profile
or customer profile."; or customer profile.";
} }
description description
"This grouping defines encryption parameters for "Container for encryption profile.";
a site.";
} }
description description
""; "This grouping defines encryption parameters for
a site.";
} }
grouping site-routing { grouping site-routing {
container routing-protocols { container routing-protocols {
list routing-protocol { list routing-protocol {
key "id"; key "id";
leaf id { leaf id {
type string; type string;
description description
""; "Unique identifier for routing protocol.";
} }
leaf type { leaf type {
type identityref { type identityref {
base l3vpn-svc:routing-protocol-type; base l3vpn-svc:routing-protocol-type;
} }
description description
"Type of routing protocol."; "Type of routing protocol.";
} }
list routing-profiles { list routing-profiles {
key "id"; key "id";
skipping to change at page 72, line 36 skipping to change at page 74, line 11
} }
leaf type { leaf type {
type ie-type; type ie-type;
description description
"Import, export or both."; "Import, export or both.";
} }
description description
"Import or Export profile reference"; "Import or Export profile reference";
} }
container ospf { container ospf {
when "derived-from-or-self(../type, 'l3vpn-ntw:ospf')" { when "derived-from-or-self(../type, 'l3vpn-svc:ospf')" {
description description
"Only applies when protocol is OSPF."; "Only applies when protocol is OSPF.";
} }
if-feature "l3vpn-svc:rtg-ospf"; if-feature "l3vpn-svc:rtg-ospf";
leaf-list address-family { leaf-list address-family {
type l3vpn-svc:address-family; type l3vpn-svc:address-family;
min-elements 1; min-elements 1;
description description
"If OSPF is used on this site, this node "If OSPF is used on this site, this node
contains a configured value. This node contains a configured value. This node
skipping to change at page 74, line 11 skipping to change at page 75, line 34
description description
"Creates a sham link with another site."; "Creates a sham link with another site.";
} }
description description
"List of sham links."; "List of sham links.";
} }
description description
"OSPF-specific configuration."; "OSPF-specific configuration.";
} }
container bgp { container bgp {
when "derived-from-or-self(../type, 'l3vpn-ntw:bgp')" { when "derived-from-or-self(../type, 'l3vpn-svc:bgp')" {
description description
"Only applies when protocol is BGP."; "Only applies when protocol is BGP.";
} }
if-feature "l3vpn-svc:rtg-bgp"; if-feature "l3vpn-svc:rtg-bgp";
leaf peer-autonomous-system { leaf peer-autonomous-system {
type inet:as-number; type inet:as-number;
mandatory true; mandatory true;
description description
"Customer AS number in case the customer "Customer AS number in case the customer
requests BGP routing."; requests BGP routing.";
skipping to change at page 76, line 30 skipping to change at page 78, line 5
} }
default "active"; default "active";
description description
"ISIS interface mode type."; "ISIS interface mode type.";
} }
uses status-params; uses status-params;
description description
"ISIS-specific configuration."; "ISIS-specific configuration.";
} }
container static { container static {
when "derived-from-or-self(../type, 'l3vpn-ntw:static')" { when "derived-from-or-self(../type, 'l3vpn-svc:static')" {
description description
"Only applies when protocol is static. "Only applies when protocol is static.
BGP activation requires the SP to know BGP activation requires the SP to know
the address of the customer peer. When the address of the customer peer. When
BGP is enabled, the 'static-address' BGP is enabled, the 'static-address'
allocation type for the IP connection allocation type for the IP connection
MUST be used."; MUST be used.";
} }
container cascaded-lan-prefixes { container cascaded-lan-prefixes {
list ipv4-lan-prefixes { list ipv4-lan-prefixes {
skipping to change at page 77, line 42 skipping to change at page 79, line 16
description description
"List of LAN prefixes for the site."; "List of LAN prefixes for the site.";
} }
description description
"LAN prefixes from the customer."; "LAN prefixes from the customer.";
} }
description description
"Configuration specific to static routing."; "Configuration specific to static routing.";
} }
container rip { container rip {
when "derived-from-or-self(../type, 'l3vpn-ntw:rip')" { when "derived-from-or-self(../type, 'l3vpn-svc:rip')" {
description description
"Only applies when the protocol is RIP. For IPv4, "Only applies when the protocol is RIP. For IPv4,
the model assumes that RIP version 2 is used."; the model assumes that RIP version 2 is used.";
} }
if-feature "l3vpn-svc:rtg-rip"; if-feature "l3vpn-svc:rtg-rip";
leaf-list address-family { leaf-list address-family {
type l3vpn-svc:address-family; type l3vpn-svc:address-family;
min-elements 1; min-elements 1;
description description
"If RIP is used on this site, this node "If RIP is used on this site, this node
contains a configured value. This node contains a configured value. This node
contains at least one address family contains at least one address family
to be activated."; to be activated.";
} }
description description
"Configuration specific to RIP routing."; "Configuration specific to RIP routing.";
} }
container vrrp { container vrrp {
when "derived-from-or-self(../type, 'l3vpn-ntw:vrrp')" { when "derived-from-or-self(../type, 'l3vpn-svc:vrrp')" {
description description
"Only applies when protocol is VRRP."; "Only applies when protocol is VRRP.";
} }
if-feature "l3vpn-svc:rtg-vrrp"; if-feature "l3vpn-svc:rtg-vrrp";
leaf-list address-family { leaf-list address-family {
type l3vpn-svc:address-family; type l3vpn-svc:address-family;
min-elements 1; min-elements 1;
description description
"If VRRP is used on this site, this node "If VRRP is used on this site, this node
contains a configured value. This node contains contains a configured value. This node contains
skipping to change at page 78, line 47 skipping to change at page 80, line 22
} }
grouping site-attachment-ip-connection { grouping site-attachment-ip-connection {
container ip-connection { container ip-connection {
container ipv4 { container ipv4 {
if-feature "l3vpn-svc:ipv4"; if-feature "l3vpn-svc:ipv4";
leaf address-allocation-type { leaf address-allocation-type {
type identityref { type identityref {
base l3vpn-svc:address-allocation-type; base l3vpn-svc:address-allocation-type;
} }
must "not(derived-from-or-self(current(), 'l3vpn-ntw:slaac')" must "not(derived-from-or-self(current(), 'l3vpn-svc:slaac')"
+ " or derived-from-or-self(current(), " + " or derived-from-or-self(current(), "
+ "'l3vpn-ntw:provider-dhcp-slaac'))" { + "'l3vpn-svc:provider-dhcp-slaac'))" {
error-message "SLAAC is only applicable to IPv6"; error-message "SLAAC is only applicable to IPv6";
} }
description description
"Defines how addresses are allocated. "Defines how addresses are allocated.
If there is no value for the address If there is no value for the address
allocation type, then IPv4 is not enabled."; allocation type, then IPv4 is not enabled.";
} }
container provider-dhcp { container provider-dhcp {
when "derived-from-or-self(../address-allocation-type, " when "derived-from-or-self(../address-allocation-type, "
+ "'l3vpn-ntw:provider-dhcp')" { + "'l3vpn-svc:provider-dhcp')" {
description description
"Only applies when addresses are allocated by DHCP."; "Only applies when addresses are allocated by DHCP.";
} }
leaf provider-address { leaf provider-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"Address of provider side. If provider-address is not "Address of provider side. If provider-address is not
specified, then prefix length should not be specified specified, then prefix length should not be specified
either. It also implies provider-dhcp allocation is either. It also implies provider-dhcp allocation is
not enabled. If provider-address is specified, then not enabled. If provider-address is specified, then
skipping to change at page 80, line 48 skipping to change at page 82, line 23
} }
} }
description description
"Choice for the way to assign addresses."; "Choice for the way to assign addresses.";
} }
description description
"DHCP allocated addresses related parameters."; "DHCP allocated addresses related parameters.";
} }
container dhcp-relay { container dhcp-relay {
when "derived-from-or-self(../address-allocation-type, " when "derived-from-or-self(../address-allocation-type, "
+ "'l3vpn-ntw:provider-dhcp-relay')" { + "'l3vpn-svc:provider-dhcp-relay')" {
description description
"Only applies when provider is required to implement "Only applies when provider is required to implement
DHCP relay function."; DHCP relay function.";
} }
leaf provider-address { leaf provider-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"Address of provider side. If provider-address is not "Address of provider side. If provider-address is not
specified, then prefix length should not be specified specified, then prefix length should not be specified
either. It also implies provider-dhcp allocation is either. It also implies provider-dhcp allocation is
skipping to change at page 81, line 45 skipping to change at page 83, line 20
"IP address of customer DHCP server."; "IP address of customer DHCP server.";
} }
description description
"Container for list of customer DHCP servers."; "Container for list of customer DHCP servers.";
} }
description description
"DHCP relay provided by operator."; "DHCP relay provided by operator.";
} }
container static-addresses { container static-addresses {
when "derived-from-or-self(../address-allocation-type, " when "derived-from-or-self(../address-allocation-type, "
+ "'l3vpn-ntw:static-address')" { + "'l3vpn-svc:static-address')" {
description description
"Only applies when protocol allocation type is static."; "Only applies when protocol allocation type is static.";
} }
leaf primary-address { leaf primary-address {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/" path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/"
+ "vpn-node/vpn-network-accesses/vpn-network-access/" + "vpn-node/vpn-network-accesses/vpn-network-access/"
+ "ip-connection/ipv4/static-addresses/address/" + "ip-connection/ipv4/static-addresses/address/"
+ "address-id"; + "address-id";
} }
skipping to change at page 83, line 14 skipping to change at page 84, line 38
base l3vpn-svc:address-allocation-type; base l3vpn-svc:address-allocation-type;
} }
description description
"Defines how addresses are allocated. "Defines how addresses are allocated.
If there is no value for the address If there is no value for the address
allocation type, then IPv6 is allocation type, then IPv6 is
not enabled."; not enabled.";
} }
container provider-dhcp { container provider-dhcp {
when "derived-from-or-self(../address-allocation-type, " when "derived-from-or-self(../address-allocation-type, "
+ "'l3vpn-ntw:provider-dhcp') " + "'l3vpn-svc:provider-dhcp') "
+ "or derived-from-or-self(../address-allocation-type, " + "or derived-from-or-self(../address-allocation-type, "
+ "'l3vpn-ntw:provider-dhcp-slaac')" { + "'l3vpn-svc:provider-dhcp-slaac')" {
description description
"Only applies when addresses are allocated by DHCP."; "Only applies when addresses are allocated by DHCP.";
} }
leaf provider-address { leaf provider-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"Address of the provider side. If provider-address "Address of the provider side. If provider-address
is not specified, then prefix length should not be is not specified, then prefix length should not be
specified either. It also implies provider-dhcp specified either. It also implies provider-dhcp
allocation is not enabled. If provider-address is allocation is not enabled. If provider-address is
skipping to change at page 85, line 4 skipping to change at page 86, line 27
description description
"Container for customer addresses allocated "Container for customer addresses allocated
by DHCP."; by DHCP.";
} }
} }
description description
"Choice for the way to assign addresses."; "Choice for the way to assign addresses.";
} }
description description
"DHCP allocated addresses related parameters."; "DHCP allocated addresses related parameters.";
} }
container dhcp-relay { container dhcp-relay {
when "derived-from-or-self(../address-allocation-type, " when "derived-from-or-self(../address-allocation-type, "
+ "'l3vpn-ntw:provider-dhcp-relay')" { + "'l3vpn-svc:provider-dhcp-relay')" {
description description
"Only applies when the provider is required "Only applies when the provider is required
to implement DHCP relay function."; to implement DHCP relay function.";
} }
leaf provider-address { leaf provider-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"Address of the provider side. If provider-address "Address of the provider side. If provider-address
is not specified, then prefix length should not be is not specified, then prefix length should not be
specified either. It also implies provider-dhcp specified either. It also implies provider-dhcp
skipping to change at page 86, line 4 skipping to change at page 87, line 27
type inet:ipv6-address; type inet:ipv6-address;
description description
"This node contains the IP address of "This node contains the IP address of
the customer DHCP server. If the DHCP relay the customer DHCP server. If the DHCP relay
function is implemented by the function is implemented by the
provider, this node contains the provider, this node contains the
configured value."; configured value.";
} }
description description
"Container for list of customer DHCP servers."; "Container for list of customer DHCP servers.";
} }
description description
"DHCP relay provided by operator."; "DHCP relay provided by operator.";
} }
container static-addresses { container static-addresses {
when "derived-from-or-self(../address-allocation-type, " when "derived-from-or-self(../address-allocation-type, "
+ "'l3vpn-ntw:static-address')" { + "'l3vpn-svc:static-address')" {
description description
"Only applies when protocol allocation type is static."; "Only applies when protocol allocation type is static.";
} }
leaf primary-address { leaf primary-address {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/" path "/l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/"
+ "vpn-node/vpn-network-accesses/vpn-network-access/" + "vpn-node/vpn-network-accesses/vpn-network-access/"
+ "ip-connection/ipv6/static-addresses/address/" + "ip-connection/ipv6/static-addresses/address/"
+ "address-id"; + "address-id";
} }
skipping to change at page 87, line 29 skipping to change at page 89, line 4
description description
"If true, BFD activation is required."; "If true, BFD activation is required.";
} }
choice holdtime { choice holdtime {
default "fixed"; default "fixed";
case fixed { case fixed {
leaf fixed-value { leaf fixed-value {
type uint32; type uint32;
units "msec"; units "msec";
description description
"Expected BFD holdtime expressed in msec. The customer "Expected BFD holdtime expressed in msec. The customer
may impose some fixed values for the holdtime period may impose some fixed values for the holdtime period
if the provider allows the customer use this function. if the provider allows the customer use this function.
If the provider doesn't allow the customer to use this If the provider doesn't allow the customer to use this
function, the fixed-value will not be set."; function, the fixed-value will not be set.";
} }
} }
case profile { case profile {
leaf profile-name { leaf profile-name {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-profiles/valid-provider-identifiers/" path "/l3vpn-ntw/vpn-profiles/"
+ "valid-provider-identifiers/"
+ "bfd-profile-identifier/id"; + "bfd-profile-identifier/id";
} }
description description
"Well-known SP profile name. The provider can propose "Well-known SP profile name. The provider can propose
some profiles to the customer, depending on the service some profiles to the customer, depending on the
level the customer wants to achieve. Profile names service level the customer wants to achieve.
must be communicated to the customer."; Profile names must be communicated to the customer.";
} }
description description
"Well-known SP profile."; "Well-known SP profile.";
} }
description description
"Choice for holdtime flavor."; "Choice for holdtime flavor.";
} }
description description
"Container for BFD."; "Container for BFD.";
} }
skipping to change at page 91, line 24 skipping to change at page 92, line 47
type l3vpn-svc:svc-id; type l3vpn-svc:svc-id;
description description
"Identifies the target VPN the local VPN want to access."; "Identifies the target VPN the local VPN want to access.";
} }
leaf local-sites-role { leaf local-sites-role {
type identityref { type identityref {
base l3vpn-svc:site-role; base l3vpn-svc:site-role;
} }
default "l3vpn-svc:any-to-any-role"; default "l3vpn-svc:any-to-any-role";
description description
"This describes the role of the "This describes the role of the
local sites in the target VPN topology. In the any-to-any VPN local sites in the target VPN topology.
service topology, the local sites must have the same role, which In the any-to-any VPN service topology,
will be 'any-to-any-role'. In the Hub-and-Spoke VPN service the local sites must have the same role, which
topology or the Hub-and-Spoke disjoint VPN service topology, will be 'any-to-any-role'. In the Hub-and-Spoke
the local sites must have a Hub role or a Spoke role."; VPN service topology or the Hub-and-Spoke
disjoint VPN service topology,
the local sites must have a Hub role or a Spoke role.";
} }
description description
"List of extranet VPNs or target VPNs the local VPN is "List of extranet VPNs or target VPNs the local VPN is
attached to."; attached to.";
} }
description description
"Container for extranet VPN configuration."; "Container for extranet VPN configuration.";
} }
description description
"Grouping for extranet VPN configuration. "Grouping for extranet VPN configuration.
skipping to change at page 92, line 51 skipping to change at page 94, line 29
"List for BFD Profile identifiers."; "List for BFD Profile identifiers.";
} }
list routing-profile-identifier { list routing-profile-identifier {
key "id"; key "id";
leaf id { leaf id {
type string; type string;
description description
"Identification of the routing Profile to be used "Identification of the routing Profile to be used
by the routing-protocols within sites, vpn- by the routing-protocols within sites, vpn-
network-accesses or vpn-nodes for refering network-accesses or vpn-nodes for refering
vrf-import/export policies. vrf-import/export policies.
This identifier has a local meaning."; This identifier has a local meaning.";
} }
description description
"List for Routing Profile Identifiers."; "List for Routing Profile Identifiers.";
} }
nacm:default-deny-write; nacm:default-deny-write;
description description
"Container for Valid Provider Identifies."; "Container for Valid Provider Identifies.";
} }
description description
"Grouping for VPN Profile configuration."; "Grouping for VPN Profile configuration.";
} }
grouping vpn-svc-cfg { grouping vpn-svc-cfg {
leaf vpn-id { leaf vpn-id {
type l3vpn-svc:svc-id; type l3vpn-svc:svc-id;
description description
"VPN identifier. "VPN identifier.
This identifier has a local meaning."; This identifier has a local meaning.";
} }
leaf l3sm-vpn-id { leaf l3sm-vpn-id {
type l3vpn-svc:svc-id; type l3vpn-svc:svc-id;
description description
"Pointer to the L3SM service."; "Pointer to the L3SM service.";
} }
leaf customer-name { leaf customer-name {
type string; type string;
description description
"Name of the customer that actually uses the VPN service. "Name of the customer that actually uses the VPN service.
In the case that any intermediary (e.g., Tier-2 provider In the case that any intermediary (e.g., Tier-2 provider
or partner) sells the VPN service to their end user or partner) sells the VPN service to their end user
on behalf of the original service provider (e.g., Tier-1 on behalf of the original service provider (e.g., Tier-1
provider), the original service provider may require the provider), the original service provider may require the
customer name to provide smooth activation/commissioning customer name to provide smooth activation/commissioning
and operation for the service."; and operation for the service.";
} }
leaf vpn-service-topology { leaf vpn-service-topology {
type identityref { type identityref {
base vpn-topology; base vpn-topology;
} }
default "any-to-any"; default "any-to-any";
description description
"VPN service topology."; "VPN service topology.";
} }
leaf description { leaf description {
skipping to change at page 98, line 24 skipping to change at page 99, line 49
description description
"Administrative Status UP/DOWN"; "Administrative Status UP/DOWN";
} }
leaf oper-status { leaf oper-status {
type operational-type; type operational-type;
config false; config false;
description description
"Operations status"; "Operations status";
} }
description description
""; "Container for status parameters.";
} }
description description
"Grouping used to join operational and administrative status "Grouping used to join operational and administrative status
is re used in the Site Network Acess and in the VPN-Node"; is re used in the Site Network Acess and in the VPN-Node";
} }
/* Parameters related to vpn-nodes (VRF config.) */ /* Parameters related to vpn-nodes (VRF config.) */
grouping vpn-nodes-params { grouping vpn-nodes-params {
container vpn-nodes { container vpn-nodes {
description description
""; "Container for VPN nodes.";
list vpn-node { list vpn-node {
key "ne-id"; key "ne-id";
leaf vpn-node-id { leaf vpn-node-id {
type union { type union {
type l3vpn-svc:svc-id; type l3vpn-svc:svc-id;
type uint32; type uint32;
} }
description description
"Type STRING or NUMBER Serivice-Id"; "Type STRING or NUMBER Serivice-Id";
} }
leaf local-autonomous-system { leaf local-autonomous-system {
type inet:as-number; type inet:as-number;
description description
"Provider AS number in case the customer "Provider AS number in case the customer
requests BGP routing."; requests BGP routing.";
} }
leaf description { leaf description {
type string; type string;
description description
"Textual description of a VPN node."; "Textual description of the VPN node.";
} }
leaf ne-id { leaf ne-id {
type string; type string;
description description
""; "Unique identifier of the network element
where the vpn-node is deployed.";
} }
leaf router-id { leaf router-id {
type inet:ip-address; type inet:ip-address;
description description
"router-id information can be ipv4/6 addresses"; "router-id information can be ipv4/6 addresses";
} }
leaf address-family { leaf address-family {
type l3vpn-svc:address-family; type l3vpn-svc:address-family;
description description
"Address family used for router-id information."; "Address family used for router-id information.";
skipping to change at page 99, line 43 skipping to change at page 101, line 21
uses status-params; uses status-params;
uses net-acc; uses net-acc;
uses site-maximum-routes; uses site-maximum-routes;
uses vpn-service-multicast; uses vpn-service-multicast;
leaf node-ie-profile { leaf node-ie-profile {
type leafref { type leafref {
path "/l3vpn-ntw/vpn-services/" path "/l3vpn-ntw/vpn-services/"
+ "vpn-service/ie-profiles/ie-profile/ie-profile-id"; + "vpn-service/ie-profiles/ie-profile/ie-profile-id";
} }
description description
""; "node Import/Export profile.";
} }
description description
""; "List for VPN node.";
} }
} }
description description
"Grouping to define VRF-specific configuration."; "Grouping to define VRF-specific configuration.";
} }
/* Parameters related to import and export profiles (RTs RDs.) */ /* Parameters related to import and export profiles (RTs RDs.) */
grouping ie-profiles-params { grouping ie-profiles-params {
container ie-profiles { container ie-profiles {
list ie-profile { list ie-profile {
key "ie-profile-id"; key "ie-profile-id";
leaf ie-profile-id { leaf ie-profile-id {
type string; type string;
description description
""; "IE profile id.";
} }
uses rt-rd; uses rt-rd;
description description
""; "List for Imort/Export profile.";
} }
description description
""; "Container for Import/Export profiles.";
} }
description description
"Grouping to specify rules for route import and export"; "Grouping to specify rules for route import and export";
} }
grouping pseudowire-params { grouping pseudowire-params {
container pseudowire { container pseudowire {
/*leaf far-end {*/ /*leaf far-end {*/
/* description "IP of the remote peer of the pseudowire.";*/ /* description "IP of the remote peer of the pseudowire.";*/
/* type inet:ip-address;*/ /* type inet:ip-address;*/
/*}*/ /*}*/
leaf vcid { leaf vcid {
type uint32; type uint32;
description description
"PW or VC identifier."; "PW or VC identifier.";
skipping to change at page 102, line 4 skipping to change at page 103, line 30
grouping ethernet-params { grouping ethernet-params {
container connection { container connection {
leaf encapsulation-type { leaf encapsulation-type {
type identityref { type identityref {
base encapsulation-type; base encapsulation-type;
} }
default "untagged-int"; default "untagged-int";
description description
"Encapsulation type. By default, the "Encapsulation type. By default, the
encapsulation type is set to 'untagged'."; encapsulation type is set to 'untagged'.";
} }
container logical-interface { container logical-interface {
leaf peer-reference { leaf peer-reference {
type uint32; type uint32;
description description
"Specify the associated logical peer interface."; "Specify the associated logical peer
interface";
} }
description description
"Reference of a logical interface type."; "Reference of a logical interface type.";
} }
container tagged-interface { container tagged-interface {
leaf type { leaf type {
type identityref { type identityref {
base tagged-inf-type; base tagged-inf-type;
} }
default "priority-tagged"; default "priority-tagged";
skipping to change at page 105, line 42 skipping to change at page 107, line 21
} }
description description
"Encapsulation types"; "Encapsulation types";
} }
description description
"Grouping to define encapsulation types"; "Grouping to define encapsulation types";
} }
grouping rt-rd { grouping rt-rd {
leaf rd { leaf rd {
type union {
type rt-types:route-distinguisher; type rt-types:route-distinguisher;
type empty;
}
description description
""; "Route distinguisher value. If this leaf has not been
configured, the server will auto-assign a route
distinguisher value and use that value operationally.
This calculated value is available in the operational
state. Use the empty type to indicate rd has no value
and is not to be aouto-assigned";
} }
container vpn-targets { container vpn-targets {
description description
"Set of route-targets to match for import and export routes "Set of route-targets to match for import and export routes
to/from VRF"; to/from VRF";
//uses rt-types:vpn-route-targets; //uses rt-types:vpn-route-targets;
uses vpn-route-targets; uses vpn-route-targets;
} }
description description
""; "Grouping for RT and RD.";
} }
grouping vpn-route-targets { grouping vpn-route-targets {
description description
"A grouping that specifies Route Target import-export rules "A grouping that specifies Route Target import-export rules
used in a BGP-enabled VPN."; used in a BGP-enabled VPN.";
list vpn-target { list vpn-target {
key "id"; key "id";
leaf id { leaf id {
type int8; type int8;
skipping to change at page 108, line 18 skipping to change at page 110, line 4
container vpn-services { container vpn-services {
list vpn-service { list vpn-service {
key "vpn-id"; key "vpn-id";
uses service-status; uses service-status;
uses vpn-svc-cfg; uses vpn-svc-cfg;
description description
"List of VPN services."; "List of VPN services.";
} }
description description
"Top-level container for the VPN services."; "Top-level container for the VPN services.";
} }
description description
"Main container for L3VPN service configuration."; "Main container for L3VPN services management.";
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 24 Figure 26
11. IANA Considerations 11. IANA Considerations
This document requests IANA to register the following URI in the "ns" This document requests IANA to register the following URI in the "ns"
subregistry within the "IETF XML Registry" [RFC3688]: subregistry within the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw
Registrant Contact: The IESG. Registrant Contact: The IESG.
skipping to change at page 112, line 31 skipping to change at page 114, line 17
[I-D.evenwu-opsawg-yang-composed-vpn] [I-D.evenwu-opsawg-yang-composed-vpn]
Even, R., Bo, W., Wu, Q., and Y. Cheng, "YANG Data Model Even, R., Bo, W., Wu, Q., and Y. Cheng, "YANG Data Model
for Composed VPN Service Delivery", draft-evenwu-opsawg- for Composed VPN Service Delivery", draft-evenwu-opsawg-
yang-composed-vpn-03 (work in progress), March 2019. yang-composed-vpn-03 (work in progress), March 2019.
[I-D.ietf-idr-bgp-model] [I-D.ietf-idr-bgp-model]
Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
YANG Model for Service Provider Networks", draft-ietf-idr- YANG Model for Service Provider Networks", draft-ietf-idr-
bgp-model-08 (work in progress), February 2020. bgp-model-08 (work in progress), February 2020.
[I-D.ietf-pim-yang]
Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu,
Y., and f. hu, "A YANG Data Model for Protocol Independent
Multicast (PIM)", draft-ietf-pim-yang-17 (work in
progress), May 2018.
[I-D.ietf-rtgwg-qos-model] [I-D.ietf-rtgwg-qos-model]
Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., Choudhary, A., Jethanandani, M., Strahle, N., Aries, E.,
and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos- and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos-
model-00 (work in progress), October 2019. model-00 (work in progress), October 2019.
[I-D.liu-pim-yang]
Liu, Y., Guo, F., and M. Sivakumar, "YANG Data Model for
PIM", draft-liu-pim-yang-01 (work in progress), March
2015.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005, DOI 10.17487/RFC4026, March 2005,
<https://www.rfc-editor.org/info/rfc4026>. <https://www.rfc-editor.org/info/rfc4026>.
[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K.,
and A. Gonguet, "Framework for Layer 3 Virtual Private and A. Gonguet, "Framework for Layer 3 Virtual Private
Networks (L3VPN) Operations and Management", RFC 4176, Networks (L3VPN) Operations and Management", RFC 4176,
DOI 10.17487/RFC4176, October 2005, DOI 10.17487/RFC4176, October 2005,
<https://www.rfc-editor.org/info/rfc4176>. <https://www.rfc-editor.org/info/rfc4176>.
skipping to change at page 117, line 15 skipping to change at page 119, line 4
| | +--rw auth-key? string | | +--rw auth-key? string
| +--rw static | +--rw static
| | +--rw cascaded-lan-prefixes | | +--rw cascaded-lan-prefixes
| | +--rw ipv4-lan-prefixes* {ipv4}? | | +--rw ipv4-lan-prefixes* {ipv4}?
| | | +--rw lan inet:ipv4-prefix | | | +--rw lan inet:ipv4-prefix
| | | +--rw lan-tag? string | | | +--rw lan-tag? string
| | | +--rw next-hop inet:ipv4-address | | | +--rw next-hop inet:ipv4-address
+--rw node-id? leafreaf +--rw node-id? leafreaf
+--rw service-id? leafreaf +--rw service-id? leafreaf
+--rw access-group-id? yang:uuid +--rw access-group-id? yang:uuid
Figure 27
Figure 25
Use Cases we have implemented include: Use Cases we have implemented include:
(a).Create VPN (a).Create VPN
(b).Create Site (b).Create Site
(c).Create/add bearers to an existing Site (c).Create/add bearers to an existing Site
(d).Create/Include Site Network Access into VPN nodes. (d).Create/Include Site Network Access into VPN nodes.
skipping to change at page 118, line 33 skipping to change at page 120, line 20
of the model are supported. of the model are supported.
The current implementation is proprietary, so under no terms the The current implementation is proprietary, so under no terms the
current implementation can be used. current implementation can be used.
Contact information: Janne Karvonen (JKarvonen@infinera.com) Contact information: Janne Karvonen (JKarvonen@infinera.com)
26 October is the date when information about this particular 26 October is the date when information about this particular
implementation was last updated. implementation was last updated.
A.4. Ribbon-ECI Implementation
Ribbon-ECI Controller (Muse) has multilayer provisioning abilities
from the optical layer up to the IP layer. With respect to ATCN
hierarchy model, Ribbon-ECI controller can be placed in at the level
of MDSC and serve as a service orchestrator or at the level of PNC as
a SDN controller. Additional information can be found at
https://www.ecitele.com/muse-network-service-apps/ The L3VPN
Fulfillment component, which is currently in beta maturity level, is
designed to support L3SM (RFC8299) for L3VPN service creation and
activation, is implemented with a data model similar to the L3NM and
translates it to the device model (ietf-routing-instance and ietf-
interfaces).
In addition, the L3VPN Fulfillment component interface include REST
API with the following methods:
o Create service
o Edit service
o Get service details
o Delete service
o Notification (registration based)
L3NM model coverage (several augmentations and deviations applied):
o vpn-service
o vpn-id
o uuid
o vpn-service-topology
o customer-name
o description
o slice-id
o service-status
o vpn-nodes
o ne-id
o vpn-node-id
o uuid
o autonomous-system
o rd
o vpn-targets
o vpn-network-accesses
o tunnel-policy
o export-policy
o routing protocol
o bgp
o static
o vpn-network-access
o vpn-network-access-id
o uuid
o statu
o connection
o tagged-interface
o cvlan-id
o ip-connection
o dhcp-relay
o static-addresses
o service
o qos-profile
o bw-profile
Authors' Addresses Authors' Addresses
Samier Barguil Samier Barguil
Telefonica Telefonica
Madrid Madrid
ES ES
Email: samier.barguilgiraldo.ext@telefonica.com Email: samier.barguilgiraldo.ext@telefonica.com
Oscar Gonzalez de Dios (editor) Oscar Gonzalez de Dios (editor)
skipping to change at page 119, line 4 skipping to change at page 122, line 35
ES ES
Email: samier.barguilgiraldo.ext@telefonica.com Email: samier.barguilgiraldo.ext@telefonica.com
Oscar Gonzalez de Dios (editor) Oscar Gonzalez de Dios (editor)
Telefonica Telefonica
Madrid Madrid
ES ES
Email: oscar.gonzalezdedios@telefonica.com Email: oscar.gonzalezdedios@telefonica.com
Mohamed Boucadair Mohamed Boucadair
Orange Orange
FR France
Email: "mohamed.boucadair@orange.com Email: "mohamed.boucadair@orange.com
Luis Angel Munoz Luis Angel Munoz
Vodafone Vodafone
ES ES
Email: luis-angel.munoz@vodafone.com Email: luis-angel.munoz@vodafone.com
Alejandro Aguado Alejandro Aguado
Nokia Nokia
Madrid Madrid
ES ES
Email: alejandro.aguado_martin@nokia.com Email: alejandro.aguado_martin@nokia.com
 End of changes. 124 change blocks. 
359 lines changed or deleted 469 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/