rfc8049.original   rfc8049.txt 
L3SM Working Group S. Litkowski Internet Engineering Task Force (IETF) S. Litkowski
Internet-Draft Orange Business Services Request for Comments: 8049 Orange Business Services
Intended status: Standards Track L. Tomotaki Category: Standards Track L. Tomotaki
Expires: May 8, 2017 Verizon ISSN: 2070-1721 Verizon
K. Ogaki K. Ogaki
KDDI KDDI
November 04, 2016 February 2017
YANG Data Model for L3VPN service delivery YANG Data Model for L3VPN Service Delivery
draft-ietf-l3sm-l3vpn-service-model-19
Abstract Abstract
This document defines a YANG data model that can be used for This document defines a YANG data model that can be used for
communication between customers and network operators and to deliver communication between customers and network operators and to deliver
a Layer 3 Provider Provisioned VPN service. The document is limited a Layer 3 provider-provisioned VPN service. This document is limited
to the BGP PE-based VPNs as described in [RFC4026], [RFC4110] and to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This
[RFC4364]. This model is intended to be instantiated at management model is intended to be instantiated at the management system to
system to deliver the overall service. This model is not a deliver the overall service. It is not a configuration model to be
configuration model to be used directly on network elements. This used directly on network elements. This model provides an abstracted
model provides an abstracted view of the Layer 3 IPVPN service view of the Layer 3 IP VPN service configuration components. It will
configuration components. It will be up to a management system to be up to the management system to take this model as input and use
take this as an input and use specific configurations models to specific configuration models to configure the different network
configure the different network elements to deliver the service. How elements to deliver the service. How the configuration of network
configuration of network elements is done is out of scope of the elements is done is out of scope for this document.
document.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc8049.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Layer 3 IP VPN service model . . . . . . . . . . . . . . . . 7 4. Layer 3 IP VPN Service Model . . . . . . . . . . . . . . . . 7
5. Service data model usage . . . . . . . . . . . . . . . . . . 8 5. Service Data Model Usage . . . . . . . . . . . . . . . . . . 8
6. Design of the Data Model . . . . . . . . . . . . . . . . . . 9 6. Design of the Data Model . . . . . . . . . . . . . . . . . . 9
6.1. Features and augmentation . . . . . . . . . . . . . . . . 16 6.1. Features and Augmentation . . . . . . . . . . . . . . . . 16
6.2. VPN service overview . . . . . . . . . . . . . . . . . . 17 6.2. VPN Service Overview . . . . . . . . . . . . . . . . . . 17
6.2.1. VPN service topology . . . . . . . . . . . . . . . . 17 6.2.1. VPN Service Topology . . . . . . . . . . . . . . . . 17
6.2.1.1. Route Target allocation . . . . . . . . . . . . . 17 6.2.1.1. Route Target Allocation . . . . . . . . . . . . . 17
6.2.1.2. Any to any . . . . . . . . . . . . . . . . . . . 18 6.2.1.2. Any-to-Any . . . . . . . . . . . . . . . . . . . 18
6.2.1.3. Hub and Spoke . . . . . . . . . . . . . . . . . . 18 6.2.1.3. Hub and Spoke . . . . . . . . . . . . . . . . . . 18
6.2.1.4. Hub and Spoke disjoint . . . . . . . . . . . . . 19 6.2.1.4. Hub and Spoke Disjoint . . . . . . . . . . . . . 19
6.2.2. Cloud access . . . . . . . . . . . . . . . . . . . . 20 6.2.2. Cloud Access . . . . . . . . . . . . . . . . . . . . 20
6.2.3. Multicast service . . . . . . . . . . . . . . . . . . 22 6.2.3. Multicast Service . . . . . . . . . . . . . . . . . . 22
6.2.4. Extranet VPNs . . . . . . . . . . . . . . . . . . . . 24 6.2.4. Extranet VPNs . . . . . . . . . . . . . . . . . . . . 24
6.3. Site overview . . . . . . . . . . . . . . . . . . . . . . 25 6.3. Site Overview . . . . . . . . . . . . . . . . . . . . . . 25
6.3.1. Devices and locations . . . . . . . . . . . . . . . . 26 6.3.1. Devices and Locations . . . . . . . . . . . . . . . . 26
6.3.2. Site network accesses . . . . . . . . . . . . . . . . 27 6.3.2. Site Network Accesses . . . . . . . . . . . . . . . . 27
6.3.2.1. Bearer . . . . . . . . . . . . . . . . . . . . . 28 6.3.2.1. Bearer . . . . . . . . . . . . . . . . . . . . . 28
6.3.2.2. Connection . . . . . . . . . . . . . . . . . . . 28 6.3.2.2. Connection . . . . . . . . . . . . . . . . . . . 28
6.3.2.3. Inheritance of parameters between site and site- 6.3.2.3. Inheritance of Parameters Defined at Site Level
network-access . . . . . . . . . . . . . . . . . 29 and Site Network Access Level . . . . . . . . . . 29
6.4. Site role . . . . . . . . . . . . . . . . . . . . . . . . 30 6.4. Site Role . . . . . . . . . . . . . . . . . . . . . . . . 30
6.5. Site belonging to multiple VPNs . . . . . . . . . . . . . 30 6.5. Site Belonging to Multiple VPNs . . . . . . . . . . . . . 30
6.5.1. Site vpn flavor . . . . . . . . . . . . . . . . . . . 30 6.5.1. Site VPN Flavor . . . . . . . . . . . . . . . . . . . 30
6.5.1.1. Single VPN attachment : site-vpn-flavor-single . 30 6.5.1.1. Single VPN Attachment: site-vpn-flavor-single . . 30
6.5.1.2. Multi VPN attachment : site-vpn-flavor-multi . . 31 6.5.1.2. MultiVPN Attachment: site-vpn-flavor-multi . . . 31
6.5.1.3. Sub VPN attachment : site-vpn-flavor-sub . . . . 31 6.5.1.3. SubVPN Attachment: site-vpn-flavor-sub . . . . . 31
6.5.1.4. NNI : site-vpn-flavor-nni . . . . . . . . . . . . 33 6.5.1.4. NNI: site-vpn-flavor-nni . . . . . . . . . . . . 33
6.5.2. Attaching a site to a VPN . . . . . . . . . . . . . . 34 6.5.2. Attaching a Site to a VPN . . . . . . . . . . . . . . 34
6.5.2.1. Reference a VPN . . . . . . . . . . . . . . . . . 35 6.5.2.1. Referencing a VPN . . . . . . . . . . . . . . . . 35
6.5.2.2. VPN policy . . . . . . . . . . . . . . . . . . . 35 6.5.2.2. VPN Policy . . . . . . . . . . . . . . . . . . . 35
6.6. Deciding where to connect the site . . . . . . . . . . . 38 6.6. Deciding Where to Connect the Site . . . . . . . . . . . 38
6.6.1. Constraint: Device . . . . . . . . . . . . . . . . . 39 6.6.1. Constraint: Device . . . . . . . . . . . . . . . . . 39
6.6.2. Constraint/parameter: Site location . . . . . . . . . 39 6.6.2. Constraint/Parameter: Site Location . . . . . . . . . 39
6.6.3. Constraint/parameter: access type . . . . . . . . . . 41 6.6.3. Constraint/Parameter: Access Type . . . . . . . . . . 41
6.6.4. Constraint: access diversity . . . . . . . . . . . . 41 6.6.4. Constraint: Access Diversity . . . . . . . . . . . . 41
6.6.5. Impossible access placement . . . . . . . . . . . . . 47 6.6.5. Infeasible Access Placement . . . . . . . . . . . . . 47
6.6.6. Examples of access placement . . . . . . . . . . . . 48 6.6.6. Examples of Access Placement . . . . . . . . . . . . 48
6.6.6.1. Multihoming . . . . . . . . . . . . . . . . . . . 48 6.6.6.1. Multihoming . . . . . . . . . . . . . . . . . . . 48
6.6.6.2. Site offload . . . . . . . . . . . . . . . . . . 50 6.6.6.2. Site Offload . . . . . . . . . . . . . . . . . . 50
6.6.6.3. Parallel links . . . . . . . . . . . . . . . . . 56 6.6.6.3. Parallel Links . . . . . . . . . . . . . . . . . 56
6.6.6.4. SubVPN with multihoming . . . . . . . . . . . . . 57 6.6.6.4. SubVPN with Multihoming . . . . . . . . . . . . . 57
6.6.7. Route Distinguisher and VRF allocation . . . . . . . 61 6.6.7. Route Distinguisher and VRF Allocation . . . . . . . 61
6.7. Site network access availability . . . . . . . . . . . . 62 6.7. Site Network Access Availability . . . . . . . . . . . . 62
6.8. Traffic protection . . . . . . . . . . . . . . . . . . . 63 6.8. Traffic Protection . . . . . . . . . . . . . . . . . . . 63
6.9. Security . . . . . . . . . . . . . . . . . . . . . . . . 64 6.9. Security . . . . . . . . . . . . . . . . . . . . . . . . 64
6.9.1. Authentication . . . . . . . . . . . . . . . . . . . 64 6.9.1. Authentication . . . . . . . . . . . . . . . . . . . 64
6.9.2. Encryption . . . . . . . . . . . . . . . . . . . . . 64 6.9.2. Encryption . . . . . . . . . . . . . . . . . . . . . 64
6.10. Management . . . . . . . . . . . . . . . . . . . . . . . 65 6.10. Management . . . . . . . . . . . . . . . . . . . . . . . 65
6.11. Routing protocols . . . . . . . . . . . . . . . . . . . . 66 6.11. Routing Protocols . . . . . . . . . . . . . . . . . . . . 66
6.11.1. Dual stack handling . . . . . . . . . . . . . . . . 66 6.11.1. Handling of Dual Stack . . . . . . . . . . . . . . . 66
6.11.2. Direct LAN connection onto SP network . . . . . . . 67 6.11.2. LAN Directly Connected to SP Network . . . . . . . . 67
6.11.3. Direct LAN connection onto SP network with 6.11.3. LAN Directly Connected to SP Network with Redundancy 67
redundancy . . . . . . . . . . . . . . . . . . . . . 67 6.11.4. Static Routing . . . . . . . . . . . . . . . . . . . 68
6.11.4. Static routing . . . . . . . . . . . . . . . . . . . 68 6.11.5. RIP Routing . . . . . . . . . . . . . . . . . . . . 68
6.11.5. RIP routing . . . . . . . . . . . . . . . . . . . . 68 6.11.6. OSPF Routing . . . . . . . . . . . . . . . . . . . . 68
6.11.6. OSPF routing . . . . . . . . . . . . . . . . . . . . 68 6.11.7. BGP Routing . . . . . . . . . . . . . . . . . . . . 70
6.11.7. BGP routing . . . . . . . . . . . . . . . . . . . . 70
6.12. Service . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.12. Service . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.12.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . 71 6.12.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . 71
6.12.2. QoS . . . . . . . . . . . . . . . . . . . . . . . . 72 6.12.2. QoS . . . . . . . . . . . . . . . . . . . . . . . . 72
6.12.2.1. QoS classification . . . . . . . . . . . . . . . 72 6.12.2.1. QoS Classification . . . . . . . . . . . . . . . 72
6.12.2.2. QoS profile . . . . . . . . . . . . . . . . . . 75 6.12.2.2. QoS Profile . . . . . . . . . . . . . . . . . . 75
6.12.3. Multicast . . . . . . . . . . . . . . . . . . . . . 79 6.12.3. Multicast . . . . . . . . . . . . . . . . . . . . . 79
6.13. Enhanced VPN features . . . . . . . . . . . . . . . . . . 79 6.13. Enhanced VPN Features . . . . . . . . . . . . . . . . . . 79
6.13.1. Carrier's Carrier . . . . . . . . . . . . . . . . . 79 6.13.1. Carriers' Carriers . . . . . . . . . . . . . . . . . 79
6.14. External ID references . . . . . . . . . . . . . . . . . 81 6.14. External ID References . . . . . . . . . . . . . . . . . 81
6.15. Defining NNIs . . . . . . . . . . . . . . . . . . . . . . 81 6.15. Defining NNIs . . . . . . . . . . . . . . . . . . . . . . 81
6.15.1. Defining NNI with option A flavor . . . . . . . . . 83 6.15.1. Defining an NNI with the Option A Flavor . . . . . . 83
6.15.2. Defining NNI with option B flavor . . . . . . . . . 86 6.15.2. Defining an NNI with the Option B Flavor . . . . . . 86
6.15.3. Defining NNI with option C flavor . . . . . . . . . 88 6.15.3. Defining an NNI with the Option C Flavor . . . . . . 88
7. Service model usage example . . . . . . . . . . . . . . . . . 90 7. Service Model Usage Example . . . . . . . . . . . . . . . . . 89
8. Interaction with Other YANG Modules . . . . . . . . . . . . . 95 8. Interaction with Other YANG Modules . . . . . . . . . . . . . 94
9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 99 9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 98
10. Security Considerations . . . . . . . . . . . . . . . . . . . 153 10. Security Considerations . . . . . . . . . . . . . . . . . . . 148
11. Contribution . . . . . . . . . . . . . . . . . . . . . . . . 154 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 148
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 154 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 149
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 154 12.1. Normative References . . . . . . . . . . . . . . . . . . 149
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 154 12.2. Informative References . . . . . . . . . . . . . . . . . 150
14.1. Changes between versions -18 and-19 . . . . . . . . . . 154 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 150
14.2. Changes between versions -17 and-18 . . . . . . . . . . 155 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 150
14.3. Changes between versions -16 and-17 . . . . . . . . . . 155 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 151
14.4. Changes between versions -15 and-16 . . . . . . . . . . 156
14.5. Changes between versions -13 and-14 . . . . . . . . . . 156
14.6. Changes between versions -12 and-13 . . . . . . . . . . 156
14.7. Changes between versions -11 and-12 . . . . . . . . . . 156
14.8. Changes between versions -09 and-10 . . . . . . . . . . 156
14.9. Changes between versions -08 and-09 . . . . . . . . . . 157
14.10. Changes between versions -07 and-08 . . . . . . . . . . 157
14.11. Changes between versions -06 and-07 . . . . . . . . . . 157
14.12. Changes between versions -05 and-06 . . . . . . . . . . 157
14.13. Changes between versions -04 and-05 . . . . . . . . . . 158
14.14. Changes between versions -02 and-03 . . . . . . . . . . 158
14.15. Changes between versions -01 and-02 . . . . . . . . . . 158
14.16. Changes between versions -00 and-01 . . . . . . . . . . 159
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 159
15.1. Normative References . . . . . . . . . . . . . . . . . . 159
15.2. Informative References . . . . . . . . . . . . . . . . . 161
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 161
1. Introduction 1. Introduction
This document defines a Layer 3 VPN service data model written in This document defines a Layer 3 VPN service data model written in
YANG. The model defines service configuration elements that can be YANG. The model defines service configuration elements that can be
used in communication protocols between customers and network used in communication protocols between customers and network
operators. Those elements can be used also as input to automated operators. Those elements can also be used as input to automated
control and configuration applications. control and configuration applications.
1.1. Terminology 1.1. Terminology
The following terms are defined in [RFC6241] and are not redefined The following terms are defined in [RFC6241] and are not redefined
here: here:
o client o client
o configuration data o configuration data
skipping to change at page 5, line 19 skipping to change at page 4, line 41
o data model o data model
o data node o data node
The terminology for describing YANG data models is found in The terminology for describing YANG data models is found in
[RFC7950]. [RFC7950].
This document presents some configuration examples using XML This document presents some configuration examples using XML
representation. representation.
1.2. Tree diagram 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.3. Tree Diagrams
A simplified graphical representation of the data model is presented A simplified graphical representation of the data model is presented
in Section 6. in Section 6.
The meaning of the symbols in these diagrams is as follows: The meanings of the symbols in these diagrams are as follows:
o Brackets "[" and "]" enclose list keys. o Brackets "[" and "]" enclose list keys.
o Curly braces "{" and "}" contain names of optional features that o Curly braces "{" and "}" contain names of optional features that
make the corresponding node conditional. make the corresponding node conditional.
o Abbreviations before data node names: "rw" means configuration o Abbreviations before data node names: "rw" means configuration
(read-write), and "ro" state data (read-only). data (read-write), and "ro" means state data (read-only).
o Symbols after data node names: "?" means an optional node and "*" o Symbols after data node names: "?" means an optional node, and "*"
denotes a "list" or "leaf-list". denotes a "list" or "leaf-list".
o Parentheses enclose choice and case nodes, and case nodes are also o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":"). marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not o Ellipsis ("...") stands for contents of subtrees that are not
shown. shown.
2. Acronyms 2. Acronyms
AAA: Authentication, Authorization, Accounting. AAA: Authentication, Authorization, and Accounting.
ACL: Access Control List. ACL: Access Control List.
ASM: Any-Source Multicast. ADSL: Asymmetric DSL.
BFD: Bidirectional Forwarding Detection. AH: Authentication Header.
BGP: Border Gateway Protocol. AS: Autonomous System.
CE: Customer Edge. ASBR: Autonomous System Border Router.
CLI: Command Line Interface. ASM: Any-Source Multicast.
CsC: Carrier's Carrier. BAS: Broadband Access Switch.
CSP: Cloud Service Provider. BFD: Bidirectional Forwarding Detection.
DHCP: Dynamic Host Configuration Protocol. BGP: Border Gateway Protocol.
IGMP: Internet Group Management Protocol. BSR: Bootstrap Router.
LAN: Local Area Network. CE: Customer Edge.
MLD: Multicast Listener Discovery. CLI: Command Line Interface.
MTU: Maximum Transmission Unit. CsC: Carriers' Carriers.
NAT: Network Address Translation. CSP: Cloud Service Provider.
NNI: Network to Network Interface. DHCP: Dynamic Host Configuration Protocol.
OAM: Operation Administration and Management. DSLAM: Digital Subscriber Line Access Multiplexer.
OSPF: Open Shortest Path First. ESP: Encapsulating Security Payload.
OSS: Operations Support System. GRE: Generic Routing Encapsulation.
PE: Provider Edge. IGMP: Internet Group Management Protocol.
POP: Point Of Presence. LAN: Local Area Network.
PIM: Protocol Independent Multicast. MLD: Multicast Listener Discovery.
QoS: Quality Of Service. MTU: Maximum Transmission Unit.
RIP: Routing Information Protocol. NAT: Network Address Translation.
RD: Route Distinguisher. NETCONF: Network Configuration Protocol.
RP: Rendez-vous Point. NNI: Network-to-Network Interface.
RT: Route Target. OAM: Operations, Administration, and Maintenance.
SLA: Service Level Agreement. OSPF: Open Shortest Path First.
SLAAC: Stateless Address AutoConfiguration. OSS: Operational Support System.
SP: Service Provider. PE: Provider Edge.
SSM: Source-Specific Multicast. PIM: Protocol Independent Multicast.
VPN: Virtual Private Network. POP: Point of Presence.
VRF: VPN Routing and Forwarding. QoS: Quality of Service.
VRRP: Virtual Router Redundancy Protocol. RD: Route Distinguisher.
RIP: Routing Information Protocol.
RP: Rendezvous Point.
RT: Route Target.
SFTP: Secure FTP.
SLA: Service Level Agreement.
SLAAC: Stateless Address Autoconfiguration.
SP: Service Provider.
SPT: Shortest Path Tree.
SSM: Source-Specific Multicast.
VM: Virtual Machine.
VPN: Virtual Private Network.
VRF: VPN Routing and Forwarding.
VRRP: Virtual Router Redundancy Protocol.
3. Definitions 3. Definitions
Customer Edge (CE) Device: Equipment that is dedicated to a Customer Edge (CE) Device: A CE is equipment dedicated to a
particular customer and is directly connected (at layer 3) to one or particular customer; it is directly connected (at Layer 3) to one or
more PE devices via attachment circuits. A CE is usually located at more PE devices via attachment circuits. A CE is usually located at
the customer premises, and is usually dedicated to a single VPN, the customer premises and is usually dedicated to a single VPN,
although it may support multiple VPNs if each one has separate although it may support multiple VPNs if each one has separate
attachment circuits. attachment circuits.
Provider Edge (PE) Device: Equipment managed by the Service Provider Provider Edge (PE) Device: A PE is equipment managed by the SP; it
(SP) that can support multiple VPNs for different customers, and is can support multiple VPNs for different customers and is directly
directly connected (at layer 3) to one or more CE devices via connected (at Layer 3) to one or more CE devices via attachment
attachment circuits. A PE is usually located at an SP point of circuits. A PE is usually located at an SP point of presence (POP)
presence (PoP) and is managed by the SP. and is managed by the SP.
PE-Based VPNs: The PE devices know that certain traffic is VPN PE-Based VPNs: The PE devices know that certain traffic is VPN
traffic. They forward the traffic (through tunnels) based on the traffic. They forward the traffic (through tunnels) based on the
destination IP address of the packet, and optionally on based on destination IP address of the packet and, optionally, based on other
other information in the IP header of the packet. The PE devices are information in the IP header of the packet. The PE devices are
themselves the tunnel endpoints. The tunnels may make use of various themselves the tunnel endpoints. The tunnels may make use of various
encapsulations to send traffic over the SP network (such as, but not encapsulations to send traffic over the SP network (such as, but not
restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels). restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels).
4. Layer 3 IP VPN service model 4. Layer 3 IP VPN Service Model
A layer 3 IPVPN service is a collection of sites that are authorized A Layer 3 IP VPN service is a collection of sites that are authorized
to exchange traffic between each other over a shared IP to exchange traffic between each other over a shared IP
infrastructure. This layer 3 VPN service model aims at providing a infrastructure. This Layer 3 VPN service model aims at providing a
common understanding on how the corresponding IP VPN service is to be common understanding of how the corresponding IP VPN service is to be
deployed over the shared infrastructure. This service model is deployed over the shared infrastructure. This service model is
limited to BGP PE-Based VPNs as described in [RFC4110] and [RFC4364]. limited to BGP PE-based VPNs as described in [RFC4026], [RFC4110],
and [RFC4364].
5. Service data model usage 5. Service Data Model Usage
L3VPN-SVC | l3vpn-svc |
MODEL | Model |
| |
+------------------+ +-----+ +------------------+ +-----+
| Orchestration | < --- > | OSS | | Orchestration | < --- > | OSS |
+------------------+ +-----+ +------------------+ +-----+
| | | |
+----------------+ | +----------------+ |
| Config manager | | | Config manager | |
+----------------+ | +----------------+ |
| | | |
| Netconf/CLI ... | NETCONF/CLI ...
| | | |
+------------------------------------------------+ +------------------------------------------------+
Network Network
+++++++ +++++++
+ AAA + + AAA +
+++++++ +++++++
++++++++ Bearer ++++++++ ++++++++ ++++++++ ++++++++ Bearer ++++++++ ++++++++ ++++++++
+ CE A + ------- + PE A + + PE B + ---- + CE B + + CE A + ----------- + PE A + + PE B + ---- + CE B +
++++++++ Cnct ++++++++ ++++++++ ++++++++ ++++++++ Connection ++++++++ ++++++++ ++++++++
Site A Site B Site A Site B
The idea of the L3 IPVPN service model is to propose an abstracted The idea of the L3 IP VPN service model is to propose an abstracted
interface between customers and network operators to manage interface between customers and network operators to manage
configuration of components of a L3VPN service. A typical usage is configuration of components of an L3VPN service. A typical scenario
to use this model as an input for an orchestration layer who will be would be to use this model as an input for an orchestration layer
responsible to translate it to orchestrated configuration of network that will be responsible for translating it to an orchestrated
elements who will be part of the service. The network elements can configuration of network elements that will be part of the service.
be routers, but also servers (like AAA), and not limited to these The network elements can be routers but can also be servers (like
examples. The configuration of network elements can be done by the AAA); the network's configuration is not limited to these examples.
CLI, or by NETCONF ([RFC6241])/RESTCONF ([I-D.ietf-netconf-restconf]) The configuration of network elements can be done via the CLI,
coupled with specific configuration YANG data models (BGP, VRF, BFD NETCONF/RESTCONF [RFC6241] [RFC8040] coupled with YANG data models of
...) or any other way. a specific configuration (BGP, VRF, BFD, etc.), or some other
technique, as preferred by the operator.
The usage of this service model is not limited to this example, it The usage of this service model is not limited to this example; it
can be used by any component of the management system but not can be used by any component of the management system but not
directly by network elements. directly by network elements.
6. Design of the Data Model 6. Design of the Data Model
The YANG module is divided in two main containers : vpn-services, The YANG module is divided into two main containers: "vpn-services"
sites. and "sites".
The vpn-service under vpn-services defines global parameters for the The "vpn-service" list under the "vpn-services" container defines
VPN service for a specific customer. global parameters for the VPN service for a specific customer.
A site is composed of at least one site-network-access and may have A site is composed of at least one site-network-access and, in the
multiple site-network-access in case of multihoming. The site- case of multihoming, may have multiple site-network-access points.
network-access attachment is done through a bearer with an IP The site-network-access attachment is done through a bearer with an
connection on top. The bearer refers to properties of the attachment IP connection on top. The bearer refers to properties of the
that are below layer 3 while the connection refers to layer 3 attachment that are below Layer 3, while the connection refers to
protocol oriented properties. The bearer may be allocated properties oriented to the Layer 3 protocol. The bearer may be
dynamically by the service provider and the customer may provide some allocated dynamically by the SP, and the customer may provide some
constraints or parameters to drive the placement. constraints or parameters to drive the placement of the access.
Authorization of traffic exchange is done through what we call a VPN Authorization of traffic exchange is done through what we call a VPN
policy or VPN service topology defining routing exchange rules policy or VPN service topology defining routing exchange rules
between sites. between sites.
The figure below describe the overall structure of the YANG module: The figure below describes the overall structure of the YANG module:
module: ietf-l3vpn-svc module: ietf-l3vpn-svc
+--rw l3vpn-svc +--rw l3vpn-svc
+--rw vpn-services +--rw vpn-services
| +--rw vpn-service* [vpn-id] | +--rw vpn-service* [vpn-id]
| +--rw vpn-id svc-id | +--rw vpn-id svc-id
| +--rw customer-name? string | +--rw customer-name? string
| +--rw vpn-service-topology? identityref | +--rw vpn-service-topology? identityref
| +--rw cloud-accesses {cloud-access}? | +--rw cloud-accesses {cloud-access}?
| | +--rw cloud-access* [cloud-identifier] | | +--rw cloud-access* [cloud-identifier]
skipping to change at page 16, line 39 skipping to change at page 16, line 39
+--rw availability +--rw availability
| +--rw access-priority? uint32 | +--rw access-priority? uint32
+--rw vpn-attachment +--rw vpn-attachment
+--rw (attachment-flavor) +--rw (attachment-flavor)
+--:(vpn-policy-id) +--:(vpn-policy-id)
| +--rw vpn-policy-id? leafref | +--rw vpn-policy-id? leafref
+--:(vpn-id) +--:(vpn-id)
+--rw vpn-id? leafref +--rw vpn-id? leafref
+--rw site-role? identityref +--rw site-role? identityref
6.1. Features and augmentation 6.1. Features and Augmentation
The model implements a lot of features allowing implementations to be The model defined in this document implements many features that
modular. As example, an implementation may support only IPv4 VPNs allow implementations to be modular. As an example, an
(ipv4 feature), IPv6 (ipv6 feature), or both (by advertising both implementation may support only IPv4 VPNs (IPv4 feature), IPv6 VPNs
features). The routing protocols proposed to the customer may also (IPv6 feature), or both (by advertising both features). The routing
be enabled through features. This model proposes also some features protocols proposed to the customer may also be enabled through
for more advanced options like : extranet-vpn support features. This model also proposes some features for options that
(Section 6.2.4), site diversity (Section 6.6), qos (Section 6.12.2), are more advanced, such as support for extranet VPNs (Section 6.2.4),
... site diversity (Section 6.6), and QoS (Section 6.12.2).
In addition, as for any YANG model, this service model can be In addition, as for any YANG model, this service model can be
augmented to implement new behaviors or specific features. For augmented to implement new behaviors or specific features. For
example, this model proposes different options for the IP address example, this model proposes different options for IP address
assignment, if those options are not filling all requirements, new assignments; if those options do not fulfill all requirements, new
options can be added through augmentation. options can be added through augmentation.
6.2. VPN service overview 6.2. VPN Service Overview
A vpn-service list item contains generic informations about the VPN A "vpn-service" list item contains generic information about the VPN
service. The vpn-id of the vpn-service refers to an internal service. The "vpn-id" provided in the "vpn-service" list refers to
reference for this VPN service, while customer name refers to a more an internal reference for this VPN service, while the customer name
explicit reference to the customer. This identifier is purely refers to a more-explicit reference to the customer. This identifier
internal to the organization responsible for the VPN service. is purely internal to the organization responsible for the VPN
service.
6.2.1. VPN service topology 6.2.1. VPN Service Topology
The type of VPN service topology is required for configuration. The type of VPN service topology is required for configuration. Our
Current proposal supports: any-to-any, hub and spoke (where hubs can proposed model supports any-to-any, Hub and Spoke (where Hubs can
exchange traffic), and hub and spoke disjoint (where hubs cannot exchange traffic), and "Hub and Spoke disjoint" (where Hubs cannot
exchange traffic). New topologies could be added by augmentation. exchange traffic). New topologies could be added via augmentation.
By default, any-to-any VPN service topology is used. By default, the any-to-any VPN service topology is used.
6.2.1.1. Route Target allocation 6.2.1.1. Route Target Allocation
Layer 3 PE-based VPN is built using route-targets as described in A Layer 3 PE-based VPN is built using route targets (RTs) as
[RFC4364]. It is expected the management system to allocate described in [RFC4364]. The management system is expected to
automatically a set of route-targets upon a VPN service creation automatically allocate a set of RTs upon receiving a VPN service
request. How the management system allocates route-targets is out of creation request. How the management system allocates RTs is out of
scope of the document but multiple ways could be envisaged as scope for this document, but multiple ways could be envisaged, as
described below. described below.
Management system Management system
<-------------------------------------------------> <------------------------------------------------->
Request RT Request RT
+-----------------------+ Topo a2a +----------+ +-----------------------+ Topo a2a +----------+
RESTCONF | | -----> | | RESTCONF | | -----> | |
User ------------- | Service Orchestration | |NetworkOSS| User ------------- | Service Orchestration | | Network |
l3vpn-svc | | <----- | | l3vpn-svc | | <----- | OSS |
model +-----------------------+ Response +----------+ Model +-----------------------+ Response +----------+
RT1,RT2 RT1, RT2
In the example above, a service orchestration, owning the In the example above, a service orchestration, owning the
instantiation of this service model, request route-targets to the instantiation of this service model, requests RTs to the network OSS.
network OSS. Based on the requested VPN service topology, the Based on the requested VPN service topology, the network OSS replies
network OSS replies with one or multiple route-targets. The with one or multiple RTs. The interface between this service
interface between this service orchestration and network OSS is out orchestration and the network OSS is out of scope for this document.
of scope of this document.
+---------------------------+ +---------------------------+
RESTCONF | | RESTCONF | |
User ------------- | Service Orchestration | User ------------- | Service Orchestration |
l3vpn-svc | | l3vpn-svc | |
model | | Model | |
| RT pool : 10:1->10:10000 | | RT pool: 10:1->10:10000 |
| RT pool : 20:50->20:5000 | | RT pool: 20:50->20:5000 |
+---------------------------+ +---------------------------+
In the example above, a service orchestration, owning the In the example above, a service orchestration, owning the
instantiation of this service model, owns one or more pools of route- instantiation of this service model, owns one or more pools of RTs
target (specified by service provider) that can be allocated. Based (specified by the SP) that can be allocated. Based on the requested
on the requested VPN service topology, it will allocate one or VPN service topology, it will allocate one or multiple RTs from the
multiple route-targets from the pool. pool.
The mechanism displayed above are just examples and should not be The mechanisms shown above are just examples and should not be
considered as an exhaustive list of solutions. considered an exhaustive list of solutions.
6.2.1.2. Any to any 6.2.1.2. Any-to-Any
+------------------------------------------------------------+ +------------------------------------------------------------+
| VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 | | VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 |
| | | |
| VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 | | VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 |
+------------------------------------------------------------+ +------------------------------------------------------------+
Figure - Any-to-any VPN service topology Any-to-Any VPN Service Topology
In the any-to-any VPN service topology, all VPN sites can communicate In the any-to-any VPN service topology, all VPN sites can communicate
between each other without any restriction. It is expected that the with each other without any restrictions. The management system that
management system that receives an any-to-any IPVPN service request receives an any-to-any IP VPN service request through this model is
through this model needs to assign and then configure the VRF and expected to assign and then configure the VRF and RTs on the
route-targets on the appropriate PEs. In the any-to-any case, in appropriate PEs. In the any-to-any case, a single RT is generally
general a single route-target is required and every VRF imports and required, and every VRF imports and exports this RT.
exports this route-target.
6.2.1.3. Hub and Spoke 6.2.1.3. Hub and Spoke
+-------------------------------------------------------------+ +-------------------------------------------------------------+
| Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 | | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
| +----------------------------------+ | +----------------------------------+
| | | |
| +----------------------------------+ | +----------------------------------+
| Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 | | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
Figure - Hub and Spoke VPN service topology Hub-and-Spoke VPN Service Topology
In the hub and spoke VPN service topology, all spoke sites can In the Hub-and-Spoke VPN service topology, all Spoke sites can
communicate only with Hub sites but not between each other, and hubs communicate only with Hub sites but not with each other, and Hubs can
can also communicate between each other. It is expected that the also communicate with each other. The management system that owns an
management system that owns an any to any IPVPN service request any-to-any IP VPN service request through this model is expected to
through this model, needs to assign and then configure the VRF and assign and then configure the VRF and RTs on the appropriate PEs. In
route-targets on the appropriate PEs. In the hub and spoke case, in the Hub-and-Spoke case, two RTs are generally required (one RT for
general a two route-targets are required (one route-target for Hub Hub routes and one RT for Spoke routes). A Hub VRF that connects Hub
routes, one route-target for spoke routes). A Hub VRF, connecting sites will export Hub routes with the Hub RT and will import Spoke
Hub sites, will export Hub routes with Hub route-target, and will routes through the Spoke RT. It will also import the Hub RT to allow
import Spoke routes through Spoke route-target. It will also import Hub-to-Hub communication. A Spoke VRF that connects Spoke sites will
the Hub route-target to allow Hub to Hub communication. A Spoke VRF, export Spoke routes with the Spoke RT and will import Hub routes
connecting Spoke sites, will export Spoke routes with Spoke route- through the Hub RT.
target, and will import Hub routes through Hub route-target.
The management system MUST take into account Hub and Spoke The management system MUST take into account constraints on Hub-and-
connections constraints. For example, if a management system decides Spoke connections. For example, if a management system decides to
to mesh a spoke site and a hub site on the same PE, it needs to mesh mesh a Spoke site and a Hub site on the same PE, it needs to mesh
connections in different VRFs as displayed in the figure below. connections in different VRFs, as shown in the figure below.
Hub_Site ------- (VRF_Hub) PE1 Hub_Site ------- (VRF_Hub) PE1
(VRF_Spoke) (VRF_Spoke)
/ | / |
Spoke_Site1 -------------------+ | Spoke_Site1 -------------------+ |
| |
Spoke_Site2 -----------------------+ Spoke_Site2 -----------------------+
6.2.1.4. Hub and Spoke disjoint 6.2.1.4. Hub and Spoke Disjoint
+-------------------------------------------------------------+ +-------------------------------------------------------------+
| Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 | | Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
+--------------------------+ +-------------------------------+ +--------------------------+ +-------------------------------+
| | | |
+--------------------------+ +-------------------------------+ +--------------------------+ +-------------------------------+
| Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 | | Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
Figure - Hub and Spoke disjoint VPN service topology Hub and Spoke Disjoint VPN Service Topology
In the Hub and Spoke disjoint VPN service topology, all Spoke sites In the Hub and Spoke disjoint VPN service topology, all Spoke sites
can communicate only with Hub sites but not between each other and can communicate only with Hub sites but not with each other, and Hubs
Hubs cannot communicate between each other. It is expected that the cannot communicate with each other. The management system that owns
management system that owns an any to any IPVPN service request an any-to-any IP VPN service request through this model is expected
through this model, needs to assign and then configure the VRF and to assign and then configure the VRF and RTs on the appropriate PEs.
route-targets on the appropriate PEs. In the Hub and Spoke case, two In the Hub-and-Spoke case, two RTs are required (one RT for Hub
route-targets are required (one route-target for Hub routes, one routes and one RT for Spoke routes). A Hub VRF that connects Hub
route-target for Spoke routes). A Hub VRF, connecting Hub sites, sites will export Hub routes with the Hub RT and will import Spoke
will export Hub routes with Hub route-target, and will import Spoke routes through the Spoke RT. A Spoke VRF that connects Spoke sites
routes through Spoke route-target. A Spoke VRF, connecting Spoke will export Spoke routes with the Spoke RT and will import Hub routes
sites, will export Spoke routes with Spoke route-target, and will through the Hub RT.
import Hub routes through Hub route-target.
The management system MUST take into account Hub and Spoke The management system MUST take into account constraints on Hub-and-
connections constraints as in the previous case. Spoke connections, as in the previous case.
Hub and Spoke disjoint can also be seen as multiple Hub and Spoke Hub and Spoke disjoint can also be seen as multiple Hub-and-Spoke
VPNs (one per Hub) sharing with a common set of Spoke sites. VPNs (one per Hub) that share a common set of Spoke sites.
6.2.2. Cloud access 6.2.2. Cloud Access
The proposed model provides a cloud access configuration through the The proposed model provides cloud access configuration via the
cloud-access container. The usage of cloud-access is targeted for "cloud-accesses" container. The usage of cloud-access is targeted
public cloud. An Internet access can also be considered as a public for the public cloud. An Internet access can also be considered a
cloud access service. The cloud-access container provides parameters public cloud access service. The "cloud-accesses" container provides
for network address translations and authorization rules. parameters for network address translation and authorization rules.
A private cloud access may be addressed through NNIs as described in A private cloud access may be addressed through NNIs, as described in
Section 6.15. Section 6.15.
A cloud identifier is used to reference the target service. This A cloud identifier is used to reference the target service. This
identifier is local to each administration. identifier is local to each administration.
The model allows for source address translation before accessing the The model allows for source address translation before accessing the
cloud. IPv4 to IPv4 address translation (nat44) is the only cloud. IPv4-to-IPv4 address translation (NAT44) is the only
supported option but other options can be added through augmentation. supported option, but other options can be added through
If IP source address translation is required to access the cloud, the augmentation. If IP source address translation is required to access
enabled leaf MUST be set to true in the "nat44" container. An IP the cloud, the "enabled" leaf MUST be set to true in the "nat44"
address may be provided in the customer-address leaf, in case the container. An IP address may be provided in the "customer-address"
customer is providing the IP address to be used for the cloud access. leaf if the customer is providing the IP address to be used for the
If the service provider is providing this address, the customer- cloud access. If the SP is providing this address,
address is not necessary as it can be picked from a service provider "customer-address" is not necessary, as it can be picked from a pool
pool. of SPs.
By default, all sites in the IPVPN MUST be authorized to access to By default, all sites in the IP VPN MUST be authorized to access the
the cloud. In case restrictions are required, a user MAY configure cloud. If restrictions are required, a user MAY configure the
the permit-site or deny-site leaf-list. The "permit-site" defines "permit-site" or "deny-site" leaf-list. The "permit-site" leaf-list
the list of sites authorized for cloud access. The "deny-site" defines the list of sites authorized for cloud access. The
defines the list of sites denied for cloud access. The model "deny-site" leaf-list defines the list of sites denied for cloud
supports both "deny any except" and "permit any except" access. The model supports both "deny-any-except" and
authorization. "permit-any-except" authorization.
How the restrictions will be configured on network elements is out of How the restrictions will be configured on network elements is out of
scope of this document. scope for this document.
IPVPN IP VPN
++++++++++++++++++++++++++++++++ +++++++++++ ++++++++++++++++++++++++++++++++ ++++++++++++
+ Site 3 + --- + Cloud1 + + Site 3 + --- + Cloud 1 +
+ Site 1 + +++++++++++ + Site 1 + ++++++++++++
+ + + +
+ Site 2 + --- ++++++++++++ + Site 2 + --- ++++++++++++
+ + + Internet + + + + Internet +
+ Site 4 + ++++++++++++ + Site 4 + ++++++++++++
++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++
| |
++++++++++ +++++++++++
+ Cloud2 + + Cloud 2 +
++++++++++ +++++++++++
In the example above, we may configure the global VPN to access In the example above, we configure the global VPN to access the
Internet by creating a cloud-access pointing to the cloud identifier Internet by creating a cloud-access pointing to the cloud identifier
for the Internet service. No authorized-sites will be configured as for the Internet service. No authorized sites will be configured, as
all sites are required to access the Internet. The "address- all sites are required to access the Internet. The
translation/nat44/enabled" leaf will be set to true. "address-translation/nat44/enabled" leaf will be set to true.
<vpn-service> <vpn-service>
<vpn-id>123456487</vpn-id> <vpn-id>123456487</vpn-id>
<cloud-accesses> <cloud-accesses>
<cloud-access> <cloud-access>
<cloud-identifier>INTERNET</cloud-identifier> <cloud-identifier>INTERNET</cloud-identifier>
<address-translation> <address-translation>
<nat44> <nat44>
<enabled>true</enabled> <enabled>true</enabled>
</nat44> </nat44>
</address-translation> </address-translation>
</cloud-access> </cloud-access>
</cloud-accesses> </cloud-accesses>
</vpn-service> </vpn-service>
If Site1 and Site2 requires access to Cloud1, a new cloud-access will If Site 1 and Site 2 require access to Cloud 1, a new cloud-access
be created pointing to the cloud identifier of Cloud1. The "permit- pointing to the cloud identifier of Cloud 1 will be created. The
site" leaf-list will be filled with a reference to Site1 and Site2. "permit-site" leaf-list will be filled with a reference to Site 1 and
Site 2.
<vpn-service> <vpn-service>
<vpn-id>123456487</vpn-id> <vpn-id>123456487</vpn-id>
<cloud-accesses> <cloud-accesses>
<cloud-access> <cloud-access>
<cloud-identifier>Cloud1</cloud-identifier> <cloud-identifier>Cloud1</cloud-identifier>
<permit-site>site1</permit-site> <permit-site>site1</permit-site>
<permit-site>site2</permit-site> <permit-site>site2</permit-site>
<cloud-access> </cloud-access>
</cloud-accesses> </cloud-accesses>
</vpn-service> </vpn-service>
If all sites except Site1 requires access to Cloud2, a new cloud- If all sites except Site 1 require access to Cloud 2, a new
access will be created pointing to the cloud identifier of Cloud2. cloud-access pointing to the cloud identifier of Cloud 2 will be
The "deny-site" leaf-list will be filled with a reference to Site1. created. The "deny-site" leaf-list will be filled with a reference
to Site 1.
<vpn-service> <vpn-service>
<vpn-id>123456487</vpn-id> <vpn-id>123456487</vpn-id>
<cloud-accesses> <cloud-accesses>
<cloud-access> <cloud-access>
<cloud-identifier>Cloud2</cloud-identifier> <cloud-identifier>Cloud2</cloud-identifier>
<deny-site>site1</deny-site> <deny-site>site1</deny-site>
</cloud-access> </cloud-access>
</cloud-accesses> </cloud-accesses>
</vpn-service> </vpn-service>
6.2.3. Multicast service 6.2.3. Multicast Service
Multicast in IP VPN is described in [RFC6513]. Multicast in IP VPNs is described in [RFC6513].
If multicast support is required for an IPVPN, some global multicast If multicast support is required for an IP VPN, some global multicast
parameters are required as input of the service request. parameters are required as input for the service request.
The user of this model will need to fill the flavor of trees that Users of this model will need to provide the flavors of trees that
will be used by customer within the IPVPN (Customer tree). The will be used by customers within the IP VPN (customer tree). The
proposed model supports bidirectional, shared and source-based trees proposed model supports bidirectional, shared, and source-based trees
(and can be augmented). Multiple flavors of tree can be supported (and can be augmented). Multiple flavors of trees can be supported
simultaneously. simultaneously.
Operator network Operator network
______________ ______________
/ \ / \
| | | |
(SSM tree) | (SSM tree) |
Recv (IGMPv3) -- Site2 ------- PE2 | Recv (IGMPv3) -- Site2 ------- PE2 |
| PE1 --- Site1 --- Source1 | PE1 --- Site1 --- Source1
| | \ | | \
skipping to change at page 23, line 26 skipping to change at page 23, line 26
Recv (IGMPv2) -- Site3 ------- PE3 | Recv (IGMPv2) -- Site3 ------- PE3 |
| | | |
(SSM tree) | (SSM tree) |
Recv (IGMPv3) -- Site4 ------- PE4 | Recv (IGMPv3) -- Site4 ------- PE4 |
| / | | / |
Recv (IGMPv2) -- Site5 -------- | Recv (IGMPv2) -- Site5 -------- |
(ASM tree) | (ASM tree) |
| | | |
\_______________/ \_______________/
In case of an ASM flavor requested, this model requires to fill the When an ASM flavor is requested, this model requires that the "rp"
rp and rp-discovery parameters. Multiple RP to group mappings can be and "rp-discovery" parameters be filled. Multiple RP-to-group
created using the rp-group-mappings container. For each mapping, the mappings can be created using the "rp-group-mappings" container. For
RP service can be managed by the service provider using the leaf each mapping, the SP can manage the RP service by setting the
"provider-managed/enabled" set to true. In case of provider managed "provider-managed/enabled" leaf to true. In the case of a provider-
RP, the user can request a rendez-vous point redundancy and/or an managed RP, the user can request RP redundancy and/or optimal traffic
optimal traffic delivery. Those parameters will help the service delivery. Those parameters will help the SP select the appropriate
provider to select the appropriate technology or architecture to technology or architecture to fulfill the customer service
fulfill the customer service requirement: for instance, in case of a requirement: for instance, in the case of a request for optimal
request for an optimal traffic delivery, a service provider may use traffic delivery, an SP may use Anycast-RP or RP-tree-to-SPT
Anycast-RP or RP-tree to SPT switchover architectures. switchover architectures.
In case of a customer managed RP, the RP address must be filled in In the case of a customer-managed RP, the RP address must be filled
the RP to group mappings using the "rp-address" leaf. This leaf is in the RP-to-group mappings using the "rp-address" leaf. This leaf
not needed for a provider managed RP. is not needed for a provider-managed RP.
User can define a specific rp-discovery mechanism like: auto-rp, Users can define a specific mechanism for RP discovery, such as the
static-rp, bsr-rp modes. By default, the model considers static-rp auto-rp, static-rp, or bsr-rp modes. By default, the model uses
if ASM is requested. A single rp-discovery mechanism is allowed for static-rp if ASM is requested. A single rp-discovery mechanism is
the VPN. The "rp-discovery" container can be used for both provider allowed for the VPN. The "rp-discovery" container can be used for
and customer managed RPs. In case of a provider managed RP, if the both provider-managed and customer-managed RPs. In the case of a
user wants to use bsr-rp as a discovery protocol, a service provider provider-managed RP, if the user wants to use bsr-rp as a discovery
should consider the provider managed rp-group-mappings for the bsr-rp protocol, an SP should consider the provider-managed
configuration. The service provider will then configure its selected rp-group-mappings for the bsr-rp configuration. The SP will then
RPs to be bsr-rp-candidates. In case of a customer managed RP and a configure its selected RPs to be bsr-rp-candidates. In the case of a
bsr-rp discovery mechanism, the rp-address provided will be customer-managed RP and a bsr-rp discovery mechanism, the rp-address
considered as bsr-rp candidate. provided will be the bsr-rp candidate.
6.2.4. Extranet VPNs 6.2.4. Extranet VPNs
There are some cases where a particular VPN needs to access to There are some cases where a particular VPN needs access to resources
resources (servers, hosts ...) that are external. These resources (servers, hosts, etc.) that are external. Those resources may be
may be located in another VPN. located in another VPN.
+-----------+ +-----------+ +-----------+ +-----------+
/ \ / \ / \ / \
SiteA -- | VPN A | --- | VPN B | --- SiteB Site A -- | VPN A | --- | VPN B | --- Site B
\ / \ / (Shared \ / \ / (Shared
+-----------+ +-----------+ resources) +-----------+ +-----------+ resources)
In the figure above, VPN B has some resources on Site B that need to In the figure above, VPN B has some resources on Site B that need to
be available to some customers/partners. VPN A must be able to be available to some customers/partners. VPN A must be able to
access those VPN B resources. access those VPN B resources.
Such VPN connection scenario can be achieved by the VPN policy Such a VPN connection scenario can be achieved via a VPN policy as
defined in Section 6.5.2.2. But there are some simple cases where a defined in Section 6.5.2.2. But there are some simple cases where a
particular VPN (VPN A) needs to access to all resources in a VPN B. particular VPN (VPN A) needs access to all resources in another VPN
The model provides an easy way to setup this connection using the (VPN B). The model provides an easy way to set up this connection
"extranet-vpns" container. using the "extranet-vpns" container.
The "extranet-vpns" container defines a list of VPNs a particular VPN The "extranet-vpns" container defines a list of VPNs a particular VPN
wants to access. The "extranet-vpns" must be used on customer VPNs wants to access. The "extranet-vpns" container must be used on
accessing extranet resources in another VPN. In the figure above, in customer VPNs accessing extranet resources in another VPN. In the
order to give access for VPN A to VPN B, extranet-vpns container figure above, in order to provide VPN A with access to VPN B, the
needs to be configured under VPN A with an entry corresponding to VPN "extranet-vpns" container needs to be configured under VPN A with an
B and there is no service configuration requirement on VPN B. entry corresponding to VPN B. There is no service configuration
requirement on VPN B.
Readers should note that even if there is no configuration Readers should note that even if there is no configuration
requirement on VPN B, if VPN A lists VPN B as extranet, all sites in requirement on VPN B, if VPN A lists VPN B as an extranet, all sites
VPN B will gain access to all sites in VPN A. in VPN B will gain access to all sites in VPN A.
The "site-role" leaf defines the role of the local VPN sites in the The "site-role" leaf defines the role of the local VPN sites in the
target extranet VPN service topology. Site roles are defined in target extranet VPN service topology. Site roles are defined in
Section 6.4. Based on this, the requirements described in Section 6.4. Based on this, the requirements described in
Section 6.4 regarding the site-role leaf are also applicable here. Section 6.4 regarding the "site-role" leaf are also applicable here.
In the example below, VPN A accesses to VPN B resources through an In the example below, VPN A accesses VPN B resources through an
extranet connection, a Spoke role is required for VPN A sites as extranet connection. A Spoke role is required for VPN A sites, as
sites from VPN A must not be able to communicate between each other sites from VPN A must not be able to communicate with each other
through the extranet VPN connection. through the extranet VPN connection.
<vpn-service> <vpn-service>
<vpn-id>VPNB</vpn-id> <vpn-id>VPNB</vpn-id>
<vpn-service-topology>hub-Spoke</vpn-service-topology> <vpn-service-topology>hub-spoke</vpn-service-topology>
</vpn-service> </vpn-service>
<vpn-service> <vpn-service>
<vpn-id>VPNA</vpn-id> <vpn-id>VPNA</vpn-id>
<vpn-service-topology>any-to-any</vpn-service-topology> <vpn-service-topology>any-to-any</vpn-service-topology>
<extranet-vpns> <extranet-vpns>
<extranet-vpn> <extranet-vpn>
<vpn-id>VPNB</vpn-id> <vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</extranet-vpn> </extranet-vpn>
</extranet-vpns> </extranet-vpns>
</vpn-service> </vpn-service>
This model does not define how the extranet configuration will be This model does not define how the extranet configuration will be
achieved. achieved.
Any more complex VPN interconnection scenario (e.g. only part of Any VPN interconnection scenario that is more complex (e.g., only
sites of VPN A accessing only part of sites of VPN B) needs to be certain parts of sites on VPN A accessing only certain parts of sites
achieved using the vpn attachment defined in Section 6.5.2 and on VPN B) needs to be achieved using a VPN attachment as defined in
especially the VPN policy defined in Section 6.5.2.2. Section 6.5.2, and especially a VPN policy as defined in
Section 6.5.2.2.
6.3. Site overview 6.3. Site Overview
A site represents a connection of a customer office to one or more A site represents a connection of a customer office to one or more
VPN services. VPN services.
+-------------+ +-------------+
/ \ / \
+------------------+ +-----| VPN1 | +------------------+ +-----| VPN1 |
| | | \ / | | | \ /
| New York Office | ----- (site) -----+ +-------------+ | New York Office |------ (site) -----+ +-------------+
| | | +-------------+ | | | +-------------+
+------------------+ | / \ +------------------+ | / \
+-----| VPN2 | +-----| VPN2 |
\ / \ /
+-------------+ +-------------+
A site is composed of some characteristics : A site has several characteristics:
o Unique identifier (site-id): to uniquely identify the site within o Unique identifier (site-id): uniquely identifies the site within
the overall network infrastructure. The identifier is a string the overall network infrastructure. The identifier is a string
allowing to any encoding for the local administration of the VPN that allows any encoding for the local administration of the VPN
service. service.
o Locations (locations): site location information to allow easy o Locations (locations): site location information that allows easy
retrieval on nearest available resources. A site may be composed retrieval of information from the nearest available resources. A
of multiple locations. site may be composed of multiple locations.
o Devices: the customer can request one or more customer premise o Devices (devices): allows the customer to request one or more
equipments from the service provider for a particular site. customer premises equipment entities from the SP for a particular
site.
o Management (management): defines the model of management of the o Management (management): defines the type of management for the
site, for example : co-managed, customer managed or provider site -- for example, co-managed, customer managed, or provider
managed. managed. See Section 6.10.
o Site network accesses (site-network-accesses): defines the list of o Site network accesses (site-network-accesses): defines the list of
network accesses associated to the sites and their properties : network accesses associated with the sites, and their properties
especially bearer, connection and service parameters. -- especially bearer, connection, and service parameters.
A site-network-access represents an IP logical connection of a site. A site-network-access represents an IP logical connection of a site.
A site may have multiple site-network-accesses. A site may have multiple site-network-accesses.
+------------------+ Site +------------------+ Site
| |----------------------------------- | |-----------------------------------
| |****** (site-network-access#1) ****** | |****** (site-network-access#1) ******
| New York Office | | New York Office |
| |****** (site-network-access#2) ****** | |****** (site-network-access#2) ******
| |----------------------------------- | |-----------------------------------
+------------------+ +------------------+
Multiple site-network-accesses are used for instance in case of Multiple site-network-accesses are used, for instance, in the case of
multihoming. Some other meshing cases may also involve multiple multihoming. Some other meshing cases may also include multiple
site-network-accesses. site-network-accesses.
The site configuration is viewed as a global entity, we assume that The site configuration is viewed as a global entity; we assume that
it is mostly the role of the management to split the parameters it is mostly the management system's role to split the parameters
between the different elements within the network. For example, in between the different elements within the network. For example, in
the case of the site-network-access configuration, the management the case of the site-network-access configuration, the management
system needs to split the overall parameters between the PE system needs to split the overall parameters between the PE
configuration and the CE configuration. configuration and the CE configuration.
6.3.1. Devices and locations 6.3.1. Devices and Locations
A site may be composed of multiple locations. All the locations will A site may be composed of multiple locations. All the locations will
need to be configured as part of the "locations" container and list. need to be configured as part of the "locations" container and list.
A typical example of multilocation site is an headquarter in a city A typical example of a multi-location site is a headquarters office
composed of multiple buildings. Those buildings may be located in in a city composed of multiple buildings. Those buildings may be
different parts of the city and may be linked by intra-city fibers located in different parts of the city and may be linked by
(customer metropolitan area network). In such a case, when intra-city fibers (customer metropolitan area network). In such a
connecting to a VPN service, the customer may ask for multihoming case, when connecting to a VPN service, the customer may ask for
based on its distributed locations. multihoming based on its distributed locations.
New York Site New York Site
+------------------+ Site +------------------+ Site
| +--------------+ |----------------------------------- | +--------------+ |-----------------------------------
| | Manhattan | |****** (site-network-access#1) ****** | | Manhattan | |****** (site-network-access#1) ******
| +--------------+ | | +--------------+ |
| +--------------+ | | +--------------+ |
| | Brooklyn | |****** (site-network-access#2) ****** | | Brooklyn | |****** (site-network-access#2) ******
| +--------------+ | | +--------------+ |
| |----------------------------------- | |-----------------------------------
+------------------+ +------------------+
A customer may also request some premise equipments (CEs) to the A customer may also request some premises equipment entities (CEs)
service provider through the "devices" container. Requesting a CE from the SP via the "devices" container. Requesting a CE implies a
implies a provider-managed or co-managed model. A particular device provider-managed or co-managed model. A particular device must be
must be ordered to a particular already configured location. This ordered to a particular already-configured location. This would help
would help the service provider to send the device to the appropriate the SP send the device to the appropriate postal address. In a
postal address. In a multilocation site, a customer may for example multi-location site, a customer may, for example, request a CE for
request a CE for each location on the site where multihoming must be each location on the site where multihoming must be implemented. In
implemented. In the figure above, one device may be requested for the figure above, one device may be requested for the Manhattan
the Manhattan location and one other for the Brooklyn location. location and one other for the Brooklyn location.
By using devices and locations, the user can influence the By using devices and locations, the user can influence the
multihoming scenario he wants to implement: single CE, dual CE... multihoming scenario he wants to implement: single CE, dual CE, etc.
6.3.2. Site network accesses 6.3.2. Site Network Accesses
As mentioned, a site may be multihomed. Each IP network access for a As mentioned earlier, a site may be multihomed. Each IP network
site is defined in the site-network-accesses list. The site-network- access for a site is defined in the "site-network-accesses"
access defines how the site is connected on the network and is split container. The "site-network-access" parameter defines how the site
into three main classes of parameters: is connected on the network and is split into three main classes of
parameters:
o bearer: defines requirements of the attachment (below Layer 3). o bearer: defines requirements of the attachment (below Layer 3).
o connection: defines Layer 3 protocol parameters of the attachment. o connection: defines Layer 3 protocol parameters of the attachment.
o availability: defines the site availability policy. The o availability: defines the site's availability policy. The
availability parameters are defined in Section 6.7 availability parameters are defined in Section 6.7.
The site-network-access has a specific type (site-network-access- The site-network-access has a specific type
type). This documents defines two types : (site-network-access-type). This document defines two types:
o point-to-point: describes a point to point connection between the o point-to-point: describes a point-to-point connection between the
service provider and the customer. SP and the customer.
o multipoint: describes a multipoint connection between the service o multipoint: describes a multipoint connection between the SP and
provider and the customer. the customer.
The type of site-network-access may have an impact on the parameters The type of site-network-access may have an impact on the parameters
offered to the customer, e.g., a service provider may not offer offered to the customer, e.g., an SP may not offer encryption for
encryption for multipoint accesses. Deciding what parameter is multipoint accesses. It is up to the provider to decide what
supported for point-to-point and/or multipoint accesses is up to the parameter is supported for point-to-point and/or multipoint accesses;
provider and is out of scope of this document. Some containers this topic is out of scope for this document. Some containers
proposed in the model may require extension in order to work properly proposed in the model may require extensions in order to work
for multipoint accesses. properly for multipoint accesses.
6.3.2.1. Bearer 6.3.2.1. Bearer
The "bearer" container defines the requirements for the site The "bearer" container defines the requirements for the site
attachment to the provider network that are below Layer 3. attachment to the provider network that are below Layer 3.
The bearer parameters will help to determine the access media to be The bearer parameters will help determine the access media to be
used. This is further described in Section 6.6.3. used. This is further described in Section 6.6.3.
6.3.2.2. Connection 6.3.2.2. Connection
The "ip-connection" container defines the protocol parameters of the The "ip-connection" container defines the protocol parameters of the
attachment (IPv4 and IPv6). Depending on the management mode, it attachment (IPv4 and IPv6). Depending on the management mode, it
refers to the PE-CE addressing or CE to customer LAN addressing. In refers to PE-CE addressing or CE-to-customer-LAN addressing. In any
any case, it describes the provider to customer responsibility case, it describes the responsibility boundary between the provider
boundary. For a customer managed site, it refers to the PE-CE and the customer. For a customer-managed site, it refers to the
connection. For a provider managed site, it refers to the CE to LAN PE-CE connection. For a provider-managed site, it refers to the
connection. CE-to-LAN connection.
6.3.2.2.1. IP addressing 6.3.2.2.1. IP Addressing
An IP subnet can be configured for either layer 3 protocols. For a An IP subnet can be configured for either IPv4 or IPv6 Layer 3
dual stack connection, two subnets will be provided, one for each protocols. For a dual-stack connection, two subnets will be
address family. provided, one for each address family.
The address-allocation-type determines how the address allocation The address-allocation-type determines how the address allocation
needs to be done. The current model proposes five ways of IP address needs to be done. The current model proposes five ways to perform IP
allocation: address allocation:
o provider-dhcp: the provider will provide DHCP service for customer o provider-dhcp: The provider will provide DHCP service for customer
equipments, this is can be applied to either IPv4 and IPv6 equipment; this is applicable to either the "IPv4" container or
containers. the "IPv6" container.
o provider-dhcp-relay: the provider will provide DHCP relay service o provider-dhcp-relay: The provider will provide DHCP relay service
for customer equipments, this is applicable to both IPv4 and IPv6 for customer equipment; this is applicable to both IPv4 and IPv6
addressing. The customer needs to fill DHCP server list to be addressing. The customer needs to populate the DHCP server list
used. to be used.
o static-address: Addresses will be assigned manually, this is o static-address: Addresses will be assigned manually; this is
applicable to both IPv4 and IPv6 addressing. applicable to both IPv4 and IPv6 addressing.
o slaac: enables stateless address autoconfiguration ([RFC4862]). o slaac: This parameter enables stateless address autoconfiguration
This is applicable only for IPv6. [RFC4862]. This is applicable to IPv6 only.
o provider-dhcp-slaac: the provider will provide DHCP service for o provider-dhcp-slaac: The provider will provide DHCP service for
customer equipments as well as stateless address customer equipment, as well as stateless address
autoconfiguration. This is applicable only for IPv6. autoconfiguration. This is applicable to IPv6 only.
In the dynamic addressing mechanism, it is expected from the service In the dynamic addressing mechanism, the SP is expected to provide at
provider to provide at least the IP address, mask and default gateway least the IP address, mask, and default gateway information.
information.
6.3.2.2.2. OAM 6.3.2.2.2. OAM
A customer may require a specific IP connectivity fault detection A customer may require a specific IP connectivity fault detection
mechanism on the IP connection. The model supports BFD as a fault mechanism on the IP connection. The model supports BFD as a fault
detection mechanism. This can be extended with other mechanisms by detection mechanism. This can be extended with other mechanisms via
augmentation. The provider can propose some profiles to the customer augmentation. The provider can propose some profiles to the
depending of the service level the customer wants to achieve. customer, depending on the service level the customer wants to
Profile names must be communicated to the customer. This achieve. Profile names must be communicated to the customer. This
communication is out of scope of this document. Some fixed values communication is out of scope for this document. Some fixed values
for the holdtime period may also be imposed by the customer if the for the holdtime period may also be imposed by the customer if the
provider enables it. provider allows the customer this function.
The OAM container can easily be augmented by other mechanisms, The "oam" container can easily be augmented by other mechanisms; in
especially work from LIME Working Group may be reused. particular, work done by the LIME Working Group
(https://datatracker.ietf.org/wg/lime/charter/) may be reused in
applicable scenarios.
6.3.2.3. Inheritance of parameters between site and site-network-access 6.3.2.3. Inheritance of Parameters Defined at Site Level and Site
Network Access Level
Some parameters can be configured both at the site level at the site- Some parameters can be configured at both the site level and the
network-access level: e.g. routing, services, security... Inheritance site-network-access level, e.g., routing, services, security.
applies when parameters are defined at site level. If a parameter is Inheritance applies when parameters are defined at the site level.
configured at both site and access level, the access level parameter If a parameter is configured at both the site level and the access
MUST override the site level parameter. Those parameters will be level, the access-level parameter MUST override the site-level
described later in the document. parameter. Those parameters will be described later in this
document.
In terms of provisionning impact, it will be up to the implementation In terms of provisioning impact, it will be up to the implementation
to decide of the appropriate behavior when modifying existing to decide on the appropriate behavior when modifying existing
configurations. But the service provider will need to communicate to configurations. But the SP will need to communicate to the user
the user about the impact of using inheritance. For example, if we about the impact of using inheritance. For example, if we consider
consider that a site has already provisionned three site-network- that a site has already provisioned three site-network-accesses, what
accesses, what will happen if customer is changing a service will happen if a customer changes a service parameter at the site
parameter at site level ? An implementation of this model may update level? An implementation of this model may update the service
the service parameters of all already provisionned site-network- parameters of all already-provisioned site-network-accesses (with
accesses (with potential impact on live traffic) or it may take into potential impact on live traffic), or it may take into account this
account this new parameter only for the new sites. new parameter only for the new sites.
6.4. Site role 6.4. Site Role
A VPN has a particular service topology as described in A VPN has a particular service topology, as described in
Section 6.2.1. As a consequence, each site belonging to a VPN is Section 6.2.1. As a consequence, each site belonging to a VPN is
assigned with a particular role in this topology. The site-role assigned with a particular role in this topology. The "site-role"
defines the role of the site in a particular VPN topology. leaf defines the role of the site in a particular VPN topology.
In the any-to-any VPN service topology, all sites MUST have the same In the any-to-any VPN service topology, all sites MUST have the same
role which is any-to-any-role. role, which will be "any-to-any-role".
In the hub-spoke or hub-spoke-disjoint VPN service topology, sites In the Hub-and-Spoke VPN service topology or the Hub and Spoke
MUST have a hub-role or a spoke-role. disjoint VPN service topology, sites MUST have a Hub role or a
Spoke role.
6.5. Site belonging to multiple VPNs 6.5. Site Belonging to Multiple VPNs
6.5.1. Site vpn flavor 6.5.1. Site VPN Flavor
A site may be part of one or multiple VPNs. The site flavor defines A site may be part of one or multiple VPNs. The site flavor defines
the way the VPN multiplexing is done. The current version of the the way the VPN multiplexing is done. The current version of the
model supports four flavors: model supports four flavors:
o site-vpn-flavor-single: the site belongs to only one VPN. o site-vpn-flavor-single: The site belongs to only one VPN.
o site-vpn-flavor-multi: the site belongs to multiple VPNs and all o site-vpn-flavor-multi: The site belongs to multiple VPNs, and all
the logical accesses of the sites belongs to the same set of VPNs. the logical accesses of the sites belong to the same set of VPNs.
o site-vpn-flavor-sub: the site belongs to multiple VPNs with o site-vpn-flavor-sub: The site belongs to multiple VPNs with
multiple logical accesses. Each logical access may map to multiple logical accesses. Each logical access may map to
different VPNs (one or many). different VPNs (one or many).
o site-vpn-flavor-nni: the site represents an option A NNI. o site-vpn-flavor-nni: The site represents an option A NNI.
6.5.1.1. Single VPN attachment : site-vpn-flavor-single 6.5.1.1. Single VPN Attachment: site-vpn-flavor-single
The figure below describes the single VPN attachment. The site The figure below describes a single VPN attachment. The site
connects to only one VPN. connects to only one VPN.
+--------+ +--------+
+------------------+ Site / \ +------------------+ Site / \
| |-----------------------------| | | |-----------------------------| |
| |***(site-network-access#1)***| VPN1 | | |***(site-network-access#1)***| VPN1 |
| New York Office | | | | New York Office | | |
| |***(site-network-access#2)***| | | |***(site-network-access#2)***| |
| |-----------------------------| | | |-----------------------------| |
+------------------+ \ / +------------------+ \ /
+--------+ +--------+
6.5.1.2. Multi VPN attachment : site-vpn-flavor-multi 6.5.1.2. MultiVPN Attachment: site-vpn-flavor-multi
The figure below describes a site connected to multiple VPNs. The figure below describes a site connected to multiple VPNs.
+---------+ +---------+
+---/----+ \ +---/----+ \
+------------------+ Site / | \ | +------------------+ Site / | \ |
| |--------------------------------- | |VPN B| | |--------------------------------- | |VPN B|
| |***(site-network-access#1)******* | | | | |***(site-network-access#1)******* | | |
| New York Office | | | | | | New York Office | | | | |
| |***(site-network-access#2)******* \ | / | |***(site-network-access#2)******* \ | /
| |-----------------------------| VPN A+-----|---+ | |-----------------------------| VPN A+-----|---+
+------------------+ \ / +------------------+ \ /
+--------+ +--------+
In the example above, the New York office is multihomed, both logical In the example above, the New York office is multihomed. Both
accesses are using the same VPN attachment rules. Both logical logical accesses are using the same VPN attachment rules, and both
accesses are connected to VPN A and VPN B. are connected to VPN A and VPN B.
Reaching VPN A or VPN B from New York office will be based on Reaching VPN A or VPN B from the New York office will be done via
destination based routing. Having the same destination reachable destination-based routing. Having the same destination reachable
from the two VPNs may cause routing troubles. This would be the role from the two VPNs may cause routing troubles. The customer
of the customer administration to ensure the appropriate mapping of administration's role in this case would be to ensure the appropriate
its prefixes in each VPN. mapping of its prefixes in each VPN.
6.5.1.3. Sub VPN attachment : site-vpn-flavor-sub 6.5.1.3. SubVPN Attachment: site-vpn-flavor-sub
The figure below describes a subVPN attachment. The site connects to The figure below describes a subVPN attachment. The site connects to
multiple VPNs but each logical access is attached to a particular set multiple VPNs, but each logical access is attached to a particular
of VPN. A typical use case of subVPN is a customer site used by set of VPNs. A typical use case for a subVPN is a customer site used
multiple affiliates with private resources for each affiliates that by multiple affiliates with private resources for each affiliate that
cannot be shared (communication is prevented between the affiliates). cannot be shared (communication between the affiliates is prevented).
It is similar than having separate sites instead that the customer It is similar to having separate sites, but in this case the customer
wants to share some physical components while keeping a strong wants to share some physical components while maintaining strong
communication isolation between affiliates. In the example, the communication isolation between the affiliates. In this example,
access#1 is attached to VPN B while the access#2 is attached to VPNA. site-network-access#1 is attached to VPN B, while
site-network-access#2 is attached to VPN A.
+------------------+ Site +--------+ +------------------+ Site +--------+
| |----------------------------------/ \ | |----------------------------------/ \
| |****(site-network-access#1)******| VPN B | | |****(site-network-access#1)******| VPN B |
| New York Office | \ / | New York Office | \ /
| | +--------+ | | +--------+
| | +--------+ | | +--------+
| | / \ | | / \
| |****(site-network-access#2)******| VPN A | | |****(site-network-access#2)******| VPN A |
| | \ / | | \ /
| | +--------+ | | +--------+
| |----------------------------------- | |-----------------------------------
+------------------+ +------------------+
MultiVPN can be implemented in addition to subVPN, as a consequence, A multiVPN can be implemented in addition to a subVPN; as a
each site-network-access can access to multiple VPNs. In the example consequence, each site-network-access can access multiple VPNs. In
below, access#1 is mapped to VPN B and VPN C, while access#2 is the example below, site-network-access#1 is mapped to VPN B and
mapped to VPN A and VPN D. VPN C, while site-network-access#2 is mapped to VPN A and VPN D.
+------------------+ Site +-----+ +-----------------+ Site +------+
| |----------------------------------/ +----+ | |--------------------------------/ +-----+
| |****(site-network-access#1)******| VPN B/ \ | |****(site-network-access#1)****| VPN B / \
| New York Office | \ | VPN C | | New York Office | \ | VPN C |
| | +----\ / | | +-----\ /
| | +-----+ | | +-----+
| | | |
| | +------+ | | +-------+
| | / +-----+ | | / +-----+
| |****(site-network-access#2)******| VPN A/ \ | |****(site-network-access#2)****| VPN A / \
| | \ | VPN D | | | \ | VPN D |
| | +------\ / | | +------\ /
| |----------------------------------- +---+ | |--------------------------------- +-----+
+------------------+ +-----------------+
Multihoming is also possible with subVPN, in this case, site-network- Multihoming is also possible with subVPNs; in this case,
accesses are grouped, and a particular group will access to the same site-network-accesses are grouped, and a particular group will have
set of VPNs. In the example below, access#1 and #2 are part of the access to the same set of VPNs. In the example below,
same group (multihomed together) and are mapped to VPN B and C, in site-network-access#1 and site-network-access#2 are part of the same
addition access#3 and #4 are part of the same group (multihomed group (multihomed together) and are mapped to VPN B and VPN C; in
together) and are mapped to VPN A and D. addition, site-network-access#3 and site-network-access#4 are part of
the same group (multihomed together) and are mapped to VPN A and
VPN D.
+------------------+ Site +-----+ +-----------------+ Site +------+
| |----------------------------------/ +----+ | |---------------------------------/ +-----+
| |****(site-network-access#1)******| VPNB / \ | |****(site-network-access#1)*****| VPN B / \
| New York Office |****(site-network-access#2)******\ | VPN C | | New York Office |****(site-network-access#2)***** \ | VPN C |
| | +----\ / | | +-----\ /
| | +-----+ | | +-----+
| | | |
| | +------+ | | +------+
| | / +-----+ | | / +-----+
| |****(site-network-access#3)******| VPNA / \ | |****(site-network-access#3)*****| VPN A / \
| |****(site-network-access#4)****** \ | VPN D | | |****(site-network-access#4)***** \ | VPN D |
| | +------\ / | | +-----\ /
| |----------------------------------- +---+ | |---------------------------------- +-----+
+------------------+ +-----------------+
In terms of service configuration, subVPN can be achieved by In terms of service configuration, a subVPN can be achieved by
requesting the site-network-access to use the same bearer (see requesting that the site-network-access use the same bearer (see
Section 6.6.4 and Section 6.6.6.4 for more details). Sections 6.6.4 and 6.6.6.4 for more details).
6.5.1.4. NNI : site-vpn-flavor-nni 6.5.1.4. NNI: site-vpn-flavor-nni
Some Network to Network Interface (NNI) scenario may be modeled using A Network-to-Network Interface (NNI) scenario may be modeled using
the site container (see Section 6.15.1). Using the site container to the "sites" container (see Section 6.15.1). Using the "sites"
model an NNI is only one possible option for NNI (see Section 6.15). container to model an NNI is only one possible option for NNIs (see
This option is called option A by reference to the option A NNI Section 6.15). This option is called "option A" by reference to the
defined in [RFC4364]. It is helpful for the service provider to option A NNI defined in [RFC4364]. It is helpful for the SP to
identify that the requested VPN connection is not a regular site but indicate that the requested VPN connection is not a regular site but
a NNI as specific default device configuration parameters may be rather is an NNI, as specific default device configuration parameters
applied in case of NNI (e.g. ACLs, routing policies...). may be applied in the case of NNIs (e.g., ACLs, routing policies).
SP A SP B SP A SP B
--------------------- -------------------- ------------------- -------------------
/ \ / \ / \ / \
| | | | | | | |
| ++++++++ InterAS link ++++++++ | | ++++++++ Inter-AS link ++++++++ |
| + +_____________ + + | | + +_______________+ + |
| + (VRF1)--(VPN1)----(VRF1) + | | + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + | | + ASBR + + ASBR + |
| + (VRF2)--(VPN2)----(VRF2) + | | + (VRF2)---(VPN2)----(VRF2) + |
| + +______________+ + | | + +_______________+ + |
| ++++++++ ++++++++ | | ++++++++ ++++++++ |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| ++++++++ InterAS link ++++++++ | | ++++++++ Inter-AS link ++++++++ |
| + +_____________ + + | | + +_______________+ + |
| + (VRF1)--(VPN1)----(VRF1) + | | + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + | | + ASBR + + ASBR + |
| + (VRF2)--(VPN2)----(VRF2) + | | + (VRF2)---(VPN2)----(VRF2) + |
| + +______________+ + | | + +_______________+ + |
| ++++++++ ++++++++ | | ++++++++ ++++++++ |
| | | | | | | |
| | | | | | | |
\ / \ / \ / \ /
-------------------- ------------------- ------------------- -------------------
The figure above describes an option A NNI scenario that can be The figure above describes an option A NNI scenario that can be
modeled using the site container. In order to connect its customer modeled using the "sites" container. In order to connect its
VPN (VPN1 and VPN2) on the SP B network, SP A may request the customer VPNs (VPN1 and VPN2) in SP B, SP A may request the creation
creation of some site-network-accesses to SP B. The site-vpn-flavor- of some site-network-accesses to SP B. The site-vpn-flavor-nni will
nni will be used to inform SP B that this is an NNI and not a regular be used to inform SP B that this is an NNI and not a regular customer
customer site. The site-vpn-flavor-nni may be multihomed and site. The site-vpn-flavor-nni may be multihomed and multiVPN as
multiVPN as well. well.
6.5.2. Attaching a site to a VPN 6.5.2. Attaching a Site to a VPN
Due to the multiple site-vpn flavors, the attachment of a site to an Due to the multiple site-vpn flavors, the attachment of a site to an
IPVPN is done at the site-network-access (logical access) level IP VPN is done at the site-network-access (logical access) level
through the vpn-attachment container. The vpn-attachment container through the "vpn-attachment" container. The "vpn-attachment"
is mandatory. The model provides two ways of attachment: container is mandatory. The model provides two ways to attach a site
to a VPN:
o By referencing directly the target VPN. o By referencing the target VPN directly.
o By referencing a VPN policy for more complex attachments. o By referencing a VPN policy for attachments that are more complex.
A choice is implemented to allow user to choose the best fitting A choice is implemented to allow the user to choose the flavor that
flavor. provides the best fit.
6.5.2.1. Reference a VPN 6.5.2.1. Referencing a VPN
Referencing a vpn-id provides an easy way to attach a particular Referencing a "vpn-id" provides an easy way to attach a particular
logical access to a VPN. This is the best way in case of single VPN logical access to a VPN. This is the best way in the case of a
attachment or subVPN with single VPN attachment per logical access. single VPN attachment or subVPN with a single VPN attachment per
When referencing a vpn-id, the site-role must be added to express the logical access. When referencing a "vpn-id", the "site-role" setting
role of the site in the target VPN service topology. must be added to express the role of the site in the target VPN
service topology.
<site> <site>
<site-id>SITE1</site-id> <site-id>SITE1</site-id>
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<site-network-access-id>LA1</site-network-access-id> <site-network-access-id>LA1</site-network-access-id>
<vpn-attachment> <vpn-attachment>
<vpn-id>VPNA</vpn-id> <vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
<site-network-access-id>LA2</site-network-access-id> <site-network-access>
<site-network-access-id>LA2</site-network-access-id>
<vpn-attachment> <vpn-attachment>
<vpn-id>VPNB</vpn-id> <vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses> </site-network-accesses>
</site> </site>
The example above describes a subVPN case where a site SITE1 has two The example above describes a subVPN case where a site (SITE1) has
logical accesses (LA1 and LA2) with LA1 attached to VPNA and LA2 two logical accesses (LA1 and LA2), with LA1 attached to VPNA and LA2
attached to VPNB. attached to VPNB.
6.5.2.2. VPN policy 6.5.2.2. VPN Policy
The vpn-policy helps to express a multiVPN scenario where a logical The "vpn-policy" list helps express a multiVPN scenario where a
access belongs to multiple VPNs. Multiple VPN policies can be logical access belongs to multiple VPNs. Multiple VPN policies can
created to handle the subVPN case where each logical access is part be created to handle the subVPN case where each logical access is
of a different set of VPNs. part of a different set of VPNs.
As a site can belong to multiple VPNs, the vpn-policy may be composed As a site can belong to multiple VPNs, the "vpn-policy" list may be
of multiple entries. A filter can be applied to specify that only composed of multiple entries. A filter can be applied to specify
some LANs of the site should be part of a particular VPN. Each time that only some LANs of the site should be part of a particular VPN.
a site (or LAN) is attached to a VPN, the user must precisely Each time a site (or LAN) is attached to a VPN, the user must
describe its role (site-role) within the target VPN service topology. precisely describe its role ("site-role") within the target VPN
service topology.
+--------------------------------------------------------------+ +--------------------------------------------------------------+
| Site1 ------ PE7 | | Site1 ------ PE7 |
+-------------------------+ [VPN2] | +-------------------------+ [VPN2] |
| | | |
+-------------------------+ | +-------------------------+ |
| Site2 ------ PE3 PE4 ------ Site3 | | Site2 ------ PE3 PE4 ------ Site3 |
+----------------------------------+ | +----------------------------------+ |
| | | |
+------------------------------------------------------------+ | +------------------------------------------------------------+ |
| Site4 ------ PE5 | PE6 ------ Site5 | | | Site4 ------ PE5 | PE6 ------ Site5 | |
| | | | | |
| [VPN3] | | | [VPN3] | |
+------------------------------------------------------------+ | +------------------------------------------------------------+ |
| | | |
+---------------------------+ +---------------------------+
In the example above, Site5 is part of two VPNs: VPN3 and VPN2. It In the example above, Site5 is part of two VPNs: VPN3 and VPN2. It
will play a hub-role in VPN2 and an any-to-any role in VPN3. We can will play a Hub role in VPN2 and an any-to-any role in VPN3. We can
express such multiVPN scenario as follows: express such a multiVPN scenario as follows:
<site> <site>
<site-id>Site5</site-id> <site-id>Site5</site-id>
<vpn-policies> <vpn-policies>
<vpn-policy> <vpn-policy>
<vpn-policy-id>POLICY1</vpn-policy-id> <vpn-policy-id>POLICY1</vpn-policy-id>
<entries> <entries>
<id>ENTRY1</id> <id>ENTRY1</id>
<vpn> <vpn>
<vpn-id>VPN2</vpn-id> <vpn-id>VPN2</vpn-id>
skipping to change at page 37, line 36 skipping to change at page 37, line 36
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<site-network-access-id>LA1</site-network-access-id> <site-network-access-id>LA1</site-network-access-id>
<vpn-attachment> <vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id> <vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses> </site-network-accesses>
</site> </site>
Now, if a more granular VPN attachment is necessary, filtering can be Now, if a more-granular VPN attachment is necessary, filtering can be
used. For example, if LAN1 from Site5 must be attached to VPN2 as used. For example, if LAN1 from Site5 must be attached to VPN2 as a
Hub and LAN2 must be attached to VPN3, the following configuration Hub and LAN2 must be attached to VPN3, the following configuration
can be used: can be used:
<site> <site>
<site-id>Site5</site-id> <site-id>Site5</site-id>
<vpn-policies> <vpn-policies>
<vpn-policy> <vpn-policy>
<vpn-policy-id>POLICY1</vpn-policy-id> <vpn-policy-id>POLICY1</vpn-policy-id>
<entries> <entries>
<id>ENTRY1</id> <id>ENTRY1</id>
skipping to change at page 38, line 42 skipping to change at page 38, line 42
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<site-network-access-id>LA1</site-network-access-id> <site-network-access-id>LA1</site-network-access-id>
<vpn-attachment> <vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id> <vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses> </site-network-accesses>
</site> </site>
6.6. Deciding where to connect the site 6.6. Deciding Where to Connect the Site
The management system will have to determine where to connect each The management system will have to determine where to connect each
site-network-access of a particular site to the provider network (PE, site-network-access of a particular site to the provider network
aggregation switch ...). (e.g., PE, aggregation switch).
The current model proposes parameters and constraints that can The current model proposes parameters and constraints that can
influence the meshing of the site-network-access. influence the meshing of the site-network-access.
The management system SHOULD honor the customer constraints, if the The management system SHOULD honor any customer constraints. If a
constraint is too strict and can not be filled, the management system constraint is too strict and cannot be fulfilled, the management
MUST not provision the site and SHOULD provide an information to the system MUST NOT provision the site and SHOULD provide relevant
user. How the information is provided is out of scope of the information to the user. How the information is provided is out of
document. It would then be up to the user to relax the constraint or scope for this document. Whether or not to relax the constraint
not. would then be left up to the user.
Parameters are just hints for the management system for service Parameters are just hints for the management system for service
placement. placement.
In addition to parameters and constraints, the management system In addition to parameters and constraints, the management system's
decision MAY be based on any other internal constraint that are up to decision MAY be based on any other internal constraints that are left
the service provider: least load, distance ... up to the SP: least load, distance, etc.
6.6.1. Constraint: Device 6.6.1. Constraint: Device
In case of provider-management or co-management, one or more devices In the case of provider management or co-management, one or more
have been ordered by the customer. The customer may force a devices have been ordered by the customer. The customer may force a
particular site-network-access to be connected on a particular device particular site-network-access to be connected on a particular device
he ordered. that he ordered.
New York Site New York Site
+------------------+ Site +------------------+ Site
| +--------------+ |----------------------------------- | +--------------+ |-----------------------------------
| | Manhattan | | | | Manhattan | |
| | CE1********* (site-network-access#1) ****** | | CE1********* (site-network-access#1) ******
| +--------------+ | | +--------------+ |
| +--------------+ | | +--------------+ |
| | Brooklyn CE2********* (site-network-access#2) ****** | | Brooklyn CE2********* (site-network-access#2) ******
| +--------------+ | | +--------------+ |
| |----------------------------------- | |-----------------------------------
+------------------+ +------------------+
In the figure above, the site-network-access#1 is associated to CE1 In the figure above, site-network-access#1 is associated with CE1 in
in the service request. The service provider must ensure the the service request. The SP must ensure the provisioning of this
provisionning of this connection. connection.
6.6.2. Constraint/parameter: Site location 6.6.2. Constraint/Parameter: Site Location
The location information provided in this model MAY be used by a The location information provided in this model MAY be used by a
management system to determine the target PE to mesh the site management system to determine the target PE to mesh the site
(service provider side). A particular location must be associated to (SP side). A particular location must be associated with each site
each site network access when configuring it. The service provider network access when configuring it. The SP MUST honor the
MUST honor the termination of the access on the location associated termination of the access on the location associated with the site
with the site network access (customer side). The country-code in network access (customer side). The country-code in the
the site-location SHOULD be expressed as an ISO ALPHA-2 code. site-location SHOULD be expressed as an ISO ALPHA-2 code.
The site-network-access location is determined by the "location- The site-network-access location is determined by the
flavor". In case of provider-managed or co-managed site, the user is "location-flavor". In the case of a provider-managed or co-managed
expected to configure a "device-reference" (device case) that will site, the user is expected to configure a "device-reference" (device
bind the site-network-access to a particular device the customer case) that will bind the site-network-access to a particular device
ordered. As each device is already associated to a particular that the customer ordered. As each device is already associated with
location, in such case the location information is retrieved from the a particular location, in such a case the location information is
device location. In case of customer-managed site, the user is retrieved from the device location. In the case of a customer-
expected to configure a "location-reference" (location case), this managed site, the user is expected to configure a
provides a reference to an existing configured location and will help "location-reference" (location case); this provides a reference to an
the placement. existing configured location and will help with placement.
PoP#1 (New York) POP#1 (New York)
+---------+ +---------+
| PE1 | | PE1 |
Site #1 ---... | PE2 | Site #1 ---... | PE2 |
(Atlantic City) | PE3 | (Atlantic City) | PE3 |
+---------+ +---------+
PoP#2 (Washington) POP#2 (Washington)
+---------+ +---------+
| PE4 | | PE4 |
| PE5 | | PE5 |
| PE6 | | PE6 |
+---------+ +---------+
PoP#3 (Philadelphia) POP#3 (Philadelphia)
+---------+ +---------+
| PE7 | | PE7 |
Site #2 CE#1---... | PE2 | Site #2 CE#1---... | PE2 |
(Reston) | PE9 | (Reston) | PE9 |
+---------+ +---------+
In the example above, Site#1 is a customer managed site with a In the example above, Site #1 is a customer-managed site with a
location L1, while Site#2 is a provider-managed site for which a CE#1 location L1, while Site #2 is a provider-managed site for which a CE
was ordered, Site#2 is configured with L2 as location. When (CE#1) was ordered. Site #2 is configured with L2 as its location.
configuring a site-network-access for Site#1, the user will need to When configuring a site-network-access for Site #1, the user will
reference the location L1, so the management system will know that need to reference location L1 so that the management system will know
the access will need to terminate on this location. Then this that the access will need to terminate on this location. Then, for
management system may mesh Site#1 on a PE in the Philadelphia PoP for distance reasons, this management system may mesh Site #1 on a PE in
distance reason. It may also take into account resources available the Philadelphia POP. It may also take into account resources
on PEs to determine the exact target PE (e.g. least loaded). available on PEs to determine the exact target PE (e.g., least
Regarding Site#2, the user is expected to configure the site-network- loaded). For Site #2, the user is expected to configure the
access with a device-reference to CE#1, so the management system will site-network-access with a "device-reference" to CE#1 so that the
know that the access must terminate on the location of CE#1 and must management system will know that the access must terminate on the
be connected to CE#1. For placing the service provider side of the location of CE#1 and must be connected to CE#1. For placement of the
access connection, in case of shortest distance PE used, it may mesh SP side of the access connection, in the case of the nearest PE used,
Site #2 on the Washington PoP. it may mesh Site #2 on the Washington POP.
6.6.3. Constraint/parameter: access type 6.6.3. Constraint/Parameter: Access Type
The management system needs to elect the access media to connect the The management system needs to elect the access media to connect the
site to the customer (for example : xDSL, leased line, Ethernet site to the customer (for example, xDSL, leased line, Ethernet
backhaul ...). The customer may provide some parameters/constraints backhaul). The customer may provide some parameters/constraints that
that will provide hints to the management system. will provide hints to the management system.
The bearer container information SHOULD be used as first input : The "bearer" container information SHOULD be the first piece of
information considered when making this decision:
o The "requested-type" provides an information about the media type o The "requested-type" parameter provides information about the
the customer would like. If the "strict" leaf is equal to "true", media type that the customer would like to use. If the "strict"
this MUST be considered as a strict constraint, so the management leaf is equal to "true", this MUST be considered a strict
system cannot connect the site with another media type. If the constraint so that the management system cannot connect the site
"strict" leaf is equal to "false" (default), if the requested-type with another media type. If the "strict" leaf is equal to "false"
cannot be fulfilled, the management system can select another (default) and if the requested media type cannot be fulfilled, the
type. The supported media types SHOULD be communicated by the management system can select another media type. The supported
service provider to the customer by a mechanism that is out of media types SHOULD be communicated by the SP to the customer via a
scope of the document. mechanism that is out of scope for this document.
o The "always-on" leaf defines a strict constraint: if set to o The "always-on" leaf defines a strict constraint: if set to true,
"true", the management system MUST elect a media type which is the management system MUST elect a media type that is "always-on"
always-on (this means no dial access type). (e.g., this means no dial access type).
o The "bearer-reference" is used in case the customer has already o The "bearer-reference" parameter is used in cases where the
ordered a network connection to the service provider apart of the customer has already ordered a network connection to the SP apart
IPVPN site and wants to reuse this connection. The string used in from the IP VPN site and wants to reuse this connection. The
an internal reference from the service provider describing the string used is an internal reference from the SP and describes the
already available connection. This is also a strict requirement already-available connection. This is also a strict requirement
that cannot be relaxed. How the reference is given to the that cannot be relaxed. How the reference is given to the
customer is out of scope of the document but as a pure example, customer is out of scope for this document, but as a pure example,
when the customer ordered the bearer (through a process out of when the customer ordered the bearer (through a process that is
this model), the service provider may had provided the bearer out of scope for this model), the SP may have provided the bearer
reference that can be used for provisionning services on top. reference that can be used for provisioning services on top.
Any other internal parameters from the service provider can be used Any other internal parameters from the SP can also be used. The
in addition. The management system MAY use other parameters such as management system MAY use other parameters, such as the requested
the requested svc-input-bandwidth and svc-output-bandwidth to help to "svc-input-bandwidth" and "svc-output-bandwidth", to help decide
decide the access type to be used. which access type to use.
6.6.4. Constraint: access diversity 6.6.4. Constraint: Access Diversity
Each site-network-access may have one or more constraints that would Each site-network-access may have one or more constraints that would
drive the placement of the access. By default, the model assumes no drive the placement of the access. By default, the model assumes
constraint but is expected allocation of a unique bearer per site- that there are no constraints, but allocation of a unique bearer per
network-access. site-network-access is expected.
In order to help the different placement scenarios, a site-network- In order to help with the different placement scenarios, a
access may be tagged using one or multiple group identifiers. The site-network-access may be tagged using one or multiple group
group identifier is a string so it can accommodate both explicit identifiers. The group identifier is a string, so it can accommodate
naming of a group of sites (e.g. "multihomed-set1" or "subVPN") or a both explicit naming of a group of sites (e.g., "multihomed-set1" or
numbered identifier (e.g. 12345678). The meaning of each group-id is "subVPN") and the use of a numbered identifier (e.g., 12345678). The
local to each customer administrator. And the management system MUST meaning of each group-id is local to each customer administrator, and
ensure that different customers can use the same group-ids. One or the management system MUST ensure that different customers can use
more group-ids can also be defined at the site-level, as a the same group-ids. One or more group-ids can also be defined at the
consequence, all site-network-accesses under the site MUST inherit site level; as a consequence, all site-network-accesses under the
the group-ids of the site they are belonging to. When, in addition site MUST inherit the group-ids of the site they belong to. When, in
to the site group-ids, some group-ids are defined at the site- addition to the site group-ids some group-ids are defined at the
network-access level, the management system MUST consider the union site-network-access level, the management system MUST consider the
of all groups (site level and site network access level) for this union of all groups (site level and site network access level) for
particular site-network-access. this particular site-network-access.
For an already configured site-network-access, each constraint MUST For an already-configured site-network-access, each constraint MUST
be expressed against a targeted set of site-network-accesses, this be expressed against a targeted set of site-network-accesses. This
site-network-access MUST never be taken into account in the targeted site-network-access MUST never be taken into account in the targeted
set: e.g. "My site-network-access S must not be connected on the set -- for example, "My site-network-access S must not be connected
same PoP as the site-network-accesses that are part of group 10". on the same POP as the site-network-accesses that are part of
The set of site-network-accesses against which the constraint is Group 10." The set of site-network-accesses against which the
evaluated can be expressed as a list of groups or "all-other- constraint is evaluated can be expressed as a list of groups,
accesses" or "all-other-groups". The "all-other-accesses" option "all-other-accesses", or "all-other-groups". The
means that the current site-network-access constraint MUST be "all-other-accesses" option means that the current
evaluated against all the other site-network-accesses belonging to site-network-access constraint MUST be evaluated against all the
the current site. The "all-other-groups" option means that the other site-network-accesses belonging to the current site. The
constraint MUST be evaluated against all groups the current site- "all-other-groups" option means that the constraint MUST be evaluated
network-access is not belonging to. against all groups that the current site-network-access does not
belong to.
The current model proposes multiple constraint-types: The current model proposes multiple constraint-types:
pe-diverse: the current site-network-access MUST not be connected o pe-diverse: The current site-network-access MUST NOT be connected
to the same PE as the targeted site-network-accesses. to the same PE as the targeted site-network-accesses.
pop-diverse: the current site-network-access MUST not be connected o pop-diverse: The current site-network-access MUST NOT be connected
to the same PoP as the targeted site-network-accesses. to the same POP as the targeted site-network-accesses.
linecard-diverse: the current site-network-access MUST not be o linecard-diverse: The current site-network-access MUST NOT be
connected to the same linecard as the targeted site-network- connected to the same linecard as the targeted
accesses. site-network-accesses.
bearer-diverse: the current site-network-access MUST NOT use o bearer-diverse: The current site-network-access MUST NOT use
common bearer components compared to bearers used by the targeted common bearer components compared to bearers used by the targeted
site-network-accesses. "bearer-diverse" provides some level of site-network-accesses. "bearer-diverse" provides some level of
diversity at the access level. As an example, two "bearer- diversity at the access level. As an example, two
diverse" site-network-accesses must not use the same DSLAM or BAS "bearer-diverse" site-network-accesses must not use the same
or layer 2 switch... DSLAM, BAS, or Layer 2 switch.
same-pe: the current site-network-access MUST be connected to the o same-pe: The current site-network-access MUST be connected to the
same PE as the targeted site-network-accesses. same PE as the targeted site-network-accesses.
same-bearer: the current site-network-access MUST be connected o same-bearer: The current site-network-access MUST be connected
using the same bearer as the targeted site-network-accesses. using the same bearer as the targeted site-network-accesses.
These constraint-types can be extended through augmentation. These constraint-types can be extended through augmentation.
Each constraint is expressed as "The site-network-access S must be Each constraint is expressed as "The site-network-access S must be
<constraint-type> (e.g. pe-diverse, pop-diverse) from these <target> <constraint-type> (e.g., pe-diverse, pop-diverse) from these <target>
site-network-accesses". site-network-accesses."
The group-id used to target some site-network-accesses may be the The group-id used to target some site-network-accesses may be the
same as the one used by the current site-network-access. This eases same as the one used by the current site-network-access. This eases
configuration of scenarios where a group of site-network-access has a the configuration of scenarios where a group of site-network-access
constraint between each other. As an example if we want a set of points has a constraint between the access points in the group. As
sites (site#1 up to #5) to be connected on different PEs, we can tag an example, if we want a set of sites (Site#1 to Site#5) to be
them with the same group-id and express a pe-diverse constraint for connected on different PEs, we can tag them with the same group-id
this group-id. and express a pe-diverse constraint for this group-id.
<site> <site>
<site-id>SITE1</site-id> <site-id>SITE1</site-id>
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<site-network-access-id>1</site-network-access-id> <site-network-access-id>1</site-network-access-id>
<access-diversity> <access-diversity>
<groups> <groups>
<group> <group>
<group-id>10</group-id> <group-id>10</group-id>
skipping to change at page 45, line 15 skipping to change at page 45, line 18
</constraints> </constraints>
</access-diversity> </access-diversity>
<vpn-attachment> <vpn-attachment>
<vpn-id>VPNA</vpn-id> <vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses> </site-network-accesses>
</site> </site>
The group-id used to target some site-network-accesses may be also The group-id used to target some site-network-accesses may also be
different than the one used by the current site-network-access. This different than the one used by the current site-network-access. This
can be used to express that a group of site has some constraints can be used to express that a group of sites has some constraints
against another group of sites, but there is no constraint within the against another group of sites, but there is no constraint within the
group. As an example, if we consider a set of 6 sites with two sets group. For example, we consider a set of six sites and two groups;
and we want to ensure that a site in the first set must be pop- we want to ensure that a site in the first group must be pop-diverse
diverse from a site in the second set. from a site in the second group:
<site> <site>
<site-id>SITE1</site-id> <site-id>SITE1</site-id>
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<site-network-access-id>1</site-network-access-id> <site-network-access-id>1</site-network-access-id>
<access-diversity> <access-diversity>
<groups> <groups>
<group> <group>
<group-id>10</group-id> <group-id>10</group-id>
skipping to change at page 47, line 45 skipping to change at page 47, line 47
</constraints> </constraints>
</access-diversity> </access-diversity>
<vpn-attachment> <vpn-attachment>
<vpn-id>VPNA</vpn-id> <vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses> </site-network-accesses>
</site> </site>
6.6.5. Impossible access placement 6.6.5. Infeasible Access Placement
Some impossible placement scenarios may be created through the Some infeasible access placement scenarios could be created via the
proposed configuration framework. Impossible scenarios could come proposed configuration framework. Such infeasible access placement
from too restrictive constraints leading to impossible placement in scenarios could result from constraints that are too restrictive,
the network or conflicting constraints that would also lead to leading to infeasible access placement in the network or conflicting
impossible placement. An example of conflicting rules would be to constraints that would also lead to infeasible access placement. An
request a site-network-access#1 to be pe-diverse from a site-network- example of conflicting rules would be to request that
access#2 and to request at the same time that site-network-access#2 site-network-access#1 be pe-diverse from site-network-access#2 and to
to be on the same PE as site-network-access#1. When the management request at the same time that site-network-access#2 be on the same PE
system cannot determine the placement of a site-network-access, it as site-network-access#1. When the management system cannot
SHOULD return an error message indicating that placement was not determine the placement of a site-network-access, it SHOULD return an
possible. error message indicating that placement was not possible.
6.6.6. Examples of access placement 6.6.6. Examples of Access Placement
6.6.6.1. Multihoming 6.6.6.1. Multihoming
The customer wants to create a multihomed site. The site will be The customer wants to create a multihomed site. The site will be
composed of two site-network-accesses and the customer wants the two composed of two site-network-accesses; for resiliency purposes, the
site-network-accesses to be meshed on different PoPs for resiliency customer wants the two site-network-accesses to be meshed on
purpose. different POPs.
PoP#1 POP#1
+-------+ +---------+ +-------+ +---------+
| | | PE1 | | | | PE1 |
| |---site_network_access#1 ---- | PE2 | | |---site-network-access#1----| PE2 |
| | | PE3 | | | | PE3 |
| | +---------+ | | +---------+
| Site#1| | Site#1|
| | PoP#2 | | POP#2
| | +---------+ | | +---------+
| | | PE4 | | | | PE4 |
| |---site_network_access#2 ---- | PE5 | | |---site-network-access#2----| PE5 |
| | | PE6 | | | | PE6 |
| | +---------+ | | +---------+
+-------+ +-------+
This scenario can be expressed in the following way: This scenario can be expressed as follows:
<site> <site>
<site-id>SITE1</site-id> <site-id>SITE1</site-id>
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<site-network-access-id>1</site-network-access-id> <site-network-access-id>1</site-network-access-id>
<access-diversity> <access-diversity>
<groups> <groups>
<group> <group>
<group-id>10</group-id> <group-id>10</group-id>
skipping to change at page 49, line 42 skipping to change at page 49, line 45
</constraints> </constraints>
</access-diversity> </access-diversity>
<vpn-attachment> <vpn-attachment>
<vpn-id>VPNA</vpn-id> <vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses> </site-network-accesses>
</site> </site>
But it can also be expressed as: But it can also be expressed as follows:
<site> <site>
<site-id>SITE1</site-id> <site-id>SITE1</site-id>
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<site-network-access-id>1</site-network-access-id> <site-network-access-id>1</site-network-access-id>
<access-diversity> <access-diversity>
<constraints> <constraints>
<constraint> <constraint>
<constraint-type>pop-diverse</constraint-type> <constraint-type>pop-diverse</constraint-type>
skipping to change at page 50, line 45 skipping to change at page 50, line 45
</constraints> </constraints>
</access-diversity> </access-diversity>
<vpn-attachment> <vpn-attachment>
<vpn-id>VPNA</vpn-id> <vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses> </site-network-accesses>
</site> </site>
6.6.6.2. Site offload 6.6.6.2. Site Offload
The customer has six branch offices in a particular region and he The customer has six branch offices in a particular region, and he
wants to prevent to have all branch offices to be connected on the wants to prevent having all branch offices connected on the same PE.
same PE.
He wants to express that three branch offices cannot be connected on He wants to express that three branch offices cannot be connected on
the same linecard. And the other branch offices must be connected on the same linecard. Also, the other branch offices must be connected
a different PoP. Those other branch offices cannot also be connected on a different POP. Those other branch offices cannot also be
on the same linecard. connected on the same linecard.
PoP#1 POP#1
+---------+ +---------+
| PE1 | | PE1 |
Office#1 ---... | PE2 | Office#1 ---... | PE2 |
Office#2 ---... | PE3 | Office#2 ---... | PE3 |
Office#3 ---... | PE4 | Office#3 ---... | PE4 |
+---------+ +---------+
PoP#2 POP#2
+---------+ +---------+
Office#4 ---... | PE4 | Office#4 ---... | PE5 |
Office#5 ---... | PE5 | Office#5 ---... | PE6 |
Office#6 ---... | PE6 | Office#6 ---... | PE7 |
+---------+ +---------+
This scenario can be expressed in the following way: This scenario can be expressed as follows:
o We need to create two sets of sites: set#1 composed of Office#1 up o We need to create two groups of sites: Group#10, which is composed
to 3, set#2 composed of Office#4 up to 6. of Office#1, Office#2, and Office#3; and Group#20, which is
composed of Office#4, Office#5, and Office#6.
o Sites within set#1 must be pop-diverse from sites within set#2 and o Sites within Group#10 must be pop-diverse from sites within
vice versa. Group#20, and vice versa.
o Sites within set#1 must be linecard-diverse from other sites in o Sites within Group#10 must be linecard-diverse from other sites in
set#1 (same for set#2). Group#10 (same for Group#20).
<site> <site>
<site-id>SITE1</site-id> <site-id>Office1</site-id>
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<site-network-access-id>1</site-network-access-id> <site-network-access-id>1</site-network-access-id>
<access-diversity> <access-diversity>
<groups> <groups>
<group> <group>
<group-id>10</group-id> <group-id>10</group-id>
</group> </group>
</groups> </groups>
<constraints> <constraints>
skipping to change at page 52, line 23 skipping to change at page 52, line 22
</group> </group>
</target> </target>
</constraint> </constraint>
</constraints> </constraints>
</access-diversity> </access-diversity>
<vpn-attachment> <vpn-attachment>
<vpn-id>VPNA</vpn-id> <vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses>
</site> </site>
<site> <site>
<site-id>SITE2</site-id> <site-id>Office2</site-id>
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<site-network-access-id>1</site-network-access-id> <site-network-access-id>1</site-network-access-id>
<access-diversity> <access-diversity>
<groups> <groups>
<group> <group>
<group-id>10</group-id> <group-id>10</group-id>
</group> </group>
</groups> </groups>
<constraints> <constraints>
skipping to change at page 53, line 4 skipping to change at page 52, line 52
</target> </target>
</constraint> </constraint>
<constraint> <constraint>
<constraint-type>linecard-diverse</constraint-type> <constraint-type>linecard-diverse</constraint-type>
<target> <target>
<group> <group>
<group-id>10</group-id> <group-id>10</group-id>
</group> </group>
</target> </target>
</constraint> </constraint>
</constraints> </constraints>
</access-diversity> </access-diversity>
<vpn-attachment> <vpn-attachment>
<vpn-id>VPNA</vpn-id> <vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses>
</site> </site>
<site> <site>
<site-id>SITE3</site-id> <site-id>Office3</site-id>
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<site-network-access-id>1</site-network-access-id> <site-network-access-id>1</site-network-access-id>
<access-diversity> <access-diversity>
<groups> <groups>
<group> <group>
<group-id>10</group-id> <group-id>10</group-id>
</group> </group>
</groups> </groups>
<constraints> <constraints>
skipping to change at page 53, line 50 skipping to change at page 53, line 50
</constraint> </constraint>
</constraints> </constraints>
</access-diversity> </access-diversity>
<vpn-attachment> <vpn-attachment>
<vpn-id>VPNA</vpn-id> <vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses> </site-network-accesses>
</site> </site>
<site> <site>
<site-id>SITE4</site-id> <site-id>Office4</site-id>
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<site-network-access-id>1</site-network-access-id> <site-network-access-id>1</site-network-access-id>
<access-diversity> <access-diversity>
<groups> <groups>
<group> <group>
<group-id>20</group-id> <group-id>20</group-id>
</group> </group>
</groups> </groups>
<constraints> <constraints>
skipping to change at page 54, line 37 skipping to change at page 54, line 36
</group> </group>
</target> </target>
</constraint> </constraint>
</constraints> </constraints>
</access-diversity> </access-diversity>
<vpn-attachment> <vpn-attachment>
<vpn-id>VPNA</vpn-id> <vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses>
</site> </site>
<site> <site>
<site-id>SITE5</site-id> <site-id>Office5</site-id>
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<site-network-access-id>1</site-network-access-id> <site-network-access-id>1</site-network-access-id>
<access-diversity> <access-diversity>
<groups> <groups>
<group> <group>
<group-id>20</group-id> <group-id>20</group-id>
</group> </group>
</groups> </groups>
<constraints> <constraints>
skipping to change at page 55, line 25 skipping to change at page 55, line 25
</group> </group>
</target> </target>
</constraint> </constraint>
</constraints> </constraints>
</access-diversity> </access-diversity>
<vpn-attachment> <vpn-attachment>
<vpn-id>VPNA</vpn-id> <vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses>
</site> </site>
<site> <site>
<site-id>SITE6</site-id> <site-id>Office6</site-id>
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<site-network-access-id>1</site-network-access-id> <site-network-access-id>1</site-network-access-id>
<access-diversity> <access-diversity>
<groups> <groups>
<group> <group>
<group-id>20</group-id> <group-id>20</group-id>
</group> </group>
</groups> </groups>
<constraints> <constraints>
skipping to change at page 55, line 51 skipping to change at page 56, line 4
<group> <group>
<group-id>10</group-id> <group-id>10</group-id>
</group> </group>
</target> </target>
</constraint> </constraint>
<constraint> <constraint>
<constraint-type>linecard-diverse</constraint-type> <constraint-type>linecard-diverse</constraint-type>
<target> <target>
<group> <group>
<group-id>20</group-id> <group-id>20</group-id>
</group>
</group>
</target> </target>
</constraint> </constraint>
</constraints> </constraints>
</access-diversity> </access-diversity>
<vpn-attachment> <vpn-attachment>
<vpn-id>VPNA</vpn-id> <vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses> </site-network-accesses>
</site> </site>
6.6.6.3. Parallel links 6.6.6.3. Parallel Links
To increase its site bandwidth at a cheaper cost, a customer wants to To increase its site bandwidth at lower cost, a customer wants to
order two parallel site-network-accesses that will be connected to order two parallel site-network-accesses that will be connected to
the same PE. the same PE.
*******SNA1********** *******site-network-access#1**********
Site 1 *******SNA2********** PE1 Site 1 *******site-network-access#2********** PE1
This scenario can be expressed in the following way: This scenario can be expressed as follows:
<site> <site>
<site-id>SITE1</site-id> <site-id>SITE1</site-id>
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<site-network-access-id>1</site-network-access-id> <site-network-access-id>1</site-network-access-id>
<access-diversity> <access-diversity>
<groups> <groups>
<group> <group>
<group-id>PE-linkgrp-1</group-id> <group-id>PE-linkgrp-1</group-id>
skipping to change at page 57, line 35 skipping to change at page 57, line 34
</constraints> </constraints>
</access-diversity> </access-diversity>
<vpn-attachment> <vpn-attachment>
<vpn-id>VPNB</vpn-id> <vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses> </site-network-accesses>
</site> </site>
6.6.6.4. SubVPN with multihoming 6.6.6.4. SubVPN with Multihoming
A customer has site which is dualhomed. The dualhoming must be done A customer has a site that is dual-homed. The dual-homing must be
on two different PEs. The customer wants also to implement two done on two different PEs. The customer also wants to implement two
subVPNs on those multihomed accesses. subVPNs on those multihomed accesses.
+------------------+ Site +-----+ +-----------------+ Site +------+
| |----------------------------------/ +----+ | |---------------------------------/ +-----+
| |****(site-network-access#1)******| VPNB / \ | |****(site-network-access#1)*****| VPN B / \
| New York Office |****(site-network-access#2)*************| VPN C | | New York Office |****(site-network-access#2)************| VPN C |
| | +----\ / | | +-----\ /
| | +-----+ | | +-----+
| | | |
| | +------+ | | +------+
| | / +-----+ | | / +-----+
| |****(site-network-access#3)******| VPNB / \ | |****(site-network-access#3)*****| VPN B / \
| |****(site-network-access#4)**************| VPN C | | |****(site-network-access#4)************| VPN C |
| | +------\ / | | +-----\ /
| |----------------------------------- +---+ | |----------------------------------- +-----+
+------------------+ +-----------------+
This scenario can be expressed in the following way: This scenario can be expressed as follows:
o The site will have 4 site network accesses (2 subVPN coupled with o The site will have four site network accesses (two subVPNs coupled
dual homing). via dual-homing).
o Site-network-access#1 and #3 will correspond to the multihoming of o Site-network-access#1 and site-network-access#3 will correspond to
the subVPN B. A PE-diverse constraint is required between them. the multihoming of subVPN B. A PE-diverse constraint is required
between them.
o Site-network-access#2 and #4 will correspond to the multihoming of o Site-network-access#2 and site-network-access#4 will correspond to
the subVPN C. A PE-diverse constraint is required between them. the multihoming of subVPN C. A PE-diverse constraint is required
between them.
o To ensure proper usage of the same bearer for the subVPN, site- o To ensure proper usage of the same bearer for the subVPN,
network-access #1 and #2 must share the same bearer as site- site-network-access#1 and site-network-access#2 must share the
network-access #3 and #4. same bearer as site-network-access#3 and site-network-access#4.
<site> <site>
<site-id>SITE1</site-id> <site-id>SITE1</site-id>
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<site-network-access-id>1</site-network-access-id> <site-network-access-id>1</site-network-access-id>
<access-diversity> <access-diversity>
<groups> <groups>
<group> <group>
<group-id>dualhomed-1</group-id> <group-id>dualhomed-1</group-id>
skipping to change at page 60, line 4 skipping to change at page 60, line 6
<group-id>dualhomed-1</group-id> <group-id>dualhomed-1</group-id>
</group> </group>
</target> </target>
</constraint> </constraint>
</constraints> </constraints>
</access-diversity> </access-diversity>
<vpn-attachment> <vpn-attachment>
<vpn-id>VPNC</vpn-id> <vpn-id>VPNC</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
<site-network-access>
<site-network-access-id>3</site-network-access-id> <site-network-access-id>3</site-network-access-id>
<access-diversity> <access-diversity>
<groups> <groups>
<group> <group>
<group-id>dualhomed-2</group-id> <group-id>dualhomed-2</group-id>
</group> </group>
</groups> </groups>
<constraints> <constraints>
<constraint> <constraint>
<constraint-type>pe-diverse</constraint-type> <constraint-type>pe-diverse</constraint-type>
skipping to change at page 61, line 24 skipping to change at page 61, line 26
</constraints> </constraints>
</access-diversity> </access-diversity>
<vpn-attachment> <vpn-attachment>
<vpn-id>VPNC</vpn-id> <vpn-id>VPNC</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses> </site-network-accesses>
</site> </site>
6.6.7. Route Distinguisher and VRF allocation 6.6.7. Route Distinguisher and VRF Allocation
The route-distinguisher is a critical parameter of PE-based L3VPNs as The route distinguisher (RD) is a critical parameter of PE-based
described in [RFC4364] that allows to distinguish common addressing L3VPNs as described in [RFC4364] that provides the ability to
plans in different VPNs. As for route-targets, it is expected that a distinguish common addressing plans in different VPNs. As for route
management system will allocate a VRF on the target PE and a route- targets (RTs), a management system is expected to allocate a VRF on
distinguisher for this VRF. the target PE and an RD for this VRF.
If a VRF already exists on the target PE, and the VRF fulfils the If a VRF already exists on the target PE and the VRF fulfills the
connectivity constraints for the site, there is no need to recreate connectivity constraints for the site, there is no need to recreate
another VRF and the site MAY be meshed within this existing VRF. How another VRF, and the site MAY be meshed within this existing VRF.
the management system checks that an existing VRF fulfils the How the management system checks that an existing VRF fulfills the
connectivity constraints for a site is out of scope of this document. connectivity constraints for a site is out of scope for this
document.
If no such a VRF exists on the target PE, the management system has If no such VRF exists on the target PE, the management system has to
to initiate a new VRF creation on the target PE and has to allocate a initiate the creation of a new VRF on the target PE and has to
new route-distinguisher for this new VRF. allocate a new RD for this new VRF.
The management system MAY apply a per-VPN or per-VRF allocation The management system MAY apply a per-VPN or per-VRF allocation
policy for the route-distinguisher depending on the service provider policy for the RD, depending on the SP's policy. In a per-VPN
policy. In a per-VPN allocation policy, all VRFs (dispatched on allocation policy, all VRFs (dispatched on multiple PEs) within a VPN
multiple PEs) within a VPN will share the same route distinguisher will share the same RD value. In a per-VRF model, all VRFs should
value. In a per-VRF model, all VRFs should always have a unique always have a unique RD value. Some other allocation policies are
route-distinguisher value. Some other allocation policies are also also possible, and this document does not restrict the allocation
possible, and this document does not restrict the allocation policies policies to be used.
to be used.
The allocation of route-distinguishers MAY be done in the same way as The allocation of RDs MAY be done in the same way as RTs. The
route-targets. The example provided in Section 6.2.1.1 could be examples provided in Section 6.2.1.1 could be reused in this
reused. scenario.
Note that a service provider MAY configure a target PE for an Note that an SP MAY configure a target PE for an automated allocation
automated allocation of route-distinguishers. In this case, there of RDs. In this case, there will be no need for any backend system
will be no need for any backend system to allocate a route- to allocate an RD value.
distinguisher value.
6.7. Site network access availability 6.7. Site Network Access Availability
A site may be multihomed, meaning it has multiple site-network-access A site may be multihomed, meaning that it has multiple
points. Placement constraints defined in previous sections will help site-network-access points. Placement constraints defined in
to ensure physical diversity. previous sections will help ensure physical diversity.
When the site-network-accesses are placed on the network, a customer When the site-network-accesses are placed on the network, a customer
may want to use a particular routing policy on those accesses. may want to use a particular routing policy on those accesses.
The "site-network-access/availability" container defines parameters The "site-network-access/availability" container defines parameters
for the site redundancy. The "access-priority" leaf defines a for site redundancy. The "access-priority" leaf defines a preference
preference for a particular access. This preference is used to model for a particular access. This preference is used to model
loadbalancing or primary/backup scenarios. The higher the access- load-balancing or primary/backup scenarios. The higher the
priority the higher the preference will be. "access-priority" value, the higher the preference will be.
The figure below describes how the access-priority attribute can be The figure below describes how the "access-priority" attribute can be
used. used.
Hub#1 LAN (Primary/backup) Hub#2 LAN (Loadsharing) Hub#1 LAN (Primary/backup) Hub#2 LAN (Load-sharing)
| | | |
| access-priority 1 access-priority 1 | | access-priority 1 access-priority 1 |
|--- CE1 ------- PE1 PE3 --------- CE3 --- | |--- CE1 ------- PE1 PE3 --------- CE3 --- |
| | | |
| | | |
|--- CE2 ------- PE2 PE4 --------- CE4 --- | |--- CE2 ------- PE2 PE4 --------- CE4 --- |
| access-priority 2 access-priority 1 | | access-priority 2 access-priority 1 |
PE5 PE5
| |
| |
| |
CE5 CE5
| |
Spoke#1 site (Single-homed) Spoke#1 site (Single-homed)
In the figure above, Hub#2 requires loadsharing so all the site- In the figure above, Hub#2 requires load-sharing, so all the
network-accesses must use the same access-priority value. On the site-network-accesses must use the same "access-priority" value. On
contrary, as Hub#1 requires primary/backup, an higher access-priority the other hand, as Hub#1 requires a primary site-network-access and a
will be configured on the primary access. backup site-network-access, a higher "access-priority" setting will
be configured on the primary site-network-access.
More complex scenarios can be modeled. Let's consider a Hub site Scenarios that are more complex can be modeled. Let's consider a Hub
with five accesses to the network (A1,A2,A3,A4,A5). The customer site with five accesses to the network (A1,A2,A3,A4,A5). The
wants to loadshare its traffic on A1,A2 in the nominal situation. If customer wants to load-share its traffic on A1,A2 in the nominal
A1 and A2 fails, he wants to loadshare its traffic on A3 and A4, and situation. If A1 and A2 fail, the customer wants to load-share its
finally if A1 to A4 are down, he wants to use A5. We can model it traffic on A3 and A4; finally, if A1 to A4 are down, he wants to
easily by configuring the following access-priorities: A1=100, use A5. We can model this easily by configuring the following
A2=100, A3=50, A4=50, A5=10. "access-priority" values: A1=100, A2=100, A3=50, A4=50, A5=10.
The access-priority has some limitation. A scenario like the The "access-priority" scenario has some limitations. An
previous one with five accesses but with the constraint of having "access-priority" scenario like the previous one with five accesses
traffic loadshared between A3 and A4 in case of A1 OR A2 being down but with the constraint of having traffic load-shared between A3
is not achievable. But the authors consider that the access-priority and A4 in the case where A1 OR A2 is down is not achievable. But the
covers most of the deployment use cases and the model can still be authors believe that using the "access-priority" attribute will cover
extended by augmentation to support additional use cases. most of the deployment use cases and that the model can still be
extended via augmentation to support additional use cases.
6.8. Traffic protection 6.8. Traffic Protection
The service model supports the ability to protect the traffic for a The service model supports the ability to protect the traffic for a
site. A protection provides a better availability to multihoming by, site. Such protection provides a better level of availability in
for example, using local-repair techniques in case of failures. The multihoming scenarios by, for example, using local-repair techniques
associated level of service guarantee would be based on an agreement in case of failures. The associated level of service guarantee would
between customer and service provider and is out of scope of this be based on an agreement between the customer and the SP and is out
document. of scope for this document.
Site#1 Site#2 Site#1 Site#2
CE1 ----- PE1 -- P1 P3 -- PE3 ---- CE3 CE1 ----- PE1 -- P1 P3 -- PE3 ---- CE3
| | | | | |
| | | | | |
CE2 ----- PE2 -- P2 P4 -- PE4 ---- CE4 CE2 ----- PE2 -- P2 P4 -- PE4 ---- CE4
/ /
/ /
CE5 ----+ CE5 ----+
Site#3 Site#3
In the figure above, we consider an IPVPN service with three sites In the figure above, we consider an IP VPN service with three sites,
including two dual homed sites (site#1 and #2). For dual homed including two dual-homed sites (Site#1 and Site#2). For dual-homed
sites, we consider PE1-CE1 and PE3-CE3 as primary, and sites, we consider PE1-CE1 and PE3-CE3 as primary and PE2-CE2,PE4-CE4
PE2-CE2,PE4-CE4 as backup for the example (even if protection also as backup for the example (even if protection also applies to
applies to loadsharing scenarios). load-sharing scenarios).
In order to protect Site#2 against a failure, user may set the In order to protect Site#2 against a failure, a user may set the
"traffic-protection/enabled" leaf to true for site#2. How the "traffic-protection/enabled" leaf to true for Site#2. How the
traffic protection will be implemented is out of scope of the traffic protection will be implemented is out of scope for this
document. But as an example, in such a case, if we consider traffic document. However, in such a case, we could consider traffic coming
coming from a remote site (site#1 or site#3), where the primary path from a remote site (Site#1 or Site#3), where the primary path would
is to use PE3 as egress PE. PE3 may have preprogrammed a backup use PE3 as the egress PE. PE3 may have preprogrammed a backup
forwarding entry pointing to backup path (through PE4-CE4) for all forwarding entry pointing to the backup path (through PE4-CE4) for
prefixes going through PE3-CE3 link. How the backup path is computed all prefixes going through the PE3-CE3 link. How the backup path is
is out of scope of the document. When PE3-CE3 link fails, traffic is computed is out of scope for this document. When the PE3-CE3 link
still received by PE3 but PE3 switch automatically traffic to the fails, traffic is still received by PE3, but PE3 automatically
backup entry, path will so be PE1-P1-(...)-P3-PE3-PE4-CE4 until switches traffic to the backup entry; the path will therefore be
remote PEs reconverge and use PE4 as the egress PE. PE1-P1-(...)-P3-PE3-PE4-CE4 until the remote PEs reconverge and use
PE4 as the egress PE.
6.9. Security 6.9. Security
The "security" container defines customer specific security The "security" container defines customer-specific security
parameters for the site. The security options supported in the model parameters for the site. The security options supported in the model
are limited but may be extended by augmentation. are limited but may be extended via augmentation.
6.9.1. Authentication 6.9.1. Authentication
The current model does not support any authentication parameters for The current model does not support any authentication parameters for
the site connection, but such parameters may be added in the the site connection, but such parameters may be added in the
"authentication" container through augmentation. "authentication" container through augmentation.
6.9.2. Encryption 6.9.2. Encryption
A traffic encryption can be requested on the connection. It may be Traffic encryption can be requested on the connection. It may be
performed at layer 2 or layer 3 by selecting the appropriate performed at Layer 2 or Layer 3 by selecting the appropriate
enumeration in "layer" leaf. For example, a service provider may use enumeration in the "layer" leaf. For example, an SP may use IPsec
IPSec when a customer is requesting layer 3 encryption. The when a customer requests Layer 3 encryption. The encryption profile
encryption profile can be a service provider defined profile or a can be SP defined or customer specific.
customer specific.
When a service provider profile is used and a key (e.g. a preshared When an SP profile is used and a key (e.g., a pre-shared key) is
key) is allocated by the provider to be used by a customer, the allocated by the provider to be used by a customer, the SP should
service provider should provide a way to communicate the key in a provide a way to communicate the key in a secured way to the
secured way to the customer. customer.
When a customer profile is used, the model supports only preshared When a customer profile is used, the model supports only a pre-shared
key for authentication with the preshared key provided through the key for authentication, with the pre-shared key provided through the
NETCONF or RESTCONF request. A secure channel must be used to ensure NETCONF or RESTCONF request. A secure channel must be used to ensure
that the preshared key cannot be intercepted. that the pre-shared key cannot be intercepted.
It may be necessary for the customer to change the preshared key on a For security reasons, it may be necessary for the customer to change
regular basis for security reasons. To perform a key change, the the pre-shared key on a regular basis. To perform a key change, the
user can request to the service provider by submitting a new user can ask the SP to change the pre-shared key by submitting a new
preshared key for the site configuration (as displayed below). This pre-shared key for the site configuration (as shown below). This
mechanism may not to be hitless. mechanism might not be hitless.
<site> <site>
<site-id>SITE1</site-id> <site-id>SITE1</site-id>
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<site-network-access-id>1</site-network-access-id> <site-network-access-id>1</site-network-access-id>
<security> <security>
<encryption-profile> <encryption-profile>
<preshared-key>MY_NEW_KEY</preshared-key> <preshared-key>MY_NEW_KEY</preshared-key>
</encryption-profile> </encryption-profile>
</security> </security>
</site-network-access> </site-network-access>
</site-network-accesses> </site-network-accesses>
</site> </site>
An hitless key change mechanism may be added through augmentation. A hitless key-change mechanism may be added through augmentation.
Other key management methodology may be added through augmentation. Other key-management methodologies may be added through augmentation.
A "pki" empty container has been created to help support of PKI A "pki" container, which is empty, has been created to help with
through augmentation. support of PKI through augmentation.
6.10. Management 6.10. Management
The model proposes three types of common management options: The model proposes three types of common management options:
o provider-managed: the CE router is managed only by the provider. o provider-managed: The CE router is managed only by the provider.
In this model, the responsibility boundary between SP and customer In this model, the responsibility boundary between the SP and the
is between CE and customer network. customer is between the CE and the customer network.
o customer-managed: the CE router is managed only by the customer. o customer-managed: The CE router is managed only by the customer.
In this model, the responsibility boundary between SP and customer In this model, the responsibility boundary between the SP and the
is between PE and CE. customer is between the PE and the CE.
o co-managed: the CE router is primarly managed by the provider and o co-managed: The CE router is primarily managed by the provider; in
in addition SP lets customer accessing the CE for some addition, the SP allows customers to access the CE for
configuration/monitoring purpose. In the co-managed mode the configuration/monitoring purposes. In the co-managed mode, the
responsibility boundary is the same as the provider-managed model. responsibility boundary is the same as the responsibility boundary
for the provider-managed model.
Based on the management model, different security options MAY be Based on the management model, different security options MAY be
derived. derived.
In case of "co-managed", the model proposes some options to define In the "co-managed" case, the model proposes some options to define
the management address family (IPv4 or IPv6) and the associated the management address family (IPv4 or IPv6) and the associated
management address. management address.
6.11. Routing protocols 6.11. Routing Protocols
Routing-protocol defines which routing protocol must be activated "routing-protocol" defines which routing protocol must be activated
between the provider and the customer router. The current model between the provider and the customer router. The current model
supports: bgp, rip, ospf, static, direct, vrrp. supports the following settings: bgp, rip, ospf, static, direct,
and vrrp.
The routing protocol defined applies at the provider to customer The routing protocol defined applies at the provider-to-customer
boundary. Depending on the management of the management model, it boundary. Depending on how the management model is administered, it
may apply to the PE-CE boundary or CE to customer boundary. In case may apply to the PE-CE boundary or the CE-to-customer boundary. In
of a customer managed site, the routing-protocol defined will be the case of a customer-managed site, the routing protocol defined
activated between the PE and the CE router managed by the customer. will be activated between the PE and the CE router managed by the
In case of a provider managed site, the routing-protocol defined will customer. In the case of a provider-managed site, the routing
be activated between the CE managed by the SP and the router or LAN protocol defined will be activated between the CE managed by the SP
belonging to the customer. In this case, it is expected that the PE- and the router or LAN belonging to the customer. In this case, we
CE routing will be configured based on the service provider rules as expect the PE-CE routing to be configured based on the SP's rules, as
both are managed by the same entity. both are managed by the same entity.
Rtg protocol Rtg protocol
192.0.2.0/24 ----- CE ----------------- PE1 192.0.2.0/24 ----- CE ----------------- PE1
Customer managed site Customer-managed site
Rtg protocol Rtg protocol
Customer router ----- CE ----------------- PE1 Customer router ----- CE ----------------- PE1
Provider managed site Provider-managed site
All the examples below will refer to a customer managed site case. All the examples below will refer to a scenario for a customer-
managed site.
6.11.1. Dual stack handling 6.11.1. Handling of Dual Stack
All routing protocol types support dual stack by using address-family All routing protocol types support dual stack by using the
leaf-list. "address-family" leaf-list.
Example of Dual stack using the same routing protocol: Example of dual stack using the same routing protocol:
<routing-protocols> <routing-protocols>
<routing-protocol> <routing-protocol>
<type>static</type> <type>static</type>
<static> <static>
<address-family>ipv4</address-family> <address-family>ipv4</address-family>
<address-family>ipv6</address-family> <address-family>ipv6</address-family>
</static> </static>
</routing-protocol> </routing-protocol>
</routing-protocols> </routing-protocols>
Example of Dual stack using two different routing protocols: Example of dual stack using two different routing protocols:
<routing-protocols> <routing-protocols>
<routing-protocol> <routing-protocol>
<type>rip</type> <type>rip</type>
<rip> <rip>
<address-family>ipv4</address-family> <address-family>ipv4</address-family>
</rip> </rip>
</routing-protocol> </routing-protocol>
<routing-protocol> <routing-protocol>
<type>ospf</type> <type>ospf</type>
<ospf> <ospf>
<address-family>ipv6</address-family> <address-family>ipv6</address-family>
</ospf> </ospf>
</routing-protocol> </routing-protocol>
</routing-protocols> </routing-protocols>
6.11.2. Direct LAN connection onto SP network 6.11.2. LAN Directly Connected to SP Network
Routing-protocol "direct" SHOULD be used when a customer LAN is The routing protocol type "direct" SHOULD be used when a customer LAN
directly connected to the provider network and must be advertised in is directly connected to the provider network and must be advertised
the IPVPN. in the IP VPN.
LAN attached directly to provider network: LAN attached directly to provider network:
192.0.2.0/24 ----- PE1 192.0.2.0/24 ----- PE1
In this case, the customer has a default route to the PE address. In this case, the customer has a default route to the PE address.
6.11.3. Direct LAN connection onto SP network with redundancy 6.11.3. LAN Directly Connected to SP Network with Redundancy
Routing-protocol "vrrp" SHOULD be used when a customer LAN is The routing protocol type "vrrp" SHOULD be used and advertised in the
directly connected to the provider network and must be advertised in IP VPN when
the IPVPN and LAN redundancy is expected.
o the customer LAN is directly connected to the provider network,
and
o LAN redundancy is expected.
LAN attached directly to provider network with LAN redundancy: LAN attached directly to provider network with LAN redundancy:
192.0.2.0/24 ------ PE1 192.0.2.0/24 ------ PE1
| |
+--- PE2 +--- PE2
In this case, the customer has a default route to the service In this case, the customer has a default route to the SP network.
provider network.
6.11.4. Static routing 6.11.4. Static Routing
Routing-protocol "static" MAY be used when a customer LAN is The routing protocol type "static" MAY be used when a customer LAN is
connected to the provider network through a CE router and must be connected to the provider network through a CE router and must be
advertised in the IPVPN. advertised in the IP VPN. In this case, the static routes give next
hops (nh) to the CE and to the PE. The customer has a default route
to the SP network.
Static rtg Static rtg
192.0.2.0/24 ------ CE -------------- PE 192.0.2.0/24 ------ CE -------------- PE
| | | |
| Static route 192.0.2.0/24 nh CE | Static route 192.0.2.0/24 nh CE
Static route 0.0.0.0/0 nh PE Static route 0.0.0.0/0 nh PE
In this case, the customer has a default route to the service 6.11.5. RIP Routing
provider network.
6.11.5. RIP routing
Routing-protocol "rip" MAY be used when a customer LAN is connected The routing protocol type "rip" MAY be used when a customer LAN is
to the provider network through a CE router and must be advertised in connected to the provider network through a CE router and must be
the IPVPN. For IPv4, the model assumes usage of RIP version 2. advertised in the IP VPN. For IPv4, the model assumes that RIP
version 2 is used.
In case of dual stack routing requested through this model, the In the case of dual-stack routing requested through this model, the
management system will be responsible to configure rip (including management system will be responsible for configuring RIP (including
right version number) and associated address-families on network the correct version number) and associated address families on
elements. network elements.
RIP rtg RIP rtg
192.0.2.0/24 ------ CE -------------- PE 192.0.2.0/24 ------ CE -------------- PE
6.11.6. OSPF routing 6.11.6. OSPF Routing
Routing-protocol "ospf" MAY be used when a customer LAN is connected The routing protocol type "ospf" MAY be used when a customer LAN is
to the provider network through a CE router and must be advertised in connected to the provider network through a CE router and must be
the IPVPN. advertised in the IP VPN.
It can be used to extend an existing OSPF network and interconnect It can be used to extend an existing OSPF network and interconnect
different areas. See [RFC4577] for more details. different areas. See [RFC4577] for more details.
+---------------------+ +---------------------+
| | | |
OSPF | | OSPF OSPF | | OSPF
area 1 | | area 2 area 1 | | area 2
(OSPF | | (OSPF (OSPF | | (OSPF
area 1) --- CE ---------- PE PE ----- CE --- area 2) area 1) --- CE ---------- PE PE ----- CE --- area 2)
| | | |
+---------------------+ +---------------------+
The model also proposes an option to create an OSPF sham-link between The model also proposes an option to create an OSPF sham link between
two sites sharing the same area and having a backdoor link. The two sites sharing the same area and having a backdoor link. The
sham-link is created by referencing the target site sharing the same sham link is created by referencing the target site sharing the same
OSPF area. The management system will be responsible to check if OSPF area. The management system will be responsible for checking to
there is already a shamlink configured for this VPN and area between see if there is already a sham link configured for this VPN and area
the same pair of PEs. If there is no existing shamlink, the between the same pair of PEs. If there is no existing sham link, the
management system will provision it. This shamlink MAY be reused by management system will provision one. This sham link MAY be reused
other sites. by other sites.
+------------------------+ +------------------------+
| | | |
| | | |
| PE (--shamlink--)PE | | PE (--sham link--)PE |
| | | | | | | |
+----|----------------|--+ +----|----------------|--+
| OSPF area1 | OSPF area 1 | OSPF area 1 | OSPF area 1
| | | |
CE1 CE2 CE1 CE2
| | | |
(OSPF area1) (OSPF area1) (OSPF area 1) (OSPF area 1)
| | | |
+----------------+ +----------------+
Regarding Dual stack support, user MAY specify both IPv4 and IPv6 Regarding dual-stack support, the user MAY specify both IPv4 and IPv6
address families, if both protocols should be routed through OSPF. address families, if both protocols should be routed through OSPF.
As OSPF uses separate protocol instances for IPv4 and IPv6, the As OSPF uses separate protocol instances for IPv4 and IPv6, the
management system will need to configure both ospf version 2 and management system will need to configure both OSPF version 2 and OSPF
version 3 on the PE-CE link. version 3 on the PE-CE link.
Example of OSPF routing parameters in service model. Example of OSPF routing parameters in the service model:
<routing-protocols> <routing-protocols>
<routing-protocol> <routing-protocol>
<type>ospf</type> <type>ospf</type>
<ospf> <ospf>
<area-address>0.0.0.1</area-address> <area-address>0.0.0.1</area-address>
<address-family>ipv4</address-family> <address-family>ipv4</address-family>
<address-family>ipv6</address-family> <address-family>ipv6</address-family>
</ospf> </ospf>
</routing-protocol> </routing-protocol>
</routing-protocols> </routing-protocols>
Example of PE configuration done by management system:
Example of PE configuration done by the management system:
router ospf 10 router ospf 10
area 0.0.0.1 area 0.0.0.1
interface Ethernet0/0 interface Ethernet0/0
! !
router ospfv3 10 router ospfv3 10
area 0.0.0.1 area 0.0.0.1
interface Ethernet0/0 interface Ethernet0/0
! !
6.11.7. BGP routing 6.11.7. BGP Routing
Routing-protocol "bgp" MAY be used when a customer LAN is connected The routing protocol type "bgp" MAY be used when a customer LAN is
to the provider network through a CE router and must be advertised in connected to the provider network through a CE router and must be
the IPVPN. advertised in the IP VPN.
BGP rtg BGP rtg
192.0.2.0/24 ------ CE -------------- PE 192.0.2.0/24 ------ CE -------------- PE
The session addressing will be derived from connection parameters as The session addressing will be derived from connection parameters as
well as internal knowledge of SP. well as the SP's knowledge of the addressing plan that is in use.
In case of dual stack access, user MAY request BGP routing for both In the case of dual-stack access, the user MAY request BGP routing
IPv4 and IPv6 by specifying both address-families. It will be up to for both IPv4 and IPv6 by specifying both address families. It will
SP and management system to determine how to decline the be up to the SP and management system to determine how to decline the
configuration (two BGP sessions, single, multisession ...). configuration (two BGP sessions, single, multi-session, etc.).
The service configuration below activates BGP on PE-CE link for both The service configuration below activates BGP on the PE-CE link for
IPv4 and IPv6. both IPv4 and IPv6.
BGP activation requires SP to know the address of the customer peer. BGP activation requires the SP to know the address of the customer
"static-address" allocation type for the IP connection MUST be used. peer. The "static-address" allocation type for the IP connection
MUST be used.
<routing-protocols> <routing-protocols>
<routing-protocol> <routing-protocol>
<type>bgp</type> <type>bgp</type>
<bgp> <bgp>
<autonomous-system>65000</autonomous-system> <autonomous-system>65000</autonomous-system>
<address-family>ipv4</address-family> <address-family>ipv4</address-family>
<address-family>ipv6</address-family> <address-family>ipv6</address-family>
<bgp> </bgp>
</routing-protocol> </routing-protocol>
</routing-protocols> </routing-protocols>
This service configuration can be derived by management system into Depending on the SP flavor, a management system can divide this
multiple flavors depending on SP flavor. service configuration into different flavors, as shown by the
following examples.
Example #1 of PE configuration done by management system Example of PE configuration done by the management system
(single session IPv4 transport session): (single IPv4 transport session):
router bgp 100 router bgp 100
neighbor 203.0.113.2 remote-as 65000 neighbor 203.0.113.2 remote-as 65000
address-family ipv4 vrf Cust1 address-family ipv4 vrf Cust1
neighbor 203.0.113.2 activate neighbor 203.0.113.2 activate
address-family ipv6 vrf Cust1 address-family ipv6 vrf Cust1
neighbor 203.0.113.2 activate neighbor 203.0.113.2 activate
neighbor 203.0.113.2 route-map SET-NH-IPV6 out neighbor 203.0.113.2 route-map SET-NH-IPV6 out
Example #2 of PE configuration done Example of PE configuration done by the management system
by management system (two sessions): (two sessions):
router bgp 100 router bgp 100
neighbor 203.0.113.2 remote-as 65000 neighbor 203.0.113.2 remote-as 65000
neighbor 2001::2 remote-as 65000 neighbor 2001::2 remote-as 65000
address-family ipv4 vrf Cust1 address-family ipv4 vrf Cust1
neighbor 203.0.113.2 activate neighbor 203.0.113.2 activate
address-family ipv6 vrf Cust1 address-family ipv6 vrf Cust1
neighbor 2001::2 activate neighbor 2001::2 activate
Example #3 of PE configuration done Example of PE configuration done by the management system
by management system (multisession): (multi-session):
router bgp 100 router bgp 100
neighbor 203.0.113.2 remote-as 65000 neighbor 203.0.113.2 remote-as 65000
neighbor 203.0.113.2 multisession per-af neighbor 203.0.113.2 multisession per-af
address-family ipv4 vrf Cust1 address-family ipv4 vrf Cust1
neighbor 203.0.113.2 activate neighbor 203.0.113.2 activate
address-family ipv6 vrf Cust1 address-family ipv6 vrf Cust1
neighbor 203.0.113.2 activate neighbor 203.0.113.2 activate
neighbor 203.0.113.2 route-map SET-NH-IPV6 out neighbor 203.0.113.2 route-map SET-NH-IPV6 out
6.12. Service 6.12. Service
The service defines service parameters associated with the site. The service defines service parameters associated with the site.
6.12.1. Bandwidth 6.12.1. Bandwidth
The service bandwidth refers to the bandwidth requirement between PE The service bandwidth refers to the bandwidth requirement between the
and CE (WAN link bandwidth). The requested bandwidth is expressed as PE and the CE (WAN link bandwidth). The requested bandwidth is
svc-input-bandwidth and svc-output-bandwidth in bits per seconds. expressed as "svc-input-bandwidth" and "svc-output-bandwidth" in bits
Input/output direction is using customer site as reference: input per second. The input/output direction uses the customer site as a
bandwidth means download bandwidth for the site, and output bandwidth reference: "input bandwidth" means download bandwidth for the site,
means upload bandwidth for the site. and "output bandwidth" means upload bandwidth for the site.
The service bandwidth is only configurable at site-network-access The service bandwidth is only configurable at the site-network-access
level. level.
Using a different input and output bandwidth will allow service Using a different input and output bandwidth will allow the SP to
provider to know if customer allows for asymmetric bandwidth access determine if the customer allows for asymmetric bandwidth access,
like ADSL. It can also be used to set rate-limit in a different way such as ADSL. It can also be used to set rate-limiting in a
upload and download on a symmetric bandwidth access. different way for uploading and downloading on a symmetric bandwidth
access.
The bandwidth is a service bandwidth: expressed primarily as IP The bandwidth is a service bandwidth expressed primarily as IP
bandwidth but if the customer enables MPLS for carrier's carrier, bandwidth, but if the customer enables MPLS for Carriers' Carriers
this becomes MPLS bandwidth. (CsC), this becomes MPLS bandwidth.
6.12.2. QoS 6.12.2. QoS
The model proposes to define QoS parameters in an abstracted way: The model proposes to define QoS parameters in an abstracted way:
o qos-classification-policy: define a set of ordered rules to o qos-classification-policy: policy that defines a set of ordered
classify customer traffic. rules to classify customer traffic.
o qos-profile: QoS scheduling profile to be applied. o qos-profile: QoS scheduling profile to be applied.
6.12.2.1. QoS classification 6.12.2.1. QoS Classification
QoS classification rules are handled by qos-classification-policy. QoS classification rules are handled by the
The qos-classification-policy is an ordered list of rules that match "qos-classification-policy" container. The
a flow or application and set the appropriate target class of service "qos-classification-policy" container is an ordered list of rules
(target-class-id). The user can define the match using an that match a flow or application and set the appropriate target class
application reference or a more specific flow definition (based layer of service (target-class-id). The user can define the match using an
3 source and destination address, layer 4 ports, layer 4 protocol). application reference or a flow definition that is more specific
When a flow definition is used, the user can use a target-sites leaf- (e.g., based on Layer 3 source and destination addresses, Layer 4
list to identify the destination of a flow rather than using ports, and Layer 4 protocol). When a flow definition is used, the
destination IP addresses. In such a case, an association between the user can employ a "target-sites" leaf-list to identify the
site abstraction and the IP addresses used by this site must be done destination of a flow rather than using destination IP addresses. In
dynamically. How this association is done is out of scope of this such a case, an association between the site abstraction and the IP
document and an implementation may not support this criterion and addresses used by this site must be done dynamically. How this
should advertise a deviation in this case. A rule that does not have association is done is out of scope for this document; an
a match statement is considered as a match-all rule. A service implementation might not support this criterion and should advertise
provider may implement a default terminal classification rule if the a deviation in this case. A rule that does not have a match
customer does not provide it. It will be up to the service provider statement is considered a match-all rule. An SP may implement a
to determine its default target class. The current model defines default terminal classification rule if the customer does not provide
some applications but new application identities may be added through it. It will be up to the SP to determine its default target class.
augmentation. The exact meaning of each application identity is up The current model defines some applications, but new application
to the service provider, so it will be necessary for the service identities may be added through augmentation. The exact meaning of
provider to advise customer on usage of application matching. each application identity is up to the SP, so it will be necessary
for the SP to advise the customer on the usage of application
matching.
Where the classification is done depends on the SP implementation of Where the classification is done depends on the SP's implementation
the service, but classification concerns the flow coming from the of the service, but classification concerns the flow coming from the
customer site and entering the network. customer site and entering the network.
Provider network Provider network
+-----------------------+ +-----------------------+
192.0.2.0/24 192.0.2.0/24
198.51.100.0/24 ---- CE --------- PE 198.51.100.0/24 ---- CE --------- PE
Traffic flow Traffic flow
----------> ---------->
In the figure above, the management system should implement the In the figure above, the management system should implement the
classification rule: classification rule:
o in the ingress direction on the PE interface, if the CE is o in the ingress direction on the PE interface, if the CE is
customer managed. customer managed.
o in the ingress direction on the CE interface connected to customer o in the ingress direction on the CE interface connected to the
LAN, if the CE is provider managed. customer LAN, if the CE is provider managed.
The figure below describes a sample service description of qos- The figure below describes a sample service description of QoS
classification for a site : classification for a site:
<service> <service>
<qos> <qos>
<qos-classification-policy> <qos-classification-policy>
<rule> <rule>
<id>1</id> <id>1</id>
<match-flow> <match-flow>
<ipv4-src-prefix>192.0.2.0/24</ipv4-src-prefix> <ipv4-src-prefix>192.0.2.0/24</ipv4-src-prefix>
<ipv4-dst-prefix>203.0.113.1/32</ipv4-dst-prefix> <ipv4-dst-prefix>203.0.113.1/32</ipv4-dst-prefix>
<l4-dst-port>80</l4-dst-port> <l4-dst-port>80</l4-dst-port>
<l4-protocol>tcp</l4-protocol> <l4-protocol>tcp</l4-protocol>
</match-flow> </match-flow>
<target-class-id>DATA2</target-class-id> <target-class-id>DATA2</target-class-id>
</rule> </rule>
<rule> <rule>
<id>2</id> <id>2</id>
<match-flow> <match-flow>
<ipv4-src-prefix>192.0.2.0/24</ipv4-src-prefix> <ipv4-src-prefix>192.0.2.0/24</ipv4-src-prefix>
<ipv4-dst-prefix>203.0.113.1/32</ipv4-dst-prefix> <ipv4-dst-prefix>203.0.113.1/32</ipv4-dst-prefix>
<l4-dst-port>21</l4-dst-port> <l4-dst-port>21</l4-dst-port>
<l4-protocol>tcp</l4-protocol> <l4-protocol>tcp</l4-protocol>
</match-flow> </match-flow>
<target-class-id>DATA2</target-class-id> <target-class-id>DATA2</target-class-id>
</rule> </rule>
<rule> <rule>
<id>3</id> <id>3</id>
<match-application>p2p</match-application> <match-application>p2p</match-application>
<target-class-id>DATA3</target-class-id> <target-class-id>DATA3</target-class-id>
</rule> </rule>
<rule> <rule>
<id>4</id> <id>4</id>
<target-class-id>DATA1</target-class-id> <target-class-id>DATA1</target-class-id>
</rule> </rule>
</qos-classification-policy> </qos-classification-policy>
</qos> </qos>
</service> </service>
In the example above: In the example above:
o HTTP traffic from 192.0.2.0/24 LAN destinated to 203.0.113.1/32 o HTTP traffic from the 192.0.2.0/24 LAN destined for 203.0.113.1/32
will be classified in DATA2. will be classified in DATA2.
o FTP traffic from 192.0.2.0/24 LAN destinated to 203.0.113.1/32 o FTP traffic from the 192.0.2.0/24 LAN destined for 203.0.113.1/32
will be classified in DATA2. will be classified in DATA2.
o Peer to peer traffic will be classified in DATA3. o Peer-to-peer traffic will be classified in DATA3.
o All other traffic will be classified in DATA1. o All other traffic will be classified in DATA1.
The order of rules is really important. The management system The order of rules is very important. The management system
responsible for translating those rules in network element responsible for translating those rules in network element
configuration MUST keep the same processing order in network element configuration MUST keep the same processing order in network element
configuration. The order of rule is defined by the "id" leaf. The configuration. The order of rules is defined by the "id" leaf. The
lowest "id" MUST be processed first. lowest "id" MUST be processed first.
6.12.2.2. QoS profile 6.12.2.2. QoS Profile
User can choose between standard profile provided by the operator or The user can choose either a standard profile provided by the
custom profile. The qos-profile defines the traffic scheduling operator or a custom profile. The "qos-profile" container defines
policy to be used by the service provider. the traffic-scheduling policy to be used by the SP.
Provider network Provider network
+-----------------------+ +-----------------------+
192.0.2.0/24 192.0.2.0/24
198.51.100.0/24 ---- CE --------- PE 198.51.100.0/24 ---- CE --------- PE
\ / \ /
qos-profile qos-profile
In case of provider managed or co-managed connection, the provider In the case of a provider-managed or co-managed connection, the
should ensure scheduling according to the requested policy in both provider should ensure scheduling according to the requested policy
traffic directions (SP to customer and customer to SP). As example in both traffic directions (SP to customer and customer to SP). As
of implementation, a device scheduling policy may be implemented both an example, a device-scheduling policy may be implemented on both the
at PE and CE side on the WAN link. In case of customer managed PE side and the CE side of the WAN link. In the case of a customer-
connection, the provider is only responsible to ensure scheduling managed connection, the provider is only responsible for ensuring
from SP network to the customer site. As example of implementation, scheduling from the SP network to the customer site. As an example,
a device scheduling policy may be implemented only at PE side on the a device-scheduling policy may be implemented only on the PE side of
WAN link towards the customer. the WAN link towards the customer.
A custom qos-profile is defined as a list of class of services and A custom QoS profile is defined as a list of classes of services and
associated properties. The properties are: associated properties. The properties are:
o rate-limit: used to rate-limit the class of service. The value is o rate-limit: used to rate-limit the class of service. The value is
expressed as a percentage of the global service bandwidth. When expressed as a percentage of the global service bandwidth. When
the qos-profile is implemented at CE side the svc-output-bandwidth the "qos-profile" container is implemented on the CE side,
is taken into account as reference. When it is implemented at PE "svc-output-bandwidth" is taken into account as a reference. When
side, the svc-input-bandwidth is used. it is implemented on the PE side, "svc-input-bandwidth" is used.
o latency: used to define the latency constraint of the class. The o latency: used to define the latency constraint of the class. The
latency constraint can be expressed as the lowest possible latency latency constraint can be expressed as the lowest possible latency
or a latency boundary expressed in milliseconds. How this latency or a latency boundary expressed in milliseconds. How this latency
constraint will be fulfilled is up to the service provider constraint will be fulfilled is up to the SP's implementation of
implementation: a strict priority queueing may be used on the the service: a strict priority queuing may be used on the access
access and in the core network, and/or a low latency routing may and in the core network, and/or a low-latency routing
be created for this traffic class. configuration may be created for this traffic class.
o jitter: used to define the jitter constraint of the class. The o jitter: used to define the jitter constraint of the class. The
jitter constraint can be expressed as the lowest possible jitter jitter constraint can be expressed as the lowest possible jitter
or a jitter boundary expressed in microseconds. How this jitter or a jitter boundary expressed in microseconds. How this jitter
constraint will be fulfilled is up to the service provider constraint will be fulfilled is up to the SP's implementation of
implementation: a strict priority queueing may be used on the the service: a strict priority queuing may be used on the access
access and in the core network, and/or a jitter-aware routing may and in the core network, and/or a jitter-aware routing
be created for this traffic class. configuration may be created for this traffic class.
o bandwidth: used to define a guaranteed amount of bandwidth for the o bandwidth: used to define a guaranteed amount of bandwidth for the
class of service. It is expressed as a percentage. The class of service. It is expressed as a percentage. The
guaranteed-bw-percent uses available bandwidth as a reference. "guaranteed-bw-percent" parameter uses available bandwidth as a
When the qos-profile is implemented at CE side the svc-output- reference. When the "qos-profile" container is implemented on the
bandwidth is taken into account as reference. When it is CE side, "svc-output-bandwidth" is taken into account as a
implemented at PE side, the svc-input-bandwidth is used. By reference. When it is implemented on the PE side,
default, the bandwidth reservation is only guaranteed at the "svc-input-bandwidth" is used. By default, the bandwidth
access level. The user can use the "end-to-end" leaf to request reservation is only guaranteed at the access level. The user can
an end-to-end bandwidth reservation including the MPLS transport use the "end-to-end" leaf to request an end-to-end bandwidth
network. reservation, including across the MPLS transport network. (In
other words, the SP will activate something in the MPLS core to
ensure that the bandwidth request from the customer will be
fulfilled by the MPLS core as well.) How this is done (e.g., RSVP
reservation, controller reservation) is out of scope for this
document.
Some constraints may not be offered by a service provider, in this Some constraints may not be offered by an SP; in this case, a
case a deviation should be advertised. In addition, due to the deviation should be advertised. In addition, due to network
network conditions, some constraints may not be completely fulfilled conditions, some constraints may not be completely fulfilled by the
by the service provider, in this case, the service provider should SP; in this case, the SP should advise the customer about the
advise the customer about the limitations. How this communication is limitations. How this communication is done is out of scope for this
done is out of scope of this document. document.
Example of service configuration using a standard qos profile: Example of service configuration using a standard QoS profile:
<site-network-access> <site-network-access>
<site-network-access-id>1245HRTFGJGJ154654</site-network-access-id> <site-network-access-id>1245HRTFGJGJ154654</site-network-access-id>
<service> <service>
<svc-input-bandwidth>100000000</svc-input-bandwidth> <svc-input-bandwidth>100000000</svc-input-bandwidth>
<svc-output-bandwidth>100000000</svc-output-bandwidth> <svc-output-bandwidth>100000000</svc-output-bandwidth>
<qos> <qos>
<qos-profile> <qos-profile>
<profile>PLATINUM</profile> <profile>PLATINUM</profile>
</qos-profile> </qos-profile>
</qos> </qos>
</service> </service>
</site-network-access> </site-network-access>
<site-network-access> <site-network-access>
<site-network-access-id>555555AAAA2344</site-network-access-id> <site-network-access-id>555555AAAA2344</site-network-access-id>
<service> <service>
<svc-input-bandwidth>2000000</svc-input-bandwidth> <svc-input-bandwidth>2000000</svc-input-bandwidth>
<svc-output-bandwidth>2000000</svc-output-bandwidth> <svc-output-bandwidth>2000000</svc-output-bandwidth>
<qos> <qos>
<qos-profile> <qos-profile>
<profile>GOLD</profile> <profile>GOLD</profile>
</qos-profile> </qos-profile>
</qos> </qos>
</service> </service>
</site-network-access> </site-network-access>
Example of service configuration using a custom qos profile: Example of service configuration using a custom QoS profile:
<site-network-access> <site-network-access>
<site-network-access-id>Site1</site-network-access-id> <site-network-access-id>Site1</site-network-access-id>
<service> <service>
<svc-input-bandwidth>100000000</svc-input-bandwidth> <svc-input-bandwidth>100000000</svc-input-bandwidth>
<svc-output-bandwidth>100000000</svc-output-bandwidth> <svc-output-bandwidth>100000000</svc-output-bandwidth>
<qos> <qos>
<qos-profile> <qos-profile>
<classes> <classes>
<class> <class>
<class-id>REAL_TIME</class-id> <class-id>REAL_TIME</class-id>
<rate-limit>10</rate-limit> <rate-limit>10</rate-limit>
<latency> <latency>
<use-lowest-latency/> <use-lowest-latency/>
</latency> </latency>
</class> </class>
<class> <class>
<class-id>DATA1</class-id> <class-id>DATA1</class-id>
<latency> <latency>
<latency-boundary>70</latency-boundary> <latency-boundary>70</latency-boundary>
</latency> </latency>
<bandwidth> <bandwidth>
<guaranteed-bw-percent> <guaranteed-bw-percent>80</guaranteed-bw-percent>
80 </bandwidth>
</guaranteed-bw-percent> </class>
</bandwidth> <class>
</class> <class-id>DATA2</class-id>
<class> <latency>
<class-id>DATA2</class-id> <latency-boundary>200</latency-boundary>
<latency> </latency>
<latency-boundary>200</latency-boundary> <bandwidth>
</latency> <guaranteed-bw-percent>5</guaranteed-bw-percent>
<bandwidth> <end-to-end/>
<guaranteed-bw-percent> </bandwidth>
5 </class>
</guaranteed-bw-percent> </classes>
<end-to-end/> </qos-profile>
</bandwidth> </qos>
</class> </service>
</classes>
</qos-profile>
</qos>
</service>
</site-network-access> </site-network-access>
The custom qos-profile for site1 defines a REAL_TIME class with a The custom QoS profile for Site1 defines a REAL_TIME class with a
lowest possible latency constraint. It defines also two data classes latency constraint expressed as the lowest possible latency. It also
DATA1 and DATA2. The two classes express a latency boundary defines two data classes -- DATA1 and DATA2. The two classes express
constraint as well as a bandwidth reservation. As the REAL_TIME a latency boundary constraint as well as a bandwidth reservation, as
class is rate-limited to 10% of the service bandwidth (10% of 100Mbps the REAL_TIME class is rate-limited to 10% of the service bandwidth
= 10Mbps). In case of congestion, the REAL_TIME traffic can go up to (10% of 100 Mbps = 10 Mbps). In cases where congestion occurs, the
10Mbps (let's assume that only 5Mbps are consumed). DATA1 and DATA2 REAL_TIME traffic can go up to 10 Mbps (let's assume that only 5 Mbps
will share the remaining bandwidth (95Mbps) according to their are consumed). DATA1 and DATA2 will share the remaining bandwidth
percentage. So the DATA1 class will be served with at least 76Mbps (95 Mbps) according to their percentage. So, the DATA1 class will be
of bandwidth while the DATA2 class will be served with at least served with at least 76 Mbps of bandwidth, while the DATA2 class will
4.75Mbps. The latency boundary information of the data class may be served with at least 4.75 Mbps. The latency boundary information
help the service provider to define a specific buffer tuning or a of the data class may help the SP define a specific buffer tuning or
specific routing within the network. The maximum percentage to be a specific routing within the network. The maximum percentage to be
used is not limited by this model but MUST be limited by the used is not limited by this model but MUST be limited by the
management system according to the policies authorized by the service management system according to the policies authorized by the SP.
provider.
6.12.3. Multicast 6.12.3. Multicast
The multicast section defines the type of site in the customer The "multicast" container defines the type of site in the customer
multicast service topology: source, receiver, or both. These multicast service topology: source, receiver, or both. These
parameters will help management system to optimize the multicast parameters will help the management system optimize the multicast
service. User can also define the type of multicast relation with service. Users can also define the type of multicast relationship
the customer: router (requires a protocol like PIM), host (IGMP or with the customer: router (requires a protocol such as PIM), host
MLD), or both. Address family (IPv4 or IPv6 or both) can also be (IGMP or MLD), or both. An address family (IPv4, IPv6, or both) can
defined. also be defined.
6.13. Enhanced VPN features 6.13. Enhanced VPN Features
6.13.1. Carrier's Carrier 6.13.1. Carriers' Carriers
In case of Carrier's Carrier ([RFC4364]), a customer may want to In the case of CsC [RFC4364], a customer may want to build an MPLS
build MPLS service using an IPVPN to carry its traffic. service using an IP VPN to carry its traffic.
LAN customer1 LAN customer1
| |
| |
CE1 CE1
| |
| ------------- | -------------
(vrf_cust1) (vrf_cust1)
CE1_ISP1 CE1_ISP1
| ISP1 PoP | ISP1 POP
| MPLS link | MPLS link
| ------------- | -------------
| |
(vrf ISP1) (vrf ISP1)
PE1 PE1
(...) Provider backbone (...) Provider backbone
PE2 PE2
(vrf ISP1) (vrf ISP1)
| |
| ------------ | ------------
| |
| MPLS link | MPLS link
| ISP1 PoP | ISP1 POP
CE2_ISP1 CE2_ISP1
(vrf_cust1) (vrf_cust1)
|------------- | ------------
| |
CE2 CE2
| |
Lan customer1 LAN customer1
In the figure above, ISP1 resells IPVPN service but has no core In the figure above, ISP1 resells an IP VPN service but has no core
network infrastructure between its PoPs. ISP1 uses an IPVPN as core network infrastructure between its POPs. ISP1 uses an IP VPN as the
network infrastructure (belonging to another provider) between its core network infrastructure (belonging to another provider) between
PoPs. its POPs.
In order to support CsC, the VPN service must be declared MPLS In order to support CsC, the VPN service must indicate MPLS support
support using the "carrierscarrier" leaf set to true in vpn-service. by setting the "carrierscarrier" leaf to true in the "vpn-service"
The link between CE1_ISP1/PE1 and CE2_ISP1/PE2 must also run an MPLS list. The link between CE1_ISP1/PE1 and CE2_ISP1/PE2 must also run
signalling protocol. This configuration is done at the site level. an MPLS signalling protocol. This configuration is done at the site
level.
In the proposed model, LDP or BGP can be used as the MPLS signalling In the proposed model, LDP or BGP can be used as the MPLS signalling
protocol. In case of LDP, an IGP routing protocol MUST also be protocol. In the case of LDP, an IGP routing protocol MUST also be
activated. In case of BGP signalling, BGP MUST also be configured as activated. In the case of BGP signalling, BGP MUST also be
routing-protocol. configured as the routing protocol.
In case Carrier's Carrier is enabled, the requested svc-mtu will If CsC is enabled, the requested "svc-mtu" leaf will refer to the
refer to the MPLS MTU and not to the IP MTU. MPLS MTU and not to the IP MTU.
6.14. External ID references 6.14. External ID References
The service model sometimes refers to external information through The service model sometimes refers to external information through
identifiers. As an example, to order a cloud-access to a particular identifiers. As an example, to order a cloud-access to a particular
Cloud Service Provider (CSP), the model uses an identifier to refer cloud service provider (CSP), the model uses an identifier to refer
to the targeted CSP. In case, a customer is using directly this to the targeted CSP. If a customer is directly using this service
service model as an API (through REST or NETCONF for example) to model as an API (through REST or NETCONF, for example) to order a
order a particular service, the service provider should provide a particular service, the SP should provide a list of authorized
list of authorized identifiers. In case of cloud-access, the service identifiers. In the case of cloud-access, the SP will provide the
provider will provide the identifiers associated of each available associated identifiers for each available CSP. The same applies to
CSP. The same applies to other identifiers like std-qos-profile, oam other identifiers, such as std-qos-profile, OAM profile-name, and
profile-name, provider-profile for encryption ... provider-profile for encryption.
How an SP provides those identifiers meaning to the customer is out How an SP provides the meanings of those identifiers to the customer
of scope of this document. is out of scope for this document.
6.15. Defining NNIs 6.15. Defining NNIs
An autonomous system is a single network or group of networks that is An autonomous system (AS) is a single network or group of networks
controlled by a common system administration group and that uses a that is controlled by a common system administration group and that
single, clearly defined routing protocol. In some cases, VPNs need uses a single, clearly defined routing protocol. In some cases, VPNs
to span across different autonomous systems in different geographic need to span different ASes in different geographic areas or span
areas or across different service providers. The connection between different SPs. The connection between ASes is established by the SPs
autonomous systems is established by the Service Providers and is and is seamless to the customer. Examples include
seamless to the customer.
Some examples are: Partnership between service providers (carrier, o a partnership between SPs (e.g., carrier, cloud) to extend their
cloud ...) to extend their VPN service seamlessly, or internal VPN service seamlessly.
administrative boundary within a single service provider (Backhaul vs
Core vs Datacenter ...).
NNIs (Network to Network Interfaces) have to be defined to extend the o an internal administrative boundary within a single SP (e.g.,
VPNs across multiple autonomous systems. backhaul versus core versus data center).
[RFC4364] defines multiple flavors of VPN NNI implementations. Each NNIs (network-to-network interfaces) have to be defined to extend the
implementation has different pros/cons that are outside the scope of VPNs across multiple ASes.
this document. As an example: In an Inter-AS Option A, ASBR peers
are connected by multiple interfaces with at least one interface
which VPN spans the two autonomous systems. These ASBRs associate
each interface with a VPN routing and forwarding (VRF) instance and a
Border Gateway Protocol (BGP) session to signal unlabeled IP
prefixes. As a result, traffic between the back-to-back VRFs is IP.
In this scenario, the VPNs are isolated from each other, and because [RFC4364] defines multiple flavors of VPN NNI implementations. Each
the traffic is IP, QoS mechanisms that operate on IP traffic can be implementation has pros and cons; this topic is outside the scope of
applied to achieve customer Service Level Agreements (SLAs). this document. For example, in an Inter-AS option A, autonomous
system border router (ASBR) peers are connected by multiple
interfaces with at least one of those interfaces spanning the two
ASes while being present in the same VPN. In order for these ASBRs
to signal unlabeled IP prefixes, they associate each interface with a
VPN routing and forwarding (VRF) instance and a Border Gateway
Protocol (BGP) session. As a result, traffic between the
back-to-back VRFs is IP. In this scenario, the VPNs are isolated
from each other, and because the traffic is IP, QoS mechanisms that
operate on IP traffic can be applied to achieve customer service
level agreements (SLAs).
-------- -------------- ----- -------- -------------- -----------
/ \ / \ / \ / \ / \ / \
| Cloud | | | | | | Cloud | | | | |
| Provider | ----NNI---- | | ---NNI---| DC | | Provider |-----NNI-----| |----NNI---| Data Center |
| #1 | | | | | | #1 | | | | |
\ / | | \ / \ / | | \ /
-------- | | ---- -------- | | -----------
| | | |
-------- | My network | ----------- -------- | My network | -----------
/ \ | | / \ / \ | | / \
| Cloud | | | | | | Cloud | | | | |
| Provider | ----NNI---- | |---NNI---| L3VPN | | Provider |-----NNI-----| |---NNI---| L3VPN |
| #2 | | | | Partner | | #2 | | | | Partner |
\ / | | | | \ / | | | |
-------- | | | | -------- | | | |
\ / | | \ / | |
-------------- \ / -------------- \ /
| ---------- | -----------
| |
NNI NNI
| |
| |
------------------- -------------------
/ \ / \
| | | |
| | | |
| | | |
| L3VPN partner | | L3VPN Partner |
| | | |
\ / \ /
------------------ -------------------
The figure above describes a service provider network "My network" The figure above describes an SP network called "My network" that has
that has several NNIs. This network uses NNI to: several NNIs. This network uses NNIs to:
o increase its footprint by relying on L3VPN partners. o increase its footprint by relying on L3VPN partners.
o connect its own datacenter services to the customer IPVPN. o connect its own data center services to the customer IP VPN.
o enable customer to access to its private resources located in o enable the customer to access its private resources located in a
private cloud owned by some cloud service providers. private cloud owned by some CSPs.
6.15.1. Defining NNI with option A flavor 6.15.1. Defining an NNI with the Option A Flavor
AS A AS B AS A AS B
--------------------- -------------------- ------------------- -------------------
/ \ / \ / \ / \
| | | | | | | |
| ++++++++ InterAS link ++++++++ | | ++++++++ Inter-AS link ++++++++ |
| + +_____________ + + | | + +_______________+ + |
| + (VRF1)--(VPN1)----(VRF1) + | | + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + | | + ASBR + + ASBR + |
| + (VRF2)--(VPN2)----(VRF2) + | | + (VRF2)---(VPN2)----(VRF2) + |
| + +______________+ + | | + +_______________+ + |
| ++++++++ ++++++++ | | ++++++++ ++++++++ |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| ++++++++ InterAS link ++++++++ | | ++++++++ Inter-AS link ++++++++ |
| + +_____________ + + | | + +_______________+ + |
| + (VRF1)--(VPN1)----(VRF1) + | | + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + | | + ASBR + + ASBR + |
| + (VRF2)--(VPN2)----(VRF2) + | | + (VRF2)---(VPN2)----(VRF2) + |
| + +______________+ + | | + +_______________+ + |
| ++++++++ ++++++++ | | ++++++++ ++++++++ |
| | | | | | | |
| | | | | | | |
\ / \ / \ / \ /
-------------------- ------------------- ------------------- -------------------
In option A, the two ASes are connected between each other with In option A, the two ASes are connected to each other with physical
physical links on Autonomous System Border Routers (ASBR). There may links on ASBRs. For resiliency purposes, there may be multiple
be multiple physical connections between the ASes for a resiliency physical connections between the ASes. A VPN connection -- physical
purpose. A VPN connection, physical or logical (on top of physical), or logical (on top of physical) -- is created for each VPN that needs
is created for each VPN that needs to cross the AS boundary. A back- to cross the AS boundary, thus providing a back-to-back VRF model.
to-back VRF model is so created.
This VPN connection can be seen as a site from a service model From a service model's perspective, this VPN connection can be seen
perspective. Let's say that AS B wants to extend some VPN connection as a site. Let's say that AS B wants to extend some VPN connections
for VPN C on AS A. Administrator of AS B can use this service model for VPN C on AS A. The administrator of AS B can use this service
to order a site on AS A. All connection scenarios could be realized model to order a site on AS A. All connection scenarios could be
using the current model features. As an example, the figure above, realized using the features of the current model. As an example, the
where two physical connections are involved with logical connections figure above shows two physical connections that have logical
per VPN on top, could be seen as a dualhomed subVPN scenario. And connections per VPN overlaid on them. This could be seen as a
for example, administrator from AS B will be able to choose the dual-homed subVPN scenario. Also, the administrator of AS B will be
appropriate routing protocol (e.g. ebgp) to dynamically exchange able to choose the appropriate routing protocol (e.g., E-BGP) to
routes between ASes. dynamically exchange routes between ASes.
This document assumes that option A NNI flavor SHOULD reuse the This document assumes that the option A NNI flavor SHOULD reuse the
existing VPN site modeling. existing VPN site modeling.
Example: a customer wants from its cloud service provider A to attach Example: a customer wants its CSP A to attach its virtual network N
its virtual network N to an existing IPVPN (VPN1) he has from a L3VPN to an existing IP VPN (VPN1) that he has from L3VPN SP B.
service provider B.
CSP A L3VPN SP B CSP A L3VPN SP B
----------------- -------------------- ----------------- -------------------
/ \ / \ / \ / \
| | | | | | | | | |
| VM --| ++++++++ NNI ++++++++ |---- VPN1 | VM --| ++++++++ NNI ++++++++ |--- VPN1
| | + +_________+ + | Site#1 | | + +_________+ + | Site#1
| |--------(VRF1)---(VPN1)--(VRF1)+ | | |--------(VRF1)---(VPN1)--(VRF1)+ |
| | + ASBR + + ASBR + | | | + ASBR + + ASBR + |
| | + +_________+ + | | | + +_________+ + |
| | ++++++++ ++++++++ | | | ++++++++ ++++++++ |
| VM --| | | |---- VPN1 | VM --| | | |--- VPN1
| |Virtual | | | Site#2 | |Virtual | | | Site#2
| |Network | | | | |Network | | |
| VM --| | | |---- VPN1 | VM --| | | |--- VPN1
| | | | | Site#3 | | | | | Site#3
\ / \ / \ / \ /
---------------- ------------------- ----------------- -------------------
| |
| |
VPN1 VPN1
Site#4 Site#4
The cloud service provider or the customer may use our L3VPN service To create the VPN connectivity, the CSP or the customer may use the
model exposed by service provider B to create the VPN connectivity. L3VPN service model that SP B exposes. We could consider that, as
We could consider that, as the NNI is shared, the physical connection the NNI is shared, the physical connection (bearer) between CSP A and
(bearer) between CSP A and SP B already exists. CSP A may request SP B already exists. CSP A may request through a service model the
through a service model a new site creation with a single site- creation of a new site with a single site-network-access
network-access (single homing used in the diagram). As placement (single-homing is used in the figure). As a placement constraint,
constraint, CSP A may use the existing bearer reference it has from CSP A may use the existing bearer reference it has from SP A to force
SP A to force the placement of the VPN NNI on the existing link. The the placement of the VPN NNI on the existing link. The XML below
XML below describes what could be the configuration request to SP B: illustrates a possible configuration request to SP B:
<site> <site>
<site-id>CSP_A_attachment</site-id> <site-id>CSP_A_attachment</site-id>
<location> <location>
<city>NY</city> <city>NY</city>
<country-code>US</country-code> <country-code>US</country-code>
</location> </location>
<site-vpn-flavor>site-vpn-flavor-nni</site-vpn-flavor> <site-vpn-flavor>site-vpn-flavor-nni</site-vpn-flavor>
<routing-protocols> <routing-protocols>
<routing-protocol> <routing-protocol>
skipping to change at page 85, line 51 skipping to change at page 85, line 51
<vpn-id>VPN1</vpn-id> <vpn-id>VPN1</vpn-id>
<site-role>any-to-any-role</site-role> <site-role>any-to-any-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses> </site-network-accesses>
<management> <management>
<type>customer-managed</type> <type>customer-managed</type>
</management> </management>
</site> </site>
The case described above is different from the cloud-access container The case described above is different from a scenario using the
usage as the cloud-access provides a public cloud access while this "cloud-accesses" container, as the cloud-access provides a public
example enables access to private resources located in a cloud cloud access while this example enables access to private resources
service provider network. located in a CSP network.
6.15.2. Defining NNI with option B flavor 6.15.2. Defining an NNI with the Option B Flavor
AS A AS B AS A AS B
--------------------- -------------------- ------------------- -------------------
/ \ / \ / \ / \
| | | | | | | |
| ++++++++ InterAS link ++++++++ | | ++++++++ Inter-AS link ++++++++ |
| + +_____________ + + | | + +_______________+ + |
| + + + + | | + + + + |
| + ASBR +<---mpebgp--->+ ASBR + | | + ASBR +<---MP-BGP---->+ ASBR + |
| + + + + | | + + + + |
| + +______________+ + | | + +_______________+ + |
| ++++++++ ++++++++ | | ++++++++ ++++++++ |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| ++++++++ InterAS link ++++++++ | | ++++++++ Inter-AS link ++++++++ |
| + +_____________ + + | | + +_______________+ + |
| + + + + | | + + + + |
| + ASBR +<---mpebgp--->+ ASBR + | | + ASBR +<---MP-BGP---->+ ASBR + |
| + + + + | | + + + + |
| + +______________+ + | | + +_______________+ + |
| ++++++++ ++++++++ | | ++++++++ ++++++++ |
| | | | | | | |
| | | | | | | |
\ / \ / \ / \ /
-------------------- ------------------- ------------------- -------------------
In option B, the two ASes are connected between each other with In option B, the two ASes are connected to each other with physical
physical links on Autonomous System Border Routers (ASBR). There may links on ASBRs. For resiliency purposes, there may be multiple
be multiple physical connections between the ASes for a resiliency physical connections between the ASes. The VPN "connection" between
purpose. The VPN "connection" between ASes is done by exchanging VPN ASes is done by exchanging VPN routes through MP-BGP [RFC4760].
routes through MP-BGP.
There are multiple flavors of implementations of such NNI, for There are multiple flavors of implementations of such an NNI. For
example: example:
1. The NNI is a provider internal NNI between a backbone and a DC. 1. The NNI is internal to the provider and is situated between a
There is enough trust between the domains to not filter the VPN backbone and a data center. There is enough trust between the
routes. So all the VPN routes are exchanged. Route target domains to not filter the VPN routes. So, all the VPN routes are
filtering may be implemented to save some unnecessary route exchanged. RT filtering may be implemented to save some
states. unnecessary route states.
2. The NNI is used between providers that agreed to exchange VPN 2. The NNI is used between providers that agreed to exchange VPN
routes for specific route-targets only. Each provider is routes for specific RTs only. Each provider is authorized to use
authorized to use the route-target values from the other the RT values from the other provider.
provider.
3. The NNI is used between providers that agreed to exchange VPN 3. The NNI is used between providers that agreed to exchange VPN
routes for specific route-targets only. Each provider has its routes for specific RTs only. Each provider has its own RT
own route-target scheme. So a customer spanning the two networks scheme. So, a customer spanning the two networks will have
will have different route-target in each network for a particular different RTs in each network for a particular VPN.
VPN.
Case 1 does not require any service modeling, as the protocol enables Case 1 does not require any service modeling, as the protocol enables
dynamic exchange of necessary VPN routes. the dynamic exchange of necessary VPN routes.
Case 2 requires to maintain some route-target filtering policy on Case 2 requires that an RT-filtering policy on ASBRs be maintained.
ASBRs. From a service modeling point of view, it is necessary to From a service modeling point of view, it is necessary to agree on
agree on the list of route target to authorize. the list of RTs to authorize.
In case 3, both ASes need to agree on the VPN route-target to In Case 3, both ASes need to agree on the VPN RT to exchange, as well
exchange and in addition how to map a VPN route-target from AS A to as how to map a VPN RT from AS A to the corresponding RT in AS B (and
the corresponding route-target in AS B (and vice-versa). vice versa).
Those modelings are currently out of scope of this document. Those modelings are currently out of scope for this document.
Cloud SP L3VPN SP B CSP A L3VPN SP B
A
----------------- --------------------
/ \ / \
| | | | |
| VM --| ++++++++ NNI ++++++++ |---- VPN1
| | + +_________+ + | Site#1
| |-------+ + + + |
| | + ASBR +<-mpebgp->+ ASBR + |
| | + +_________+ + |
| | ++++++++ ++++++++ |
| VM --| | | |---- VPN1
| |Virtual | | | Site#2
| |Network | | |
| VM --| | | |---- VPN1
| | | | | Site#3
\ / | |
---------------- | |
\ /
-------------------
|
|
VPN1
Site#4
The example above describes an NNI connection between the service ----------------- ------------------
provider network B and a cloud service provider A. Both service / \ / \
providers do not trust themselves and use a different route-target | | | | |
allocation policy. So, in term of implementation, the customer VPN | VM --| ++++++++ NNI ++++++++ |--- VPN1
has a different route-target in each network (RT A in CSP A and RT B | | + +__________+ + | Site#1
is CSP B). In order to connect the customer virtual network in CSP A | |-------+ + + + |
to the customer IPVPN (VPN1) in SP B network, CSP A should request SP | | + ASBR +<-MP-BGP->+ ASBR + |
B to open the customer VPN on the NNI (accept the appropriate RT). | | + +__________+ + |
Who does the RT translation is up to an agreement between the two | | ++++++++ ++++++++ |
service providers: SP B may permit CSP A to request VPN (RT) | VM --| | | |--- VPN1
translation. | |Virtual | | | Site#2
| |Network | | |
| VM --| | | |--- VPN1
| | | | | Site#3
\ / | |
----------------- | |
\ /
------------------
|
|
VPN1
Site#4
6.15.3. Defining NNI with option C flavor The example above describes an NNI connection between CSP A and SP
AS A AS B network B. Both SPs do not trust themselves and use a different RT
--------------------- -------------------- allocation policy. So, in terms of implementation, the customer VPN
/ \ / \ has a different RT in each network (RT A in CSP A and RT B in SP
| | | | network B). In order to connect the customer virtual network in
| | | | CSP A to the customer IP VPN (VPN1) in SP network B, CSP A should
| | | | request that SP network B open the customer VPN on the NNI (accept
| ++++++++ Multihop ebgp++++++++ | the appropriate RT). Who does the RT translation depends on the
| + + + + | agreement between the two SPs: SP B may permit CSP A to request VPN
| + + + + | (RT) translation.
| + RGW +<---mpebgp--->+ RGW + |
| + + + + |
| + + + + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| | | |
| | | |
| ++++++++ InterAS link ++++++++ |
| + +_____________ + + |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + +______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ InterAS link ++++++++ |
| + +_____________ + + |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + +______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
-------------------- -------------------
From a VPN service perspective, option C NNI is very similar to 6.15.3. Defining an NNI with the Option C Flavor
option B as an MP-BGP session is used to exchange VPN routes between
the ASes. The difference is that the forwarding and control plane
are on different nodes, so the MP-BGP is multihop between routing
gateway (RGW) nodes.
Modeling option B and C will be identical from a VPN service point of AS A AS B
view. ------------------- -------------------
/ \ / \
| | | |
| | | |
| | | |
| ++++++++ Multihop E-BGP ++++++++ |
| + + + + |
| + + + + |
| + RGW +<----MP-BGP---->+ RGW + |
| + + + + |
| + + + + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
7. Service model usage example From a VPN service's perspective, the option C NNI is very similar to
option B, as an MP-BGP session is used to exchange VPN routes between
the ASes. The difference is that the forwarding plane and the
control plane are on different nodes, so the MP-BGP session is
multihop between routing gateway (RGW) nodes.
From a VPN service's point of view, modeling options B and C will be
identical.
7. Service Model Usage Example
As explained in Section 5, this service model is intended to be As explained in Section 5, this service model is intended to be
instantiated at a management layer and is not intended to be used instantiated at a management layer and is not intended to be used
directly on network elements. The management system serves as a directly on network elements. The management system serves as a
central point of configuration of the overall service. central point of configuration of the overall service.
This section provides an example on how a management system can use This section provides an example of how a management system can use
this model to configure an IPVPN service on network elements. this model to configure an IP VPN service on network elements.
The example wants to achieve the provisionning of a VPN service for 3 In this example, we want to achieve the provisioning of a VPN service
sites using Hub and Spoke VPN service topology. One of the sites for three sites using a Hub-and-Spoke VPN service topology. One of
will be dual homed and loadsharing is expected. the sites will be dual-homed, and load-sharing is expected.
+-------------------------------------------------------------+ +-------------------------------------------------------------+
| Hub_Site ------ PE1 PE2 ------ Spoke_Site1 | | Hub_Site ------ PE1 PE2 ------ Spoke_Site1 |
| | +----------------------------------+ | | +----------------------------------+
| | | | | |
| | +----------------------------------+ | | +----------------------------------+
| Hub_Site ------ PE3 PE4 ------ Spoke_Site2 | | Hub_Site ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
The following XML describes the overall simplified service The following XML describes the overall simplified service
configuration of this VPN. configuration of this VPN.
<vpn-service> <vpn-service>
<vpn-id>12456487</vpn-id> <vpn-id>12456487</vpn-id>
<vpn-service-topology>hub-spoke</vpn-service-topology> <vpn-service-topology>hub-spoke</vpn-service-topology>
</vpn-service> </vpn-service>
When receiving the request for provisioning the VPN service, the When receiving the request for provisioning the VPN service, the
management system will internally (or through communication with management system will internally (or through communication with
another OSS component) allocates VPN route-targets. In this specific another OSS component) allocate VPN RTs. In this specific case, two
case two RTs will be allocated (100:1 for Hub and 100:2 for Spoke). RTs will be allocated (100:1 for Hub and 100:2 for Spoke). The
The output below describes the configuration of Spoke1. output below describes the configuration of Spoke_Site1.
<site> <site>
<site-id>Spoke_Site1</site-id> <site-id>Spoke_Site1</site-id>
<location> <location>
<city>NY</city> <city>NY</city>
<country-code>US</country-code> <country-code>US</country-code>
</location> </location>
<routing-protocols> <routing-protocols>
<routing-protocol> <routing-protocol>
<type>bgp</type> <type>bgp</type>
skipping to change at page 91, line 50 skipping to change at page 91, line 8
</addresses> </addresses>
</ipv4> </ipv4>
<ipv6> <ipv6>
<address-allocation-type> <address-allocation-type>
static-address static-address
</address-allocation-type> </address-allocation-type>
<addresses> <addresses>
<provider-address>2001:db8::1</provider-address> <provider-address>2001:db8::1</provider-address>
<customer-address>2001:db8::2</customer-address> <customer-address>2001:db8::2</customer-address>
<mask>64</mask> <mask>64</mask>
</addresses> </addresses>
</ipv6> </ipv6>
</ip-connection> </ip-connection>
<service> <service>
<svc-input-bandwidth>450000000</svc-input-bandwidth> <svc-input-bandwidth>450000000</svc-input-bandwidth>
<svc-output-bandwidth>450000000</svc-output-bandwidth> <svc-output-bandwidth>450000000</svc-output-bandwidth>
</service> </service>
<vpn-attachment> <vpn-attachment>
<vpn-id>12456487</vpn-id> <vpn-id>12456487</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
skipping to change at page 92, line 21 skipping to change at page 91, line 26
<vpn-id>12456487</vpn-id> <vpn-id>12456487</vpn-id>
<site-role>spoke-role</site-role> <site-role>spoke-role</site-role>
</vpn-attachment> </vpn-attachment>
</site-network-access> </site-network-access>
</site-network-accesses> </site-network-accesses>
<management> <management>
<type>provider-managed</type> <type>provider-managed</type>
</management> </management>
</site> </site>
When receiving the request for provisioning Spoke1 site, the When receiving the request for provisioning Spoke_Site1, the
management system MUST allocate network resources for this site. It management system MUST allocate network resources for this site. It
MUST first determine the target network elements to provision the MUST first determine the target network elements to provision the
access, and especially the PE router (and may be an aggregation access, particularly the PE router (and perhaps also an aggregation
switch). As described in Section 6.6, the management system SHOULD switch). As described in Section 6.6, the management system SHOULD
use the location information and SHOULD use the access-diversity use the location information and SHOULD use the access-diversity
constraint to find the appropriate PE. In this case, we consider constraint to find the appropriate PE. In this case, we consider
Spoke1 requires PE diversity with Hub and that management system that Spoke_Site1 requires PE diversity with the Hub and that the
allocate PEs based on lowest distance. Based on the location management system allocates PEs based on the least distance. Based
information, the management system finds the available PEs in the on the location information, the management system finds the
nearest area of the customer and picks one that fits the access- available PEs in the area nearest the customer and picks one that
diversity constraint. fits the access-diversity constraint.
When the PE is chosen, the management system needs to allocate When the PE is chosen, the management system needs to allocate
interface resources on the node. One interface is selected from the interface resources on the node. One interface is selected from the
PE available pool. The management system can start provisioning the pool of available PEs. The management system can start provisioning
PE node by using any mean (Netconf, CLI, ...). The management system the chosen PE node via whatever means the management system prefers
will check if a VRF is already present that fits the needs. If not, (e.g., NETCONF, CLI). The management system will check to see if a
it will provision the VRF: Route distinguisher will come from VRF that fits its needs is already present. If not, it will
internal allocation policy model, route-targets are coming from the provision the VRF: the RD will be derived from the internal
vpn-policy configuration of the site (management system allocated allocation policy model, and the RTs will be derived from the VPN
some RTs for the VPN). As the site is a Spoke site (site-role), the policy configuration of the site (the management system allocated
management system knows which RT must be imported and exported. As some RTs for the VPN). As the site is a Spoke site ("site-role"),
the site is provider managed, some management route-targets may also the management system knows which RTs must be imported and exported.
be added (100:5000). Standard provider VPN policies MAY also be As the site is provider managed, some management RTs may also be
added in the configuration. added (100:5000). Standard provider VPN policies MAY also be added
in the configuration.
Example of generated PE configuration: Example of generated PE configuration:
ip vrf Customer1 ip vrf Customer1
export-map STD-CUSTOMER-EXPORT <---- Standard SP configuration export-map STD-CUSTOMER-EXPORT <---- Standard SP configuration
route-distinguisher 100:3123234324 route-distinguisher 100:3123234324
route-target import 100:1 route-target import 100:1
route-target import 100:5000 <---- Standard SP configuration route-target import 100:5000 <---- Standard SP configuration
route-target export 100:2 for provider managed route-target export 100:2 for provider-managed CE
! !
When the VRF has been provisioned, the management system can start When the VRF has been provisioned, the management system can start
configuring the access on the PE using the allocated interface configuring the access on the PE using the allocated interface
information. IP addressing is chosen by the management system. One information. IP addressing is chosen by the management system. One
address will be picked from an allocated subnet for the PE, another address will be picked from an allocated subnet for the PE, and
will be used for the CE configuration. Routing protocols will also another will be used for the CE configuration. Routing protocols
be configured between PE and CE and due to provider managed model, will also be configured between the PE and CE; because this model is
the choice is up to service provider: BGP was chosen for the example. provider managed, the choices are left to the SP. BGP was chosen for
This choice is independant of the routing protocol chosen by this example. This choice is independent of the routing protocol
customer. For the CE - LAN part, BGP will be used as requested in chosen by the customer. BGP will be used to configure the CE-to-LAN
the service model. Peering addresses will be derived from those of connection as requested in the service model. Peering addresses will
the connection. As CE is provider managed, CE AS number can be be derived from those of the connection. As the CE is provider
automatically allocated by the management system. Some provider managed, the CE's AS number can be automatically allocated by the
standard configuration templates may also be added. management system. Standard configuration templates provided by the
SP may also be added.
Example of generated PE configuration: Example of generated PE configuration:
interface Ethernet1/1/0.10 interface Ethernet1/1/0.10
encapsulation dot1q 10 encapsulation dot1q 10
ip vrf forwarding Customer1 ip vrf forwarding Customer1
ip address 198.51.100.1 255.255.255.252 <---- Comes from ip address 198.51.100.1 255.255.255.252 <---- Comes from
automated allocation automated allocation
ipv6 address 2001:db8::10:1/64 ipv6 address 2001:db8::10:1/64
ip access-group STD-PROTECT-IN <---- Standard SP config ip access-group STD-PROTECT-IN <---- Standard SP config
! !
router bgp 100 router bgp 100
address-family ipv4 vrf Customer1 address-family ipv4 vrf Customer1
neighbor 198.51.100.2 remote-as 65000 <---- Comes from neighbor 198.51.100.2 remote-as 65000 <---- Comes from
automated allocation automated allocation
neighbor 198.51.100.2 route-map STD in <---- Standard SP config neighbor 198.51.100.2 route-map STD in <---- Standard SP config
neighbor 198.51.100.2 filter-list 10 in <---- Standard SP config neighbor 198.51.100.2 filter-list 10 in <---- Standard SP config
! !
address-family ipv6 vrf Customer1 address-family ipv6 vrf Customer1
neighbor 2001:db8::0A10:2 remote-as 65000 <---- Comes from neighbor 2001:db8::0a10:2 remote-as 65000 <---- Comes from
automated allocation automated allocation
neighbor 2001:db8::0A10:2 route-map STD in <---- Standard SP config neighbor 2001:db8::0a10:2 route-map STD in <---- Standard SP
neighbor 2001:db8::0A10:2 filter-list 10 in <---- Standard SP config config
! neighbor 2001:db8::0a10:2 filter-list 10 in <---- Standard SP
ip route vrf Customer1 192.0.2.1 255.255.255.255 198.51.100.2 config
! Static route for provider administration of CE !
! ip route vrf Customer1 192.0.2.1 255.255.255.255 198.51.100.2
! Static route for provider administration of CE
!
As the CE router is not reachable at this stage, the management As the CE router is not reachable at this stage, the management
system can produce a complete CE configuration that can be uploaded system can produce a complete CE configuration that can be manually
to the node by manual operation before sending the CE to customer uploaded to the node before sending the CE configuration to the
premise. The CE configuration will be built as for the PE. Based on customer premises. The CE configuration will be built in the same
the CE type (vendor/model) allocated to the customer and bearer way as the PE would be configured. Based on the CE type
(vendor/model) allocated to the customer as well as the bearer
information, the management system knows which interface must be information, the management system knows which interface must be
configured on the CE. PE-CE link configuration is expected to be configured on the CE. PE-CE link configuration is expected to be
handled automatically using the service provider OSS as both handled automatically using the SP OSS, as both resources are managed
resources are managed internally. CE to LAN interface parameters internally. CE-to-LAN-interface parameters such as IP addressing are
like IP addressing are derived from ip-connection taking into account derived from the "ip-connection" container, taking into account how
how management system distributes addresses between PE and CE within the management system distributes addresses between the PE and CE
the subnet. This will allow to produce a plug'n'play configuration within the subnet. This will allow a plug-and-play configuration for
for the CE. the CE to be created.
Example of generated CE configuration: Example of generated CE configuration:
interface Loopback10 interface Loopback10
description "Administration" description "Administration"
ip address 192.0.2.1 255.255.255.255 ip address 192.0.2.1 255.255.255.255
! !
interface FastEthernet10 interface FastEthernet10
description "WAN" description "WAN"
ip address 198.51.100.2 255.255.255.252 <---- Comes from ip address 198.51.100.2 255.255.255.252 <---- Comes from
automated allocation automated allocation
ipv6 address 2001:db8::0A10:2/64 ipv6 address 2001:db8::0a10:2/64
! !
interface FastEthernet11 interface FastEthernet11
description "LAN" description "LAN"
ip address 203.0.113.254 255.255.255.0 <---- Comes from ip address 203.0.113.254 255.255.255.0 <---- Comes from the
ip-connection "ip-connection" container
ipv6 address 2001:db8::1/64 ipv6 address 2001:db8::1/64
! !
router bgp 65000 router bgp 65000
address-family ipv4 address-family ipv4
redistribute static route-map STATIC2BGP <---- Standard SP redistribute static route-map STATIC2BGP <---- Standard SP
configuration configuration
neighbor 198.51.100.1 remote-as 100 <---- Comes from neighbor 198.51.100.1 remote-as 100 <---- Comes from
automated allocation automated allocation
neighbor 203.0.113.2 remote-as 500 <---- Comes from neighbor 203.0.113.2 remote-as 500 <---- Comes from the
ip-connection "ip-connection" container
address-family ipv6 address-family ipv6
redistribute static route-map STATIC2BGP <---- Standard SP redistribute static route-map STATIC2BGP <---- Standard SP
configuration configuration
neighbor 2001:db8::0A10:1 remote-as 100 <---- Comes from neighbor 2001:db8::0a10:1 remote-as 100 <---- Comes from
automated allocation automated allocation
neighbor 2001:db8::2 remote-as 500 <---- Comes from neighbor 2001:db8::2 remote-as 500 <---- Comes from the
ip-connection "ip-connection" container
! !
route-map STATIC2BGP permit 10 route-map STATIC2BGP permit 10
match tag 10 match tag 10
! !
8. Interaction with Other YANG Modules 8. Interaction with Other YANG Modules
As expressed in Section 5, this service module is intended to be As expressed in Section 5, this service model is intended to be
instantiated in management system and not directly on network instantiated in a management system and not directly on network
elements. elements.
It will be the role of the management system to configure the network The management system's role will be to configure the network
elements. The management system may be modular, so the component elements. The management system may be modular, so the component
instantiating the service model (let's call it service component) and instantiating the service model (let's call it "service component")
the component responsible for network element configuration (let's and the component responsible for network element configuration
call it configuration component) may be different. (let's call it "configuration component") may be different.
L3VPN-SVC | l3vpn-svc |
service model | Model |
| |
+----------------------+ +---------------------+
| Service component | service datastore | Service component | Service datastore
+----------------------+ +---------------------+
| |
| |
+----------------------+ +---------------------+
+----| Config component |-------+ +----| Config component |------+
/ +----------------------+ \ Network / +---------------------+ \ Network
/ / \ \ Configuration / / \ \ Configuration
/ / \ \ models / / \ \ models
/ / \ \ / / \ \
+++++++ ++++++++ ++++++++ +++++++ ++++++++ ++++++++ ++++++++ ++++++++
+ CEA + ------- + PE A + + PE B + ----- + CEB + Config + CE A + ------- + PE A + + PE B + ----- + CE B + Config
+++++++ ++++++++ ++++++++ +++++++ datastore ++++++++ ++++++++ ++++++++ ++++++++ datastore
Site A Site B Site A Site B
In the previous sections, we provided some example of translation of In the previous sections, we provided some examples of the
service provisioning request to router configuration lines as an translation of service provisioning requests to router configuration
illustration. In the NETCONF/YANG ecosystem, it will be expected lines. In the NETCONF/YANG ecosystem, we expect NETCONF/YANG to be
NETCONF/YANG to be used between configuration component and network used between the configuration component and network elements to
elements to configure the requested service on these elements. configure the requested services on those elements.
In this framework, it is expected from standardization to also work In this framework, specifications are expected to provide specific
on specific configuration YANG modelization of service components on YANG modeling of service components on network elements. There will
network elements. There will be a strong relation between the be a strong relationship between the abstracted view provided by this
abstracted view provided by this service model and the detailed service model and the detailed configuration view that will be
configuration view that will be provided by specific configuration provided by specific configuration models for network elements.
models for network elements.
Authors of this document are expecting definition of YANG models for The authors of this document anticipate definitions of YANG models
network elements on this non exhaustive list of items: for the network elements listed below. Note that this list is not
exhaustive:
o VRF definition including VPN policy expression. o VRF definition, including VPN policy expression.
o Physical interface. o Physical interface.
o IP layer (IPv4, IPv6). o IP layer (IPv4, IPv6).
o QoS: classification, profiles... o QoS: classification, profiles, etc.
o Routing protocols: support of configuration of all protocols o Routing protocols: support of configuration of all protocols
listed in the document, as well as routing policies associated listed in the document, as well as routing policies associated
with these protocols. with those protocols.
o Multicast VPN. o Multicast VPN.
o Network Address Translation. o Network address translation.
o ...
Example of VPN site request at service level using this model: Example of a VPN site request at the service level, using this model:
<site> <site>
<site-id>Site A</site-id> <site-id>Site A</site-id>
<site-network-accesses> <site-network-accesses>
<site-network-access> <site-network-access>
<ip-connection> <ip-connection>
<ipv4> <ipv4>
<address-allocation-type> <address-allocation-type>
static-address static-address
</address-allocation-type> </address-allocation-type>
skipping to change at page 98, line 4 skipping to change at page 96, line 47
<ipv4-lan-prefixes> <ipv4-lan-prefixes>
<lan>198.51.100.0/30</lan> <lan>198.51.100.0/30</lan>
<next-hop>203.0.113.2</next-hop> <next-hop>203.0.113.2</next-hop>
</ipv4-lan-prefixes> </ipv4-lan-prefixes>
</cascaded-lan-prefixes> </cascaded-lan-prefixes>
</static> </static>
</routing-protocol> </routing-protocol>
</routing-protocols> </routing-protocols>
<management> <management>
<type>customer-managed</type> <type>customer-managed</type>
</management> </management>
<vpn-policies> <vpn-policies>
<vpn-policy> <vpn-policy>
<vpn-policy-id>VPNPOL1</vpn-policy-id> <vpn-policy-id>VPNPOL1</vpn-policy-id>
<entries> <entries>
<id>1</id> <id>1</id>
<vpn> <vpn>
<vpn-id>VPN1</vpn-id> <vpn-id>VPN1</vpn-id>
<site-role>any-to-any-role</site-role> <site-role>any-to-any-role</site-role>
</vpn> </vpn>
</entries> </entries>
</vpn-policy> </vpn-policy>
</vpn-policies> </vpn-policies>
</site> </site>
In the service example above, it is expected that the service In the service example above, the service component is expected to
component requests to the configuration component of the management request that the configuration component of the management system
system the configuration of the service elements. If we consider provide the configuration of the service elements. If we consider
that service component selected a PE (PE A) as target PE for the that the service component selected a PE (PE A) as the target PE for
site, the configuration component will need to push the configuration the site, the configuration component will need to push the
to PE A. The configuration component will use several YANG data configuration to PE A. The configuration component will use several
models to define the configuration to be applied to PE A. The XML YANG data models to define the configuration to be applied to PE A.
configuration of PE-A may look like this: The XML configuration of PE A might look like this:
<if:interfaces> <if:interfaces>
<if:interface> <if:interface>
<if:name>eth0</if:name> <if:name>eth0</if:name>
<if:type>ianaift:ethernetCsmacd</if:type> <if:type>ianaift:ethernetCsmacd</if:type>
<if:description> <if:description>
Link to CEA. Link to CE A.
</if:description> </if:description>
<ip:ipv4> <ip:ipv4>
<ip:address> <ip:address>
<ip:ip>203.0.113.254</ip:ip> <ip:ip>203.0.113.254</ip:ip>
<ip:prefix-length>24</ip:prefix-length> <ip:prefix-length>24</ip:prefix-length>
</ip:address> </ip:address>
<ip:forwarding>true</ip:forwarding> <ip:forwarding>true</ip:forwarding>
</ip:ipv4> </ip:ipv4>
</if:interface> </if:interface>
</if:interfaces> </if:interfaces>
<rt:routing> <rt:routing>
<rt:routing-instance> <rt:routing-instance>
<rt:name>VRF_CustA</rt:name> <rt:name>VRF_CustA</rt:name>
<rt:type>l3vpn:vrf</rt:type> <rt:type>l3vpn:vrf</rt:type>
<rt:description>VRF for CustomerA</rt:description> <rt:description>VRF for Customer A</rt:description>
<l3vpn:route-distinguisher> <l3vpn:route-distinguisher>
100:1546542343 100:1546542343
</l3vpn:route-distinguisher> </l3vpn:route-distinguisher>
<l3vpn:import-rt>100:1</l3vpn:import-rt> <l3vpn:import-rt>100:1</l3vpn:import-rt>
<l3vpn:export-rt>100:1</l3vpn:export-rt> <l3vpn:export-rt>100:1</l3vpn:export-rt>
<rt:interfaces> <rt:interfaces>
<rt:interface> <rt:interface>
<rt:name>eth0</rt:name> <rt:name>eth0</rt:name>
</rt:interface> </rt:interface>
</rt:interfaces> </rt:interfaces>
<rt:routing-protocols> <rt:routing-protocols>
<rt:routing-protocol> <rt:routing-protocol>
<rt:type>rt:static</rt:type> <rt:type>rt:static</rt:type>
<rt:name>st0</rt:name> <rt:name>st0</rt:name>
<rt:static-routes> <rt:static-routes>
<v4ur:ipv4> <v4ur:ipv4>
<v4ur:route> <v4ur:route>
<v4ur:destination-prefix> <v4ur:destination-prefix>
198.51.100.0/30 198.51.100.0/30
skipping to change at page 99, line 36 skipping to change at page 98, line 31
</v4ur:route> </v4ur:route>
</v4ur:ipv4> </v4ur:ipv4>
</rt:static-routes> </rt:static-routes>
</rt:routing-protocol> </rt:routing-protocol>
</rt:routing-protocols> </rt:routing-protocols>
</rt:routing-instance> </rt:routing-instance>
</rt:routing> </rt:routing>
9. YANG Module 9. YANG Module
<CODE BEGINS> file "ietf-l3vpn-svc@2016-11-04.yang" <CODE BEGINS>
file "ietf-l3vpn-svc@2017-01-27.yang"
module ietf-l3vpn-svc { module ietf-l3vpn-svc {
namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc"; namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
prefix l3vpn-svc; prefix l3vpn-svc;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
skipping to change at page 100, line 4 skipping to change at page 98, line 47
prefix l3vpn-svc; prefix l3vpn-svc;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
} }
organization organization
"IETF L3SM Working Group"; "IETF L3SM Working Group";
contact contact
"WG List: &lt;mailto:l3sm@ietf.org&gt; "WG List: <mailto:l3sm@ietf.org>
Editor: Editor:
L3SM WG L3SM WG
Chairs: Chairs:
Adrian Farrel, Qin Wu Adrian Farrel, Qin Wu
"; ";
description description
"The YANG module defines a generic service configuration "This YANG module defines a generic service configuration
model for Layer 3 VPN common across all of the vendor model for Layer 3 VPNs. This model is common across all
implementations."; vendor implementations.";
revision 2016-11-03 { revision 2017-01-27 {
description description
"Initial document"; "Initial document.";
reference reference
"RFC XXXX"; "RFC 8049.";
} }
/* Features */ /* Features */
feature cloud-access { feature cloud-access {
description description
"Allow VPN to connect to a Cloud Service "Allows the VPN to connect to a CSP.";
provider.";
} }
feature multicast { feature multicast {
description description
"Enables multicast capabilities in a VPN"; "Enables multicast capabilities in a VPN.";
} }
feature ipv4 { feature ipv4 {
description description
"Enables IPv4 support in a VPN"; "Enables IPv4 support in a VPN.";
} }
feature ipv6 { feature ipv6 {
description description
"Enables IPv6 support in a VPN"; "Enables IPv6 support in a VPN.";
} }
feature carrierscarrier { feature carrierscarrier {
description description
"Enables support of carrier's carrier"; "Enables support of CsC.";
} }
feature extranet-vpn { feature extranet-vpn {
description description
"Enables support of extranet VPNs"; "Enables support of extranet VPNs.";
} }
feature site-diversity { feature site-diversity {
description description
"Enables support of site diversity constraints"; "Enables support of site diversity constraints.";
} }
feature encryption { feature encryption {
description description
"Enables support of encryption"; "Enables support of encryption.";
} }
feature qos { feature qos {
description description
"Enables support of Class of Services"; "Enables support of classes of services.";
} }
feature qos-custom { feature qos-custom {
description description
"Enables support of custom qos profile"; "Enables support of the custom QoS profile.";
} }
feature rtg-bgp { feature rtg-bgp {
description description
"Enables support of BGP routing protocol."; "Enables support of the BGP routing protocol.";
} }
feature rtg-rip { feature rtg-rip {
description description
"Enables support of RIP routing protocol."; "Enables support of the RIP routing protocol.";
} }
feature rtg-ospf { feature rtg-ospf {
description description
"Enables support of OSPF routing protocol."; "Enables support of the OSPF routing protocol.";
} }
feature rtg-ospf-sham-link { feature rtg-ospf-sham-link {
description description
"Enables support of OSPF sham-links."; "Enables support of OSPF sham links.";
} }
feature rtg-vrrp { feature rtg-vrrp {
description description
"Enables support of VRRP routing protocol."; "Enables support of the VRRP routing protocol.";
} }
feature fast-reroute { feature fast-reroute {
description description
"Enables support of Fast Reroute."; "Enables support of Fast Reroute.";
} }
feature bfd { feature bfd {
description description
"Enables support of BFD."; "Enables support of BFD.";
} }
feature always-on { feature always-on {
description description
"Enables support for always-on access "Enables support of the 'always-on' access constraint.";
constraint.";
} }
feature requested-type { feature requested-type {
description description
"Enables support for requested-type access "Enables support of the 'requested-type' access constraint.";
constraint.";
} }
feature bearer-reference { feature bearer-reference {
description description
"Enables support for bearer-reference access "Enables support of the 'bearer-reference' access constraint.";
constraint.";
} }
/* Typedefs */ /* Typedefs */
typedef svc-id { typedef svc-id {
type string; type string;
description description
"Defining a type of service component "Defines a type of service component identifier.";
identificators.";
} }
typedef template-id { typedef template-id {
type string; type string;
description description
"Defining a type of service template "Defines a type of service template identifier.";
identificators.";
} }
typedef address-family { typedef address-family {
type enumeration { type enumeration {
enum ipv4 { enum ipv4 {
description description
"IPv4 address family"; "IPv4 address family.";
} }
enum ipv6 { enum ipv6 {
description description
"IPv6 address family"; "IPv6 address family.";
} }
} }
description description
"Defining a type for address-family."; "Defines a type for the address family.";
} }
/* Identities */ /* Identities */
identity site-network-access-type { identity site-network-access-type {
description description
"Base identity for site-network-access type"; "Base identity for site-network-access type.";
} }
identity point-to-point { identity point-to-point {
base site-network-access-type; base site-network-access-type;
description description
"Identity for point-to-point connection"; "Identity for point-to-point connection.";
} }
identity multipoint { identity multipoint {
base site-network-access-type; base site-network-access-type;
description description
"Identity for multipoint connection "Identity for multipoint connection.
Example : ethernet broadcast segment"; Example: Ethernet broadcast segment.";
} }
identity placement-diversity { identity placement-diversity {
description description
"Base identity for site placement "Base identity for site placement constraints.";
constraints";
} }
identity bearer-diverse { identity bearer-diverse {
base placement-diversity; base placement-diversity;
description description
"Identity for bearer diversity. "Identity for bearer diversity.
The bearers should not use common elements."; The bearers should not use common elements.";
} }
identity pe-diverse { identity pe-diverse {
base placement-diversity; base placement-diversity;
description description
"Identity for PE diversity"; "Identity for PE diversity.";
} }
identity pop-diverse { identity pop-diverse {
base placement-diversity; base placement-diversity;
description description
"Identity for POP diversity"; "Identity for POP diversity.";
} }
identity linecard-diverse { identity linecard-diverse {
base placement-diversity; base placement-diversity;
description description
"Identity for linecard diversity"; "Identity for linecard diversity.";
} }
identity same-pe { identity same-pe {
base placement-diversity; base placement-diversity;
description description
"Identity for having sites connected "Identity for having sites connected on the same PE.";
on the same PE";
} }
identity same-bearer { identity same-bearer {
base placement-diversity; base placement-diversity;
description description
"Identity for having sites connected "Identity for having sites connected using the same bearer.";
using the same bearer";
} }
identity customer-application { identity customer-application {
description description
"Base identity for customer application"; "Base identity for customer application.";
} }
identity web { identity web {
base customer-application; base customer-application;
description description
"Identity for web application (e.g. HTTP,HTTPS)"; "Identity for Web application (e.g., HTTP, HTTPS).";
} }
identity mail { identity mail {
base customer-application; base customer-application;
description description
"Identity for mail applications"; "Identity for mail application.";
} }
identity file-transfer { identity file-transfer {
base customer-application; base customer-application;
description description
"Identity for file transfer applications ( "Identity for file transfer application (e.g., FTP, SFTP).";
e.g. FTP, SFTP, ...)";
} }
identity database { identity database {
base customer-application; base customer-application;
description description
"Identity for database applications"; "Identity for database application.";
} }
identity social { identity social {
base customer-application; base customer-application;
description description
"Identity for social network applications"; "Identity for social-network application.";
} }
identity games { identity games {
base customer-application; base customer-application;
description description
"Identity for gaming applications"; "Identity for gaming application.";
} }
identity p2p { identity p2p {
base customer-application; base customer-application;
description description
"Identity for peer to peer applications"; "Identity for peer-to-peer application.";
} }
identity network-management { identity network-management {
base customer-application; base customer-application;
description description
"Identity for management applications (e.g. telnet "Identity for management application
syslog, snmp ...)"; (e.g., Telnet, syslog, SNMP).";
} }
identity voice { identity voice {
base customer-application; base customer-application;
description description
"Identity for voice applications"; "Identity for voice application.";
} }
identity video { identity video {
base customer-application; base customer-application;
description description
"Identity for video conference applications"; "Identity for video conference application.";
} }
identity site-vpn-flavor { identity site-vpn-flavor {
description description
"Base identity for the site VPN service flavor."; "Base identity for the site VPN service flavor.";
} }
identity site-vpn-flavor-single { identity site-vpn-flavor-single {
base site-vpn-flavor; base site-vpn-flavor;
description description
"Base identity for the site VPN service flavor. "Base identity for the site VPN service flavor.
Used when the site belongs to only one VPN."; Used when the site belongs to only one VPN.";
} }
identity site-vpn-flavor-multi { identity site-vpn-flavor-multi {
base site-vpn-flavor; base site-vpn-flavor;
description description
"Base identity for the site VPN service flavor. "Base identity for the site VPN service flavor.
Used when a logical connection of a site Used when a logical connection of a site
belongs to multiple VPNs."; belongs to multiple VPNs.";
} }
identity site-vpn-flavor-sub { identity site-vpn-flavor-sub {
base site-vpn-flavor; base site-vpn-flavor;
description description
"Base identity for the site VPN service flavor. "Base identity for the site VPN service flavor.
Used when a site has multiple logical connections. Used when a site has multiple logical connections.
Each of the connection may belong to different Each connection may belong to different multiple VPNs.";
multiple VPNs.";
} }
identity site-vpn-flavor-nni { identity site-vpn-flavor-nni {
base site-vpn-flavor; base site-vpn-flavor;
description description
"Base identity for the site VPN service flavor. "Base identity for the site VPN service flavor.
Used to describe a NNI option A connection."; Used to describe an NNI option A connection.";
} }
identity management { identity management {
description description
"Base identity for site management scheme."; "Base identity for site management scheme.";
} }
identity co-managed { identity co-managed {
base management; base management;
description description
"Base identity for comanaged site."; "Base identity for co-managed site.";
} }
identity customer-managed { identity customer-managed {
base management; base management;
description description
"Base identity for customer managed site."; "Base identity for customer-managed site.";
} }
identity provider-managed { identity provider-managed {
base management; base management;
description description
"Base identity for provider managed site."; "Base identity for provider-managed site.";
} }
identity address-allocation-type { identity address-allocation-type {
description description
"Base identity for address-allocation-type "Base identity for address-allocation-type for PE-CE link.";
for PE-CE link.";
} }
identity provider-dhcp { identity provider-dhcp {
base address-allocation-type; base address-allocation-type;
description description
"Provider network provides DHCP service to customer."; "Provider network provides DHCP service to customer.";
} }
identity provider-dhcp-relay { identity provider-dhcp-relay {
base address-allocation-type; base address-allocation-type;
description description
"Provider network provides DHCP relay service to customer."; "Provider network provides DHCP relay service to customer.";
} }
identity provider-dhcp-slaac { identity provider-dhcp-slaac {
base address-allocation-type; base address-allocation-type;
description description
"Provider network provides DHCP service to customer "Provider network provides DHCP service to customer,
as well as SLAAC."; as well as SLAAC.";
} }
identity static-address { identity static-address {
base address-allocation-type; base address-allocation-type;
description description
"Provider to customer addressing is static."; "Provider-to-customer addressing is static.";
} }
identity slaac { identity slaac {
base address-allocation-type; base address-allocation-type;
description description
"Use IPv6 SLAAC."; "Use IPv6 SLAAC.";
} }
identity site-role { identity site-role {
description description
"Base identity for site type."; "Base identity for site type.";
} }
identity any-to-any-role { identity any-to-any-role {
base site-role; base site-role;
description description
"Site in a any to any IPVPN."; "Site in an any-to-any IP VPN.";
} }
identity spoke-role { identity spoke-role {
base site-role; base site-role;
description description
"Spoke Site in a Hub & Spoke IPVPN."; "Spoke site in a Hub-and-Spoke IP VPN.";
} }
identity hub-role { identity hub-role {
base site-role; base site-role;
description description
"Hub Site in a Hub & Spoke IPVPN."; "Hub site in a Hub-and-Spoke IP VPN.";
} }
identity vpn-topology { identity vpn-topology {
description description
"Base identity for VPN topology."; "Base identity for VPN topology.";
} }
identity any-to-any { identity any-to-any {
base vpn-topology; base vpn-topology;
description description
"Identity for any to any VPN topology."; "Identity for any-to-any VPN topology.";
} }
identity hub-spoke { identity hub-spoke {
base vpn-topology; base vpn-topology;
description description
"Identity for Hub'n'Spoke VPN topology."; "Identity for Hub-and-Spoke VPN topology.";
} }
identity hub-spoke-disjoint { identity hub-spoke-disjoint {
base vpn-topology; base vpn-topology;
description description
"Identity for Hub'n'Spoke VPN topology "Identity for Hub-and-Spoke VPN topology
where Hubs cannot talk between each other."; where Hubs cannot communicate with each other.";
} }
identity multicast-tree-type { identity multicast-tree-type {
description description
"Base identity for multicast tree type."; "Base identity for multicast tree type.";
} }
identity ssm-tree-type { identity ssm-tree-type {
base multicast-tree-type; base multicast-tree-type;
description description
"Identity for SSM tree type."; "Identity for SSM tree type.";
} }
identity asm-tree-type { identity asm-tree-type {
base multicast-tree-type; base multicast-tree-type;
description description
"Identity for ASM tree type."; "Identity for ASM tree type.";
} }
skipping to change at page 108, line 25 skipping to change at page 106, line 45
"Identity for SSM tree type."; "Identity for SSM tree type.";
} }
identity asm-tree-type { identity asm-tree-type {
base multicast-tree-type; base multicast-tree-type;
description description
"Identity for ASM tree type."; "Identity for ASM tree type.";
} }
identity bidir-tree-type { identity bidir-tree-type {
base multicast-tree-type; base multicast-tree-type;
description description
"Identity for BiDir tree type."; "Identity for bidirectional tree type.";
} }
identity multicast-rp-discovery-type { identity multicast-rp-discovery-type {
description description
"Base identity for rp discovery type."; "Base identity for RP discovery type.";
} }
identity auto-rp { identity auto-rp {
base multicast-rp-discovery-type; base multicast-rp-discovery-type;
description description
"Base identity for auto-rp discovery type."; "Base identity for Auto-RP discovery type.";
} }
identity static-rp { identity static-rp {
base multicast-rp-discovery-type; base multicast-rp-discovery-type;
description description
"Base identity for static type."; "Base identity for static type.";
} }
identity bsr-rp { identity bsr-rp {
base multicast-rp-discovery-type; base multicast-rp-discovery-type;
description description
"Base identity for BDR discovery type."; "Base identity for BSR discovery type.";
} }
identity routing-protocol-type { identity routing-protocol-type {
description description
"Base identity for routing-protocol type."; "Base identity for routing protocol type.";
} }
identity ospf { identity ospf {
base routing-protocol-type; base routing-protocol-type;
description description
"Identity for OSPF protocol type."; "Identity for OSPF protocol type.";
} }
identity bgp { identity bgp {
base routing-protocol-type; base routing-protocol-type;
description description
"Identity for BGP protocol type."; "Identity for BGP protocol type.";
} }
identity static { identity static {
base routing-protocol-type; base routing-protocol-type;
description description
"Identity for static routing protocol type."; "Identity for static routing protocol type.";
} }
identity rip { identity rip {
base routing-protocol-type; base routing-protocol-type;
description description
"Identity for RIP protocol type."; "Identity for RIP protocol type.";
} }
identity vrrp { identity vrrp {
base routing-protocol-type; base routing-protocol-type;
description description
"Identity for VRRP protocol type. "Identity for VRRP protocol type.
This is to be used when LAn are directly connected This is to be used when LANs are directly connected
to provider Edge routers."; to PE routers.";
} }
identity direct { identity direct {
base routing-protocol-type; base routing-protocol-type;
description description
"Identity for direct protocol type. "Identity for direct protocol type.";
.";
} }
identity protocol-type { identity protocol-type {
description description
"Base identity for protocol field type."; "Base identity for protocol field type.";
} }
identity tcp { identity tcp {
base protocol-type; base protocol-type;
description description
"TCP protocol type."; "TCP protocol type.";
} }
identity udp { identity udp {
base protocol-type; base protocol-type;
description description
"UDP protocol type."; "UDP protocol type.";
} }
identity icmp { identity icmp {
base protocol-type; base protocol-type;
description description
"icmp protocol type."; "ICMP protocol type.";
} }
identity icmp6 { identity icmp6 {
base protocol-type; base protocol-type;
description description
"icmp v6 protocol type."; "ICMPv6 protocol type.";
} }
identity gre { identity gre {
base protocol-type; base protocol-type;
description description
"GRE protocol type."; "GRE protocol type.";
} }
identity ipip { identity ipip {
base protocol-type; base protocol-type;
description description
"IPinIP protocol type."; "IP-in-IP protocol type.";
} }
identity hop-by-hop { identity hop-by-hop {
base protocol-type; base protocol-type;
description description
"Hop by Hop IPv6 header type."; "Hop-by-Hop IPv6 header type.";
} }
identity routing { identity routing {
base protocol-type; base protocol-type;
description description
"Routing IPv6 header type."; "Routing IPv6 header type.";
} }
identity esp { identity esp {
base protocol-type; base protocol-type;
description description
"ESP header type."; "ESP header type.";
} }
identity ah { identity ah {
base protocol-type; base protocol-type;
description description
"AH header type."; "AH header type.";
skipping to change at page 111, line 16 skipping to change at page 109, line 29
grouping vpn-service-cloud-access { grouping vpn-service-cloud-access {
container cloud-accesses { container cloud-accesses {
if-feature cloud-access; if-feature cloud-access;
list cloud-access { list cloud-access {
key cloud-identifier; key cloud-identifier;
leaf cloud-identifier { leaf cloud-identifier {
type string; type string;
description description
"Identification of cloud service. Local "Identification of cloud service.
admin meaning."; Local administration meaning.";
} }
choice list-flavor { choice list-flavor {
case permit-any { case permit-any {
leaf permit-any { leaf permit-any {
type empty; type empty;
description description
"Allow all sites."; "Allows all sites.";
} }
} }
case deny-any-except { case deny-any-except {
leaf-list permit-site { leaf-list permit-site {
type leafref { type leafref {
path "/l3vpn-svc/sites/site/site-id"; path "/l3vpn-svc/sites/site/site-id";
} }
description description
"Site ID to be authorized."; "Site ID to be authorized.";
} }
} }
case permit-any-except { case permit-any-except {
leaf-list deny-site { leaf-list deny-site {
type leafref { type leafref {
path "/l3vpn-svc/sites/site/site-id"; path "/l3vpn-svc/sites/site/site-id";
} }
description description
"Site ID to be denied."; "Site ID to be denied.";
} }
} }
description description
"Choice for cloud access policy."; "Choice for cloud access policy.";
} }
container authorized-sites { container authorized-sites {
list authorized-site { list authorized-site {
key site-id; key site-id;
leaf site-id { leaf site-id {
type leafref { type leafref {
path "/l3vpn-svc/sites/site/site-id"; path "/l3vpn-svc/sites/site/site-id";
} }
description description
"Site ID."; "Site ID.";
} }
description description
"List of authorized sites."; "List of authorized sites.";
} }
description description
"Configuration of authorized sites"; "Configuration of authorized sites.";
} }
container denied-sites { container denied-sites {
list denied-site { list denied-site {
key site-id; key site-id;
leaf site-id { leaf site-id {
type leafref { type leafref {
path "/l3vpn-svc/sites/site/site-id"; path "/l3vpn-svc/sites/site/site-id";
} }
description description
"Site ID."; "Site ID.";
} }
description description
"List of denied sites."; "List of denied sites.";
} }
description description
"Configuration of denied sites"; "Configuration of denied sites.";
} }
container address-translation { container address-translation {
container nat44 { container nat44 {
leaf enabled { leaf enabled {
type boolean; type boolean;
default false; default false;
description description
"Control if "Controls whether or not address translation is required.";
address translation is required or not.";
} }
leaf nat44-customer-address { leaf nat44-customer-address {
type inet:ipv4-address; type inet:ipv4-address;
must "../enabled = 'true'" { must "../enabled = 'true'" {
description description
"Applicable only if "Applicable only if address translation is enabled.";
address translation is enabled.";
} }
description description
"Address to be used for translation. "Address to be used for translation.
This is to be used in case customer is providing This is to be used if the customer is
the address."; providing the address.";
} }
description description
"IPv4 to IPv4 translation."; "IPv4-to-IPv4 translation.";
} }
description description
"Container for NAT"; "Container for NAT.";
} }
description description
"Cloud access configuration."; "Cloud access configuration.";
} }
description description
"Container for cloud access configurations"; "Container for cloud access configurations.";
} }
description description
"grouping for vpn cloud definition"; "Grouping for VPN cloud definition.";
} }
grouping multicast-rp-group-cfg { grouping multicast-rp-group-cfg {
choice group-format { choice group-format {
case startend { case startend {
leaf group-start { leaf group-start {
type inet:ip-address; type inet:ip-address;
description description
"First group address."; "First group address.";
} }
leaf group-end { leaf group-end {
type inet:ip-address; type inet:ip-address;
description description
"Last group address."; "Last group address.";
} }
} }
case singleaddress { case singleaddress {
leaf group-address { leaf group-address {
type inet:ip-address; type inet:ip-address;
description description
"Group address"; "Group address.";
} }
} }
description description
"Choice for group format."; "Choice for group format.";
} }
description description
"Definition of groups for "Definition of groups for RP-to-group mapping.";
RP to group mapping.";
} }
grouping vpn-service-multicast { grouping vpn-service-multicast {
container multicast { container multicast {
if-feature multicast; if-feature multicast;
leaf enabled { leaf enabled {
type boolean; type boolean;
default false; default false;
description description
"Enable multicast."; "Enables multicast.";
} }
container customer-tree-flavors { container customer-tree-flavors {
leaf-list tree-flavor { leaf-list tree-flavor {
type identityref { type identityref {
base multicast-tree-type; base multicast-tree-type;
} }
description description
"Type of tree to be used."; "Type of tree to be used.";
} }
description description
skipping to change at page 114, line 43 skipping to change at page 112, line 49
leaf id { leaf id {
type uint16; type uint16;
description description
"Unique identifier for the mapping."; "Unique identifier for the mapping.";
} }
container provider-managed { container provider-managed {
leaf enabled { leaf enabled {
type boolean; type boolean;
default false; default false;
description description
"Set to true, if the RP must be a "Set to true if the RP must be a provider-managed node.
provider Set to false if it is a customer-managed node.";
managed node.
Set to false, if it is a customer
managed node.";
} }
leaf rp-redundancy { leaf rp-redundancy {
when "../enabled = 'true'" { when "../enabled = 'true'" {
description description
"Relevant when RP "Relevant when the RP is provider managed.";
is provider managed.";
} }
type boolean; type boolean;
default false; default false;
description description
"If true, redundancy "If true, a redundancy mechanism for the RP is required.";
mechanism for RP is required.";
} }
leaf optimal-traffic-delivery { leaf optimal-traffic-delivery {
when "../enabled = 'true'" { when "../enabled = 'true'" {
description description
"Relevant when RP "Relevant when the RP is provider managed.";
is provider managed.";
} }
type boolean; type boolean;
default false; default false;
description description
"If true, SP must ensure "If true, the SP must ensure that
that traffic uses an optimal path."; traffic uses an optimal path.";
} }
description description
"Parameters for provider managed RP."; "Parameters for a provider-managed RP.";
} }
leaf rp-address { leaf rp-address {
when "../provider-managed/enabled = 'false'" { when "../provider-managed/enabled = 'false'" {
description description
"Relevant when RP "Relevant when the RP is provider managed.";
is provider managed.";
} }
type inet:ip-address; type inet:ip-address;
description description
"Defines the address of the "Defines the address of the RP.
RendezvousPoint. Used if the RP is customer managed.";
Used if RP is customer managed.";
} }
container groups { container groups {
list group { list group {
key id; key id;
leaf id { leaf id {
type uint16; type uint16;
description description
"Identifier for the group."; "Identifier for the group.";
} }
uses multicast-rp-group-cfg; uses multicast-rp-group-cfg;
description description
"List of groups."; "List of groups.";
} }
description description
"Multicast groups associated with RP."; "Multicast groups associated with the RP.";
} }
description description
"List of RP to group mappings."; "List of RP-to-group mappings.";
} }
description description
"RP to group mappings."; "RP-to-group mappings.";
} }
container rp-discovery { container rp-discovery {
leaf rp-discovery-type { leaf rp-discovery-type {
type identityref { type identityref {
base multicast-rp-discovery-type; base multicast-rp-discovery-type;
} }
default static-rp; default static-rp;
description description
"Type of RP discovery used."; "Type of RP discovery used.";
} }
container bsr-candidates { container bsr-candidates {
when "../rp-discovery-type = 'bsr-rp'" { when "../rp-discovery-type = '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 BSR candidate"; "Address of BSR candidate.";
} }
description description
"Customer BSR candidates address"; "Customer BSR candidate's address.";
} }
description description
"RP discovery parameters"; "RP discovery parameters.";
} }
description description
"RendezvousPoint parameters."; "RP parameters.";
} }
description description
"Multicast global parameters for the VPN service."; "Multicast global parameters for the VPN service.";
} }
description description
"grouping for multicast vpn definition"; "Grouping for multicast VPN definition.";
} }
grouping vpn-service-mpls { grouping vpn-service-mpls {
leaf carrierscarrier { leaf carrierscarrier {
if-feature carrierscarrier; if-feature carrierscarrier;
type boolean; type boolean;
default false; default false;
description description
"The VPN is using Carrier's Carrier, "The VPN is using CsC, and so MPLS is required.";
and so MPLS is required.";
} }
description description
"grouping for mpls CsC definition"; "Grouping for MPLS CsC definition.";
} }
grouping customer-location-info { grouping customer-location-info {
container locations { container locations {
list location { list location {
key location-id; key location-id;
leaf location-id { leaf location-id {
type svc-id; type svc-id;
description description
"Identifier for a particular location"; "Identifier for a particular location.";
} }
leaf address { leaf address {
type string; type string;
description description
"Address (number and street) "Address (number and street) of the site.";
of the site.";
} }
leaf postal-code { leaf postal-code {
type string; type string;
description description
"Postal code of the site."; "Postal code of the site.";
} }
leaf state { leaf state {
type string; type string;
description description
"State of the site. "State of the site. This leaf can also be used to describe
This leaf can also be used a region for a country that does not have states.";
to describe a region
for country who does not have
states.
";
} }
leaf city { leaf city {
type string; type string;
description description
"City of the site."; "City of the site.";
} }
leaf country-code { leaf country-code {
type string { type string {
pattern '[A-Z]{2}'; pattern '[A-Z]{2}';
} }
description description
"Country of the site. "Country of the site.
Expressed as ISO Expressed as ISO ALPHA-2 code.";
ALPHA-2 code.";
} }
description description
"Location of the site."; "Location of the site.";
} }
description description
"List of locations for the site"; "List of locations for the site.";
} }
description description
"This grouping defines customer location "This grouping defines customer location parameters.";
parameters";
} }
grouping site-group { grouping site-group {
container groups { container groups {
list group { list group {
key group-id; key group-id;
leaf group-id { leaf group-id {
type string; type string;
description description
"Group-id the site "Group-id the site belongs to.";
is belonging to";
} }
description description
"List of group-id"; "List of group-ids.";
} }
description description
"Groups the site or site-network-access "Groups the site or site-network-access belongs to.";
is belonging to.";
} }
description description
"Grouping definition to assign "Grouping definition to assign
group-ids to site or site-network-access"; group-ids to site or site-network-access.";
} }
grouping site-diversity { grouping site-diversity {
container site-diversity { container site-diversity {
if-feature site-diversity; if-feature site-diversity;
uses site-group; uses site-group;
description description
"Diversity constraint type. "Diversity constraint type.
Group values defined here will be inherited All site-network-accesses will inherit the group values
to all site-network-accesses."; defined here.";
} }
description description
"This grouping defines site diversity "This grouping defines site diversity parameters.";
parameters";
} }
grouping access-diversity { grouping access-diversity {
container access-diversity { container access-diversity {
if-feature site-diversity; if-feature site-diversity;
uses site-group; uses site-group;
container constraints { container constraints {
list constraint { list constraint {
key constraint-type; key constraint-type;
skipping to change at page 119, line 43 skipping to change at page 117, line 26
} }
container target { container target {
choice target-flavor { choice target-flavor {
case id { case id {
list group { list group {
key group-id; key group-id;
leaf group-id { leaf group-id {
type string; type string;
description description
"The constraint will apply "The constraint will be applied against
against this particular this particular group-id.";
group-id";
} }
description description
"List of groups"; "List of groups.";
} }
} }
case all-accesses { case all-accesses {
leaf all-other-accesses { leaf all-other-accesses {
type empty; type empty;
description description
"The constraint will apply "The constraint will be applied against
against all other site network all other site network accesses of this site.";
access
of this site";
} }
} }
case all-groups { case all-groups {
leaf all-other-groups { leaf all-other-groups {
type empty; type empty;
description description
"The constraint will apply "The constraint will be applied against
against all other groups the all other groups managed by the customer.";
customer
is managing";
} }
} }
description description
"Choice for the group definition"; "Choice for the group definition.";
} }
description description
"The constraint will apply against "The constraint will be applied against
this list of groups"; this list of groups.";
} }
description description
"List of constraints"; "List of constraints.";
} }
description description
"Constraints for placing this site "Placement constraints for this site network access.";
network access";
} }
description description
"Diversity parameters."; "Diversity parameters.";
} }
description description
"This grouping defines access diversity "This grouping defines access diversity parameters.";
parameters";
} }
grouping operational-requirements { grouping operational-requirements {
leaf requested-site-start { leaf requested-site-start {
type yang:date-and-time; type yang:date-and-time;
description description
"Optional leaf indicating requested date "Optional leaf indicating requested date and time when the
and time service at a particular site is expected to start.";
when the service at a particular site is
expected
to start";
} }
leaf requested-site-stop { leaf requested-site-stop {
type yang:date-and-time; type yang:date-and-time;
description description
"Optional leaf indicating requested date "Optional leaf indicating requested date and time when the
and time service at a particular site is expected to stop.";
when the service at a particular site is
expected
to stop";
} }
description description
"This grouping defines some operational parameters "This grouping defines some operational parameters.";
parameters";
} }
grouping operational-requirements-ops { grouping operational-requirements-ops {
leaf actual-site-start { leaf actual-site-start {
type yang:date-and-time; type yang:date-and-time;
config false; config false;
description description
"Optional leaf indicating actual date "Optional leaf indicating actual date and time when the
and time service at a particular site actually started.";
when the service at a particular site
actually
started";
} }
leaf actual-site-stop { leaf actual-site-stop {
type yang:date-and-time; type yang:date-and-time;
config false; config false;
description description
"Optional leaf indicating actual date "Optional leaf indicating actual date and time when the
and time service at a particular site actually stopped.";
when the service at a particular site
actually
stopped";
} }
description description
"This grouping defines some operational parameters "This grouping defines some operational parameters.";
parameters";
} }
grouping flow-definition { grouping flow-definition {
container match-flow { container match-flow {
leaf dscp { leaf dscp {
type inet:dscp; type inet:dscp;
description description
"DSCP value."; "DSCP value.";
} }
leaf dot1p { leaf dot1p {
type uint8 { type uint8 {
range "0 .. 7"; range "0..7";
} }
description description
"802.1p matching."; "802.1p matching.";
} }
leaf ipv4-src-prefix { leaf ipv4-src-prefix {
type inet:ipv4-prefix; type inet:ipv4-prefix;
description description
"Match on IPv4 src address."; "Match on IPv4 src address.";
} }
leaf ipv6-src-prefix { leaf ipv6-src-prefix {
type inet:ipv6-prefix; type inet:ipv6-prefix;
description description
"Match on IPv6 src address."; "Match on IPv6 src address.";
skipping to change at page 122, line 37 skipping to change at page 119, line 47
"Match on IPv4 dst address."; "Match on IPv4 dst address.";
} }
leaf ipv6-dst-prefix { leaf ipv6-dst-prefix {
type inet:ipv6-prefix; type inet:ipv6-prefix;
description description
"Match on IPv6 dst address."; "Match on IPv6 dst address.";
} }
leaf l4-src-port { leaf l4-src-port {
type inet:port-number; type inet:port-number;
description description
"Match on layer 4 src port."; "Match on Layer 4 src port.";
} }
leaf-list target-sites { leaf-list target-sites {
type svc-id; type svc-id;
description description
"Identify a site as traffic destination."; "Identify a site as traffic destination.";
} }
container l4-src-port-range { container l4-src-port-range {
leaf lower-port { leaf lower-port {
type inet:port-number; type inet:port-number;
description description
"Lower boundary for port."; "Lower boundary for port.";
} }
leaf upper-port { leaf upper-port {
type inet:port-number; type inet:port-number;
must ". >= ../lower-port" { must ". >= ../lower-port" {
description description
"Upper boundary must be higher "Upper boundary must be higher than lower boundary.";
than lower boundary";
} }
description description
"Upper boundary for port."; "Upper boundary for port.";
} }
description description
"Match on layer 4 src port range."; "Match on Layer 4 src port range.";
} }
leaf l4-dst-port { leaf l4-dst-port {
type inet:port-number; type inet:port-number;
description description
"Match on layer 4 dst port."; "Match on Layer 4 dst port.";
} }
container l4-dst-port-range { container l4-dst-port-range {
leaf lower-port { leaf lower-port {
type inet:port-number; type inet:port-number;
description description
"Lower boundary for port."; "Lower boundary for port.";
} }
leaf upper-port { leaf upper-port {
type inet:port-number; type inet:port-number;
must ". >= ../lower-port" { must ". >= ../lower-port" {
description description
"Upper boundary must be higher "Upper boundary must be higher than lower boundary.";
than lower boundary";
} }
description description
"Upper boundary for port."; "Upper boundary for port.";
} }
description description
"Match on layer 4 dst port range."; "Match on Layer 4 dst port range.";
} }
leaf protocol-field { leaf protocol-field {
type union { type union {
type uint8; type uint8;
type identityref { type identityref {
base protocol-type; base protocol-type;
} }
} }
description description
"Match on IPv4 protocol or "Match on IPv4 protocol or IPv6 Next Header field.";
Ipv6 Next Header
field.";
} }
description description
"Describe flow matching "Describes flow-matching criteria.";
criterions.";
} }
description description
"Flow definition based on criteria."; "Flow definition based on criteria.";
} }
grouping site-service-basic { grouping site-service-basic {
leaf svc-input-bandwidth { leaf svc-input-bandwidth {
type uint32; type uint32;
units bps; units bps;
description description
"From the PE perspective, the service input "From the PE's perspective, the service input
bandwidth of the connection."; bandwidth of the connection.";
} }
leaf svc-output-bandwidth { leaf svc-output-bandwidth {
type uint32; type uint32;
units bps; units bps;
description description
"From the PE perspective, the service output "From the PE's perspective, the service output
bandwidth of the connection."; bandwidth of the connection.";
} }
leaf svc-mtu { leaf svc-mtu {
type uint16; type uint16;
units bytes; units bytes;
description description
"MTU at service level. "MTU at service level. If the service is IP,
If the service is IP,
it refers to the IP MTU."; it refers to the IP MTU.";
} }
description description
"Defines basic service parameters for a site."; "Defines basic service parameters for a site.";
} }
grouping site-protection { grouping site-protection {
container traffic-protection { container traffic-protection {
if-feature fast-reroute; if-feature fast-reroute;
leaf enabled { leaf enabled {
type boolean; type boolean;
default false; default false;
description description
"Enables "Enables traffic protection of access link.";
traffic protection of access link.";
} }
description description
"Fast reroute service parameters "Fast Reroute service parameters for the site.";
for the site.";
} }
description description
"Defines protection service parameters for a site."; "Defines protection service parameters for a site.";
} }
grouping site-service-mpls { grouping site-service-mpls {
container carrierscarrier { container carrierscarrier {
if-feature carrierscarrier; if-feature carrierscarrier;
leaf signalling-type { leaf signalling-type {
type enumeration { type enumeration {
enum "ldp" { enum "ldp" {
description description
"Use LDP as signalling "Use LDP as the signalling protocol
protocol between PE and CE."; between the PE and the CE.";
} }
enum "bgp" { enum "bgp" {
description description
"Use BGP 3107 as signalling "Use BGP (as per RFC 3107) as the signalling protocol
protocol between PE and CE. between the PE and the CE.
In this case, bgp must be also In this case, BGP must also be configured as
configured the routing protocol.";
as routing-protocol.
";
} }
} }
description description
"MPLS signalling type."; "MPLS signalling type.";
} }
description description
"This container is used when customer provides "This container is used when the customer provides
MPLS based services. MPLS-based services. This is used in the case of CsC.";
This is used in case of Carrier's
Carrier.";
} }
description description
"Defines MPLS service parameters for a site."; "Defines MPLS service parameters for a site.";
} }
grouping site-service-qos-profile { grouping site-service-qos-profile {
container qos { container qos {
if-feature qos; if-feature qos;
container qos-classification-policy { container qos-classification-policy {
list rule { list rule {
key id; key id;
skipping to change at page 126, line 14 skipping to change at page 123, line 12
choice match-type { choice match-type {
case match-flow { case match-flow {
uses flow-definition; uses flow-definition;
} }
case match-application { case match-application {
leaf match-application { leaf match-application {
type identityref { type identityref {
base customer-application; base customer-application;
} }
description description
"Defines the application "Defines the application to match.";
to match.";
} }
} }
description description
"Choice for classification"; "Choice for classification.";
} }
leaf target-class-id { leaf target-class-id {
type string; type string;
description description
"Identification of the "Identification of the class of service.
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
"Need to express marking rules ..."; "Configuration of the traffic classification policy.";
} }
container qos-profile { container qos-profile {
choice qos-profile { choice qos-profile {
description description
"Choice for QoS profile. "Choice for QoS profile.
Can be standard profile or custom."; Can be standard profile or custom.";
case standard { case standard {
leaf profile { leaf profile {
type string; type string;
description description
"QoS profile to be used"; "QoS profile to be used.";
} }
} }
case custom { case custom {
container classes { container classes {
if-feature qos-custom; if-feature qos-custom;
list class { list class {
key class-id; key class-id;
leaf class-id { leaf class-id {
type string; type string;
description description
"Identification of the "Identification of the class of service.
class of service. This identifier is internal to the administration.";
This identifier is internal to
the administration.";
} }
leaf rate-limit { leaf rate-limit {
type uint8; type uint8;
units percent; units percent;
description description
"To be used if class must "To be used if the class must be rate-limited.
be rate Expressed as percentage of the service bandwidth.";
limited. Expressed as
percentage of the svc-bw.";
} }
container latency { container latency {
choice flavor { choice flavor {
case lowest { case lowest {
leaf use-lowest-latency { leaf use-lowest-latency {
type empty; type empty;
description description
"The traffic class should use "The traffic class should use the path with the
the lowest latency path"; lowest latency.";
} }
} }
case boundary { case boundary {
leaf latency-boundary { leaf latency-boundary {
type uint16; type uint16;
units msec; units msec;
description description
"The traffic class should use "The traffic class should use a path with a
a path with a defined maximum defined maximum latency.";
latency.";
} }
} }
description description
"Latency constraint on the traffic "Latency constraint on the traffic class.";
class";
} }
description description
"Latency constraint on the traffic "Latency constraint on the traffic class.";
class";
} }
container jitter { container jitter {
choice flavor { choice flavor {
case lowest { case lowest {
leaf use-lowest-jitter { leaf use-lowest-jitter {
type empty; type empty;
description description
"The traffic class should use "The traffic class should use the path with the
the lowest jitter path"; lowest jitter.";
} }
} }
case boundary { case boundary {
leaf latency-boundary { leaf latency-boundary {
type uint32; type uint32;
units usec; units usec;
description description
"The traffic class should use "The traffic class should use a path with a
a path with a defined maximum defined maximum jitter.";
jitter.";
} }
} }
description description
"Jitter constraint on the traffic "Jitter constraint on the traffic class.";
class";
} }
description description
"Jitter constraint on the traffic "Jitter constraint on the traffic class.";
class";
} }
container bandwidth { container bandwidth {
leaf guaranteed-bw-percent { leaf guaranteed-bw-percent {
type uint8; type uint8;
units percent; units percent;
description description
"To be used to define the "To be used to define the guaranteed bandwidth
guaranteed as a percentage of the available service bandwidth.";
BW in percent of the svc-bw
available.";
} }
leaf end-to-end { leaf end-to-end {
type empty; type empty;
description description
"Used if the bandwidth reservation "Used if the bandwidth reservation
must be done on the MPLS network too"; must be done on the MPLS network too.";
} }
description description
"Bandwidth constraint on the traffic "Bandwidth constraint on the traffic class.";
class";
} }
description description
"List of class of services."; "List of classes of services.";
} }
description description
"Container for "Container for list of classes of services.";
list of class of services.";
} }
} }
} }
description description
"Qos profile configuration."; "QoS profile configuration.";
} }
description description
"QoS configuration."; "QoS configuration.";
} }
description description
"This grouping defines QoS parameters "This grouping defines QoS parameters for a site.";
for a site";
} }
grouping site-security-authentication { grouping site-security-authentication {
container authentication { container authentication {
description description
"Authentication parameters"; "Authentication parameters.";
} }
description description
"This grouping defines authentication "This grouping defines authentication parameters for a site.";
parameters
for a site";
} }
grouping site-security-encryption { grouping site-security-encryption {
container encryption { container encryption {
if-feature encryption; if-feature encryption;
leaf enabled { leaf enabled {
type boolean; type boolean;
default false; default false;
description description
"If true, access encryption is required."; "If true, access encryption is required.";
} }
leaf layer { leaf layer {
type enumeration { type enumeration {
enum layer2 { enum layer2 {
description description
"Encryption will occur at layer 2."; "Encryption will occur at Layer 2.";
} }
enum layer3 { enum layer3 {
description description
"Encryption will occur at layer 3. "Encryption will occur at Layer 3.
IPSec may be used as example."; For example, IPsec may be used.";
} }
} }
mandatory true; mandatory true;
description description
"Layer on which encryption is applied."; "Layer on which encryption is applied.";
} }
container encryption-profile { container encryption-profile {
choice profile { choice profile {
case provider-profile { case provider-profile {
leaf profile-name { leaf profile-name {
type string; type string;
description description
"Name of the SP profile "Name of the SP profile to be applied.";
to be applied.";
} }
} }
case customer-profile { case customer-profile {
leaf algorithm { leaf algorithm {
type string; type string;
description description
"Encryption algorithm to "Encryption algorithm to be used.";
be used.";
} }
choice key-type { choice key-type {
case psk { case psk {
leaf preshared-key { leaf preshared-key {
type string; type string;
description description
"Key coming from "Key coming from customer.";
customer.";
} }
} }
case pki { case pki {
} }
description description
"Type of keys to be used."; "Type of keys to be used.";
} }
} }
description description
"Choice of profile."; "Choice of profile.";
} }
description description
"Profile of encryption to be applied."; "Profile of encryption to be applied.";
} }
description description
"Encryption parameters."; "Encryption parameters.";
} }
description description
"This grouping defines encryption parameters "This grouping defines encryption parameters for a site.";
for a site";
} }
grouping site-attachment-bearer { grouping site-attachment-bearer {
container bearer { container bearer {
container requested-type { container requested-type {
if-feature requested-type; if-feature requested-type;
leaf requested-type { leaf requested-type {
type string; type string;
description description
"Type of requested bearer Ethernet, DSL, "Type of requested bearer: Ethernet, DSL,
Wireless ... Wireless, etc. Operator specific.";
Operator specific.";
} }
leaf strict { leaf strict {
type boolean; type boolean;
default false; default false;
description description
"define if the requested-type is a preference "Defines whether 'requested-type' is a preference
or a strict requirement."; or a strict requirement.";
} }
description description
"Container for requested type."; "Container for 'requested-type'.";
} }
leaf always-on { leaf always-on {
if-feature always-on; if-feature always-on;
type boolean; type boolean;
default true; default true;
description description
"Request for an always on access type. "Request for an 'always-on' access type.
This means no Dial access type for For example, this could mean 'no dial access type'.";
example.";
} }
leaf bearer-reference { leaf bearer-reference {
if-feature bearer-reference; if-feature bearer-reference;
type string; type string;
description description
"This is an internal reference for the "This is an internal reference for the SP.";
service provider.
Used ";
} }
description description
"Bearer specific parameters. "Bearer-specific parameters.
To be augmented."; To be augmented.";
} }
description description
"Defines physical properties of "Defines physical properties of a site attachment.";
a site attachment.";
} }
grouping site-routing { grouping site-routing {
container routing-protocols { container routing-protocols {
list routing-protocol { list routing-protocol {
key type; key type;
leaf type { leaf type {
type identityref { type identityref {
base routing-protocol-type; base routing-protocol-type;
} }
description description
"Type of routing protocol."; "Type of routing protocol.";
} }
container ospf { container ospf {
when "../type = 'ospf'" { when "../type = 'ospf'" {
description description
"Only applies "Only applies when protocol is OSPF.";
when protocol is OSPF.";
} }
if-feature rtg-ospf; if-feature rtg-ospf;
leaf-list address-family { leaf-list address-family {
type address-family; type address-family;
description description
"Address family to be activated."; "Address family to be activated.";
} }
leaf area-address { leaf area-address {
type yang:dotted-quad; type yang:dotted-quad;
description description
"Area address."; "Area address.";
} }
leaf metric { leaf metric {
type uint16; type uint16;
skipping to change at page 132, line 50 skipping to change at page 129, line 15
"Address family to be activated."; "Address family to be activated.";
} }
leaf area-address { leaf area-address {
type yang:dotted-quad; type yang:dotted-quad;
description description
"Area address."; "Area address.";
} }
leaf metric { leaf metric {
type uint16; type uint16;
description description
"Metric of PE-CE link."; "Metric of the PE-CE link.";
} }
container sham-links { container sham-links {
if-feature rtg-ospf-sham-link; if-feature rtg-ospf-sham-link;
list sham-link { list sham-link {
key target-site; key target-site;
leaf target-site { leaf target-site {
type svc-id; type svc-id;
description description
"Target site for the sham link "Target site for the sham link connection.
connection. The site is referred to by its ID.";
The site is referred through it's ID.";
} }
leaf metric { leaf metric {
type uint16; type uint16;
description description
"Metric of the sham link."; "Metric of the sham link.";
} }
description description
"Creates a shamlink with another "Creates a sham link with another site.";
site";
} }
description description
"List of Sham links"; "List of sham links.";
} }
description description
"OSPF specific configuration."; "OSPF-specific configuration.";
} }
container bgp { container bgp {
when "../type = 'bgp'" { when "../type = 'bgp'" {
description description
"Only applies when "Only applies when protocol is BGP.";
protocol is BGP.";
} }
if-feature rtg-bgp; if-feature rtg-bgp;
leaf autonomous-system { leaf autonomous-system {
type uint32; type uint32;
description description
"AS number."; "AS number.";
} }
leaf-list address-family { leaf-list address-family {
type address-family; type address-family;
description description
"Address family to be activated."; "Address family to be activated.";
} }
description description
"BGP specific configuration."; "BGP-specific configuration.";
} }
container static { container static {
when "../type = 'static'" { when "../type = 'static'" {
description description
"Only applies when protocol "Only applies when protocol is static.";
is static.";
} }
container cascaded-lan-prefixes { container cascaded-lan-prefixes {
list ipv4-lan-prefixes { list ipv4-lan-prefixes {
if-feature ipv4; if-feature ipv4;
key "lan next-hop"; key "lan next-hop";
leaf lan { leaf lan {
type inet:ipv4-prefix; type inet:ipv4-prefix;
description description
"Lan prefixes."; "LAN prefixes.";
} }
leaf lan-tag { leaf lan-tag {
type string; type string;
description description
"Internal tag to be used in vpn "Internal tag to be used in VPN policies.";
policies.";
} }
leaf next-hop { leaf next-hop {
type inet:ipv4-address; type inet:ipv4-address;
description description
"Nexthop address to use at customer "Next-hop address to use on the customer side.";
side.";
} }
description " description
List of LAN prefixes for "List of LAN prefixes for the site.";
the site.
";
} }
list ipv6-lan-prefixes { list ipv6-lan-prefixes {
if-feature ipv6; if-feature ipv6;
key "lan next-hop"; key "lan next-hop";
leaf lan { leaf lan {
type inet:ipv6-prefix; type inet:ipv6-prefix;
description description
"Lan prefixes."; "LAN prefixes.";
} }
leaf lan-tag { leaf lan-tag {
type string; type string;
description description
"Internal tag to be used "Internal tag to be used in VPN policies.";
in vpn policies.";
} }
leaf next-hop { leaf next-hop {
type inet:ipv6-address; type inet:ipv6-address;
description description
"Nexthop address to use at "Next-hop address to use on the customer side.";
customer side.";
} }
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
"Static routing "Configuration specific to static routing.";
specific configuration.";
} }
container rip { container rip {
when "../type = 'rip'" { when "../type = 'rip'" {
description description
"Only applies when "Only applies when protocol is RIP.";
protocol is RIP.";
} }
if-feature rtg-rip; if-feature rtg-rip;
leaf-list address-family { leaf-list address-family {
type address-family; type address-family;
description description
"Address family to be "Address family to be activated.";
activated.";
} }
description description
"RIP routing specific "Configuration specific to RIP routing.";
configuration.";
} }
container vrrp { container vrrp {
when "../type = 'vrrp'" { when "../type = 'vrrp'" {
description description
"Only applies when "Only applies when protocol is VRRP.";
protocol is VRRP.";
} }
if-feature rtg-vrrp; if-feature rtg-vrrp;
leaf-list address-family { leaf-list address-family {
type address-family; type address-family;
description description
"Address family to be activated."; "Address family to be activated.";
} }
description description
"VRRP routing specific configuration."; "Configuration specific to VRRP routing.";
} }
description description
"List of routing protocols used "List of routing protocols used on
on the site. the site. This list can be augmented.";
Need to be augmented.";
} }
description description
"Defines routing protocols."; "Defines routing protocols.";
} }
description description
"Grouping for routing protocols."; "Grouping for routing protocols.";
} }
grouping site-attachment-ip-connection { grouping site-attachment-ip-connection {
container ip-connection { container ip-connection {
container ipv4 { container ipv4 {
if-feature ipv4; if-feature ipv4;
leaf address-allocation-type { leaf address-allocation-type {
type identityref { type identityref {
base address-allocation-type; base address-allocation-type;
} }
default "static-address"; default "static-address";
description description
"Defines how addresses are allocated. "Defines how addresses are allocated.";
";
} }
leaf number-of-dynamic-address { leaf number-of-dynamic-address {
when when "../address-allocation-type = 'provider-dhcp'" {
"../address-allocation-type = 'provider-dhcp'"
{
description description
"Only applies when "Only applies when addresses are allocated by DHCP.";
addresses are dhcp allocated";
} }
type uint8; type uint8;
default 1; default 1;
description description
"Describes the number of IP addresses the "Describes the number of IP addresses the customer requires.";
customer requires";
} }
container dhcp-relay { container dhcp-relay {
when when "../address-allocation-type = 'provider-dhcp-relay'" {
"../address-allocation-type = 'provider-dhcp-relay'"
{
description description
"Only applies when "Only applies when provider is required to implement
provider is required to implementations DHCP relay function.";
DHCP relay function";
} }
container customer-dhcp-servers { container customer-dhcp-servers {
leaf-list server-ip-address { leaf-list server-ip-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"IP address of customer DHCP server"; "IP address of customer DHCP server.";
} }
description description
"Container for list of customer DHCP server"; "Container for list of customer DHCP servers.";
} }
description description
"DHCP relay provided by operator."; "DHCP relay provided by operator.";
} }
container addresses { container addresses {
when when "../address-allocation-type = 'static-address'" {
"../address-allocation-type = 'static-address'" {
description description
"Only applies when "Only applies when protocol allocation type is static.";
protocol allocation type is static";
} }
leaf provider-address { leaf provider-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"Provider side address."; "Address of provider side.";
} }
leaf customer-address { leaf customer-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"Customer side address."; "Address of customer side.";
} }
leaf mask { leaf mask {
type uint8 { type uint8 {
range "0..31"; range "0..31";
} }
description description
"Subnet mask expressed "Subnet mask expressed in bits.";
in bits";
} }
description description
"Describes IP addresses used"; "Describes IP addresses used.";
} }
description description
"IPv4 specific parameters"; "IPv4-specific parameters.";
} }
container ipv6 { container ipv6 {
if-feature ipv6; if-feature ipv6;
leaf address-allocation-type { leaf address-allocation-type {
type identityref { type identityref {
base address-allocation-type; base address-allocation-type;
} }
default "static-address"; default "static-address";
description description
"Defines how addresses are allocated. "Defines how addresses are allocated.";
";
} }
leaf number-of-dynamic-address { leaf number-of-dynamic-address {
when when
"../address-allocation-type = 'provider-dhcp' "+ "../address-allocation-type = 'provider-dhcp' "+
"or ../address-allocation-type "+ "or ../address-allocation-type "+
"= 'provider-dhcp-slaac'" { "= 'provider-dhcp-slaac'" {
description description
"Only applies when "Only applies when addresses are allocated by DHCP.";
addresses are dhcp allocated";
} }
type uint8; type uint8;
default 1; default 1;
description description
"Describes the number of IP addresses the "Describes the number of IP addresses the customer requires.";
customer requires";
} }
container dhcp-relay { container dhcp-relay {
when when "../address-allocation-type = 'provider-dhcp-relay'" {
"../address-allocation-type = 'provider-dhcp-relay'"
{
description description
"Only applies when "Only applies when provider is required to implement
provider is required to implementations DHCP relay function.";
DHCP relay function";
} }
container customer-dhcp-servers { container customer-dhcp-servers {
leaf-list server-ip-address { leaf-list server-ip-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"IP address of customer DHCP server"; "IP address of customer DHCP server.";
} }
description description
"Container for list of customer DHCP server"; "Container for list of customer DHCP servers.";
} }
description description
"DHCP relay provided by operator."; "DHCP relay provided by operator.";
} }
container addresses { container addresses {
when when "../address-allocation-type = 'static-address'" {
"../address-allocation-type = 'static-address'" {
description description
"Only applies when "Only applies when protocol allocation type is static.";
protocol allocation type is static";
} }
leaf provider-address { leaf provider-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"Provider side address."; "Address of provider side.";
} }
leaf customer-address { leaf customer-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"Customer side address."; "Address of customer side.";
} }
leaf mask { leaf mask {
type uint8 { type uint8 {
range "0..127"; range "0..127";
} }
description description
"Subnet mask expressed "Subnet mask expressed in bits.";
in bits";
} }
description description
"Describes IP addresses used"; "Describes IP addresses used.";
} }
description description
"IPv6 specific parameters"; "IPv6-specific parameters.";
} }
container oam { container oam {
container bfd { container bfd {
if-feature bfd; if-feature bfd;
leaf enabled { leaf enabled {
type boolean; type boolean;
default false; default false;
description description
"BFD activation"; "BFD activation.";
} }
choice holdtime { choice holdtime {
case profile { case profile {
leaf profile-name { leaf profile-name {
type string; type string;
description description
"Service provider well "Well-known SP profile.";
known profile.";
} }
description description
"Service provider well "Well-known SP profile.";
known profile.";
} }
case fixed { case fixed {
leaf fixed-value { leaf fixed-value {
type uint32; type uint32;
units msec; units msec;
description description
"Expected holdtime "Expected holdtime expressed in msec.";
expressed
in msec.";
} }
} }
description description
"Choice for holdtime flavor."; "Choice for holdtime flavor.";
} }
description description
"Container for BFD."; "Container for BFD.";
} }
description description
"Define the OAM used on the connection."; "Defines the OAM mechanisms used on the connection.";
} }
description description
"Defines connection parameters."; "Defines connection parameters.";
} }
description description
"This grouping defines IP connection parameters."; "This grouping defines IP connection parameters.";
} }
grouping site-service-multicast { grouping site-service-multicast {
container multicast { container multicast {
if-feature multicast; if-feature multicast;
leaf multicast-site-type { leaf multicast-site-type {
type enumeration { type enumeration {
enum receiver-only { enum receiver-only {
description description
"The site has only receivers."; "The site only has receivers.";
} }
enum source-only { enum source-only {
description description
"The site has only sources."; "The site only has sources.";
} }
enum source-receiver { enum source-receiver {
description description
"The site has both "The site has both sources and receivers.";
sources & receivers.";
} }
} }
default "source-receiver"; default "source-receiver";
description description
"Type of multicast site."; "Type of multicast site.";
} }
container multicast-address-family { container multicast-address-family {
leaf ipv4 { leaf ipv4 {
if-feature ipv4; if-feature ipv4;
type boolean; type boolean;
default true; default true;
description description
"Enables ipv4 multicast"; "Enables IPv4 multicast.";
} }
leaf ipv6 { leaf ipv6 {
if-feature ipv6; if-feature ipv6;
type boolean; type boolean;
default false; default false;
description description
"Enables ipv6 multicast"; "Enables IPv6 multicast.";
} }
description description
"Defines protocol to carry multicast."; "Defines protocol to carry multicast.";
} }
leaf protocol-type { leaf protocol-type {
type enumeration { type enumeration {
enum host { enum host {
description description
" "Hosts are directly connected to the provider network.
Hosts are directly connected Host protocols such as IGMP or MLD are required.";
to the provider network.
Host protocols like IGMP, MLD
are required.
";
} }
enum router { enum router {
description description
" "Hosts are behind a customer router.
Hosts are behind a customer router. PIM will be implemented.";
PIM will be implemented.
";
} }
enum both { enum both {
description description
"Some Hosts are behind a customer "Some hosts are behind a customer router, and some others
router and some others are directly are directly connected to the provider network.
connected to the provider network. Both host and routing protocols must be used.
Both host and routing protocols must be Typically, IGMP and PIM will be implemented.";
used. Typically IGMP and PIM will be
implemented.
";
} }
} }
default "both"; default "both";
description description
"Multicast protocol type to be used "Multicast protocol type to be used with the customer site.";
with the customer site.";
} }
description description
"Multicast parameters for the site."; "Multicast parameters for the site.";
} }
description description
"Multicast parameters for the site."; "Multicast parameters for the site.";
} }
grouping site-management { grouping site-management {
container management { container management {
leaf type { leaf type {
type identityref { type identityref {
base management; base management;
} }
description description
"Management type of the connection."; "Management type of the connection.";
} }
description description
"Management configuration"; "Management configuration.";
} }
description description
"Management parameters for the site."; "Management parameters for the site.";
} }
grouping site-devices { grouping site-devices {
container devices { container devices {
must "/l3vpn-svc/sites/site/management/type = "+ must "/l3vpn-svc/sites/site/management/type = "+
"'provider-managed' or "+ "'provider-managed' or "+
"/l3vpn-svc/sites/site/management/type ="+ "/l3vpn-svc/sites/site/management/type = "+
"'co-managed'" { "'co-managed'" {
description description
"Applicable only for provider-managed or "Applicable only for provider-managed or co-managed device.";
co-managed device";
} }
list device { list device {
key device-id; key device-id;
leaf device-id { leaf device-id {
type svc-id; type svc-id;
description description
"identifier for the device"; "Identifier for the device.";
} }
leaf location { leaf location {
type leafref { type leafref {
path "/l3vpn-svc/sites/site/locations/"+ path "/l3vpn-svc/sites/site/locations/"+
"location/location-id"; "location/location-id";
} }
description description
"Location of the device"; "Location of the device.";
} }
container management { container management {
must "/l3vpn-svc/sites/site/management/type"+ must "/l3vpn-svc/sites/site/management/type"+
"= 'co-managed'" { "= 'co-managed'" {
description description
"Applicable only for "Applicable only for co-managed device.";
co-managed device";
} }
leaf address-family { leaf address-family {
type address-family; type address-family;
description description
"Address family used for management."; "Address family used for management.";
} }
leaf address { leaf address {
type inet:ip-address; type inet:ip-address;
description description
"Management address"; "Management address.";
} }
description description
"Management configuration. Only for "Management configuration. Applicable only for
co-managed case."; co-managed device.";
} }
description description
"Device configuration"; "Device configuration.";
} }
description description
"List of devices requested by customer"; "List of devices requested by customer.";
} }
description description
"Grouping for device allocation"; "Grouping for device allocation.";
} }
grouping site-vpn-flavor { grouping site-vpn-flavor {
leaf site-vpn-flavor { leaf site-vpn-flavor {
type identityref { type identityref {
base site-vpn-flavor; base site-vpn-flavor;
} }
default site-vpn-flavor-single; default site-vpn-flavor-single;
description description
"Defines if the site "Defines whether the site is, for example,
is a single VPN site, or multiVPN or ..."; a single VPN site or a multiVPN.";
} }
description description
"Grouping for site-vpn-flavor."; "Grouping for site VPN flavor.";
} }
grouping site-vpn-policy { grouping site-vpn-policy {
container vpn-policies { container vpn-policies {
list vpn-policy { list vpn-policy {
key vpn-policy-id; key vpn-policy-id;
leaf vpn-policy-id { leaf vpn-policy-id {
type svc-id; type svc-id;
description description
"Unique identifier for "Unique identifier for the VPN policy.";
the VPN policy.";
} }
list entries { list entries {
key id; key id;
leaf id { leaf id {
type svc-id; type svc-id;
description description
"Unique identifier for "Unique identifier for the policy entry.";
the policy entry.";
} }
container filter { container filter {
choice lan { choice lan {
case prefixes { case prefixes {
leaf-list ipv4-lan-prefix { leaf-list ipv4-lan-prefix {
if-feature ipv4; if-feature ipv4;
type inet:ipv4-prefix; type inet:ipv4-prefix;
description description
"List of IPv4 prefixes to be "List of IPv4 prefixes to be matched.";
matched.";
} }
leaf-list ipv6-lan-prefix { leaf-list ipv6-lan-prefix {
if-feature ipv6; if-feature ipv6;
type inet:ipv6-prefix; type inet:ipv6-prefix;
description description
"List of IPv6 prefixes to be "List of IPv6 prefixes to be matched.";
matched.";
} }
} }
case lan-tag { case lan-tag {
leaf-list lan-tag { leaf-list lan-tag {
type string; type string;
description description
"List of lan-tags to be matched."; "List of 'lan-tag' items to be matched.";
} }
} }
description description
"Choice for LAN matching type"; "Choice of ways to do LAN matching.";
} }
description description
"If used, it permit to split site LANs "If used, it permits the splitting of
among multiple VPNs. site LANs among multiple VPNs.
If no filter used, all the LANs will be If no filter is used, all the LANs will be
part of the same VPNs with the same part of the same VPNs with the same role.";
role.";
} }
container vpn { container vpn {
leaf vpn-id { leaf vpn-id {
type leafref { type leafref {
path "/l3vpn-svc/vpn-services/" path "/l3vpn-svc/vpn-services/"+
+"vpn-service/vpn-id"; "vpn-service/vpn-id";
} }
mandatory true; mandatory true;
description description
"Reference to an IPVPN."; "Reference to an IP VPN.";
} }
leaf site-role { leaf site-role {
type identityref { type identityref {
base site-role; base site-role;
} }
default any-to-any-role; default any-to-any-role;
description description
"Role of the site in the IPVPN."; "Role of the site in the IP VPN.";
} }
description description
"List of VPNs the LAN is associated to."; "List of VPNs the LAN is associated with.";
} }
description description
"List of entries for export policy."; "List of entries for export policy.";
} }
description description
"List of VPN policies."; "List of VPN policies.";
} }
description description
"VPN policy."; "VPN policy.";
} }
description description
"VPN policy parameters for the site."; "VPN policy parameters for the site.";
} }
grouping site-maximum-routes { grouping site-maximum-routes {
container maximum-routes { container maximum-routes {
list address-family { list address-family {
key af; key af;
leaf af { leaf af {
type address-family; type address-family;
description description
"Address-family."; "Address family.";
} }
leaf maximum-routes { leaf maximum-routes {
type uint32; type uint32;
description description
"Maximum prefixes the VRF can "Maximum prefixes the VRF can accept for this address family.";
accept for this
address-family.";
} }
description description
"List of address families."; "List of address families.";
} }
description description
"Define maximum-routes for the VRF."; "Defines 'maximum-routes' for the VRF.";
} }
description description
"Define maximum-routes for the site."; "Defines 'maximum-routes' for the site.";
} }
grouping site-security { grouping site-security {
container security { container security {
uses site-security-authentication; uses site-security-authentication;
uses site-security-encryption; uses site-security-encryption;
description description
"Site specific security parameters."; "Site-specific security parameters.";
} }
description description
"Grouping for security parameters."; "Grouping for security parameters.";
} }
grouping site-service { grouping site-service {
container service { container service {
uses site-service-qos-profile; uses site-service-qos-profile;
uses site-service-mpls; uses site-service-mpls;
uses site-service-multicast; uses site-service-multicast;
description description
"Service parameters on the attachement."; "Service parameters on the attachment.";
} }
description description
"Grouping for service parameters."; "Grouping for service parameters.";
} }
grouping site-network-access-service { grouping site-network-access-service {
container service { container service {
uses site-service-basic; uses site-service-basic;
uses site-service-qos-profile; uses site-service-qos-profile;
uses site-service-mpls; uses site-service-mpls;
uses site-service-multicast; uses site-service-multicast;
description description
"Service parameters on the attachement."; "Service parameters on the attachment.";
} }
description description
"Grouping for service parameters."; "Grouping for service parameters.";
} }
grouping vpn-extranet { grouping vpn-extranet {
container extranet-vpns { container extranet-vpns {
if-feature extranet-vpn; if-feature extranet-vpn;
list extranet-vpn { list extranet-vpn {
key vpn-id; key vpn-id;
leaf vpn-id { leaf vpn-id {
type svc-id; type svc-id;
description description
"Identifies the target VPN"; "Identifies the target VPN.";
} }
leaf local-sites-role { leaf local-sites-role {
type identityref { type identityref {
base site-role; base site-role;
} }
default any-to-any-role; default 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."; local sites in the target VPN topology.";
} }
description description
"List of extranet VPNs the local "List of extranet VPNs the local VPN is attached to.";
VPN is attached to.";
} }
description description
"Container for extranet vpn cfg."; "Container for extranet VPN configuration.";
} }
description description
"grouping for extranet VPN configuration. "Grouping for extranet VPN configuration.
Extranet provides a way to interconnect all sites This provides an easy way to interconnect
from two VPNs in a easy way."; all sites from two VPNs.";
} }
grouping site-attachment-availability { grouping site-attachment-availability {
container availability { container availability {
leaf access-priority { leaf access-priority {
type uint32; type uint32;
default 1; default 1;
description description
"Defines the priority for the access. "Defines the priority for the access.
The highest the priority value is, The higher the 'access-priority' value,
the highest the the higher the preference of the access will be.";
preference of the access is.";
} }
description description
"Availability parameters "Availability parameters (used for multihoming).";
(used for multihoming)";
} }
description description
"Defines site availability parameters."; "Defines availability parameters for a site.";
} }
grouping access-vpn-policy { grouping access-vpn-policy {
container vpn-attachment { container vpn-attachment {
choice attachment-flavor { choice attachment-flavor {
case vpn-policy-id { case vpn-policy-id {
leaf vpn-policy-id { leaf vpn-policy-id {
type leafref { type leafref {
path "/l3vpn-svc/sites/site/"+ path "/l3vpn-svc/sites/site/"+
skipping to change at page 149, line 30 skipping to change at page 144, line 21
} }
description description
"Reference to a VPN."; "Reference to a VPN.";
} }
leaf site-role { leaf site-role {
type identityref { type identityref {
base site-role; base site-role;
} }
default any-to-any-role; default any-to-any-role;
description description
"Role of the site in the IPVPN."; "Role of the site in the IP VPN.";
} }
} }
mandatory true; mandatory true;
description description
"Choice for VPN attachment flavor."; "Choice for VPN attachment flavor.";
} }
description description
"Defines VPN attachment of a site."; "Defines VPN attachment of a site.";
} }
description description
"Defines the VPN attachment rules "Defines the VPN attachment rules for a site's logical access.";
for a site logical access.";
} }
grouping vpn-svc-cfg { grouping vpn-svc-cfg {
leaf vpn-id { leaf vpn-id {
type svc-id; type svc-id;
description description
"VPN identifier. Local administration meaning."; "VPN identifier. Local administration meaning.";
} }
leaf customer-name { leaf customer-name {
type string; type string;
description description
"Name of the customer."; "Name of the customer.";
} }
leaf vpn-service-topology { leaf vpn-service-topology {
type identityref { type identityref {
base vpn-topology; base vpn-topology;
} }
skipping to change at page 150, line 15 skipping to change at page 145, line 4
description description
"Name of the customer."; "Name of the customer.";
} }
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.";
} }
uses vpn-service-cloud-access; uses vpn-service-cloud-access;
uses vpn-service-multicast; uses vpn-service-multicast;
uses vpn-service-mpls; uses vpn-service-mpls;
uses vpn-extranet; uses vpn-extranet;
description description
"grouping for vpn-svc configuration."; "Grouping for VPN service configuration.";
} }
grouping site-top-level-cfg { grouping site-top-level-cfg {
uses operational-requirements; uses operational-requirements;
uses customer-location-info; uses customer-location-info;
uses site-devices; uses site-devices;
uses site-diversity; uses site-diversity;
uses site-management; uses site-management;
uses site-vpn-policy; uses site-vpn-policy;
uses site-vpn-flavor; uses site-vpn-flavor;
uses site-maximum-routes; uses site-maximum-routes;
uses site-security; uses site-security;
uses site-service; uses site-service;
uses site-protection; uses site-protection;
uses site-routing; uses site-routing;
description description
"Grouping for site top level cfg."; "Grouping for site top-level configuration.";
} }
grouping site-network-access-top-level-cfg { grouping site-network-access-top-level-cfg {
leaf site-network-access-type { leaf site-network-access-type {
type identityref { type identityref {
base site-network-access-type; base site-network-access-type;
} }
default "point-to-point"; default "point-to-point";
description description
"Describes the type of connection, e.g. : "Describes the type of connection, e.g.,
point-to-point or multipoint"; point-to-point or multipoint.";
} }
choice location-flavor { choice location-flavor {
case location { case location {
when "/l3vpn-svc/sites/site/management/type = "+ when "/l3vpn-svc/sites/site/management/type = "+
"'customer-managed'" { "'customer-managed'" {
description description
"Applicable only for customer-managed"; "Applicable only for customer-managed device.";
} }
leaf location-reference { leaf location-reference {
type leafref { type leafref {
path "/l3vpn-svc/sites/site/locations/"+ path "/l3vpn-svc/sites/site/locations/"+
"location/location-id"; "location/location-id";
} }
description description
"Location of the site-network-access"; "Location of the site-network-access.";
} }
} }
case device { case device {
when "/l3vpn-svc/sites/site/management/type = "+ when "/l3vpn-svc/sites/site/management/type = "+
"'provider-managed' or "+ "'provider-managed' or "+
"/l3vpn-svc/sites/site/management/type = "+ "/l3vpn-svc/sites/site/management/type = "+
"'co-managed'" { "'co-managed'" {
description description
"Applicable only for provider-managed or "Applicable only for provider-managed or co-managed device.";
co-managed device";
} }
leaf device-reference { leaf device-reference {
type leafref { type leafref {
path "/l3vpn-svc/sites/site/devices/"+ path "/l3vpn-svc/sites/site/devices/"+
"device/device-id"; "device/device-id";
} }
description description
"Identifier of CE to use"; "Identifier of CE to use.";
} }
} }
mandatory true; mandatory true;
description description
"Choice on how to describe the site location"; "Choice of how to describe the site's location.";
} }
uses access-diversity; uses access-diversity;
uses site-attachment-bearer; uses site-attachment-bearer;
uses site-attachment-ip-connection; uses site-attachment-ip-connection;
uses site-security; uses site-security;
uses site-network-access-service; uses site-network-access-service;
uses site-routing; uses site-routing;
uses site-attachment-availability; uses site-attachment-availability;
uses access-vpn-policy; uses access-vpn-policy;
description description
"Grouping for site network access "Grouping for site network access top-level configuration.";
top level cfg.";
} }
/* Main blocks */ /* Main blocks */
container l3vpn-svc { container l3vpn-svc {
container vpn-services { container vpn-services {
list vpn-service { list vpn-service {
key vpn-id; key vpn-id;
uses vpn-svc-cfg; uses vpn-svc-cfg;
description " description
List of VPN services. "List of VPN services.";
";
} }
description description
"top level container "Top-level container for the VPN services.";
for the VPN services.";
} }
container sites { container sites {
list site { list site {
key site-id; key site-id;
leaf site-id { leaf site-id {
type svc-id; type svc-id;
description description
"Identifier of the site."; "Identifier of the site.";
skipping to change at page 152, line 49 skipping to change at page 147, line 33
uses site-top-level-cfg; uses site-top-level-cfg;
uses operational-requirements-ops; uses operational-requirements-ops;
container site-network-accesses { container site-network-accesses {
list site-network-access { list site-network-access {
key site-network-access-id; key site-network-access-id;
leaf site-network-access-id { leaf site-network-access-id {
type svc-id; type svc-id;
description description
"Identifier for the access"; "Identifier for the access.";
} }
uses site-network-access-top-level-cfg; uses site-network-access-top-level-cfg;
description description
"List of accesses for a site."; "List of accesses for a site.";
} }
description description
"List of accesses for a site."; "List of accesses for a site.";
} }
description "List of sites."; description
"List of sites.";
} }
description description
"Container for sites"; "Container for sites.";
} }
description description
"Main container for L3VPN service configuration."; "Main container for L3VPN service configuration.";
} }
} }
<CODE ENDS> <CODE ENDS>
10. Security Considerations 10. Security Considerations
The YANG modules defined in this document MAY be accessed via the The YANG module defined in this document MAY be accessed via the
RESTCONF protocol [I-D.ietf-netconf-restconf] or NETCONF protocol RESTCONF protocol [RFC8040] or the NETCONF protocol [RFC6241]. The
([RFC6241]. The lowest RESTCONF or NETCONF layer requires that the lowest RESTCONF or NETCONF layer requires that the transport-layer
transport-layer protocol provides both data integrity and protocol provide both data integrity and confidentiality; see
confidentiality, see Section 2 in [I-D.ietf-netconf-restconf] and Section 2 in [RFC8040] and Section 2 in [RFC6241]. The client MUST
[RFC6241]. The client MUST carefully examine the certificate carefully examine the certificate presented by the server to
presented by the server to determine if it meets the client's determine if it meets the client's expectations, and the server MUST
expectations, and the server MUST authenticate client access to any authenticate client access to any protected resource. The client
protected resource. The client identity derived from the identity derived from the authentication mechanism used is subject to
authentication mechanism used is subject to the NETCONF Access the NETCONF Access Control Model (NACM) [RFC6536]. Other protocols
Control Module (NACM) ([RFC6536]). Other protocols to access this that are used to access this YANG module are also required to support
YANG module are also required to support the similar mechanism. similar security mechanisms.
The data nodes defined in the "ietf-l3vpn-svc" YANG module MUST be The data nodes defined in the "ietf-l3vpn-svc" YANG module MUST be
carefully created/read/updated/deleted. The entries in the lists carefully created, read, updated, or deleted as appropriate. The
below include customer proprietary or confidential information, entries in the lists below include customer-proprietary or
therefore only authorized clients MUST access the information and the confidential information; therefore, access to confidential
other clients MUST NOT be able to access the information. information MUST be limited to authorized clients, and other clients
MUST NOT be permitted to access the information.
o /l3vpn-svc/vpn-services/vpn-service o /l3vpn-svc/vpn-services/vpn-service
o /l3vpn-svc/sites/site o /l3vpn-svc/sites/site
The data model proposes some security parameters than can be extended The data model proposes some security parameters than can be extended
by augmentation as part of the customer service request: those via augmentation as part of the customer service request; those
parameters are described in Section 6.9. parameters are described in Section 6.9.
11. Contribution 11. IANA Considerations
Authors would like to thank Rob Shakir for his major contribution on
the initial modeling and use cases.
12. Acknowledgements
Thanks to Qin Wu, Maxim Klyus, Luis Miguel Contreras, Gregory Mirsky,
Zitao Wang, Jing Zhao, Kireeti Kompella, Eric Rosen, Aijun Wang,
Michael Scharf, Xufeng Liu, David Ball, Lucy Yong, Jean-Philippe
Landry and Andrew Leu for the contributions to the document.
13. IANA Considerations
IANA is requested to assign a new URI from the IETF XML registry
([RFC3688]). Authors are suggesting the following URI:
ID: yang:ietf-l3vpn-svc
URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]
Registrant Contact: L3SM WG
XML: N/A, the requested URI is an XML namespace
This document also requests a new YANG module name in the YANG Module
Names registry ([RFC7950]) with the following suggestion:
Name: ietf-l3vpn-svc
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
Prefix: l3vpn-svc
Module:
Reference: [ RFC-to-be ]
14. Change Log
14.1. Changes between versions -18 and-19
o Country code string pattern enforced to ISO ALPHA-2 code.
o zip-code renamed to postal-code.
o Added new address-allocation-type: provider-dhcp-slaac.
o Removed transport-constraints and include transport constraints
(jitter,latency, bandwidth) in the qos-profile.
o qos-profile simplified with more abstraction.
o added target-sites in flow-definition.
14.2. Changes between versions -17 and-18
o Removed TOS from flow matching.
14.3. Changes between versions -16 and-17
o Renamed "vpn-svc" list to "vpn-service".
o Renamed "vpn-policy-list" to "vpn-policies".
o Renamed "management-transport" to "address-family".
o Renamed "multicast-transport" to "address-family".
o Modified cloud access policy using a choice.
o any-to-any-role as default site-role.
o "address-family" is now an enumeration instead of identity.
o cloud-access feature moved to container level.
o Added "address-translation" container for cloud-access.
o Renamed "customer-nat-address" to "customer-address".
o New type ip:address for "customer-address".
o "tree-flavor" moved to leaf-list.
o "bsr-candidate" list moved to "bsr-candidate-address" leaf-list.
o layer becomes mandatory in security-encryption.
o ip-subnet mask range modified.
o multicast transport constraint destination moved to leaf-list.
o lan-prefixes in vpn-policy moved to leaf-list ang tag has been
renamed "prefixes".
o Added source and destination port range in QoS classification.
o QoS classification uses more existing inet:types.
o Grouping defined for site group list.
14.4. Changes between versions -15 and-16
o Rename "topology" leaf to "vpn-service-topology".
14.5. Changes between versions -13 and-14
o Choice between device reference and location reference.
14.6. Changes between versions -12 and-13
o Removed rip-ng identity (rip container has AF information)
o renamed pe-dhcp to provider-dhcp
o add provider-dhcp-relay identity and container
o BW/MTU is now only under site-network-access
o Add list of location and location ID
o Site-network-access mapped to location Identifier
o Add list of devices (provided by operator) requested by customer
o Some management parameters moved under device list
o Site-network-access mapped to device identifier
14.7. Changes between versions -11 and-12
o Fixing some 'when' statements that prevented compilation.
14.8. Changes between versions -09 and-10
o Removed templates.
o Add site-network-access-type.
o Add a leaf number-of-dynamic-address in case of pe-dhcp
addressing.
14.9. Changes between versions -08 and-09
o Add site-vpn-flavor NNI.
14.10. Changes between versions -07 and-08
o Traffic protection moved to site level.
o Decouple operational-requirements in two containers.
14.11. Changes between versions -06 and-07
o Set config false to actual-site-start and stop.
o Add a container before cloud-access list.
o Add a container before authorized-sites list.
o Add a container before denied-sites list.
o Modified access-diversity modeling.
o Replacing type placement diversity by an identity.
14.12. Changes between versions -05 and-06
o Added linecard diverse for site diversity
o Added a new diversity enum in placement-diversity: none
o Added state to site location
o remove reference to core routing model: created new address family
identities
o added features
o Modified bearer parameters
o Modified union for ipv4/ipv6 addresses to ip-address type
o Add BSR parameters for multicast
o Add applications matching for QoS classification
14.13. Changes between versions -04 and-05
o Modify VPN policy and creating a vpn-policy-list
o Add VPN policy reference and VPN ID reference under site-network-
access
14.14. Changes between versions -02 and-03
o Add extranet-vpn container in vpn-svc
o Creating top level containers
o Refine groupings
o Added site-vpn-flavor
o qos-profile moved to choice
o vpn leaf moved to vpn-id in vpn-policy
o added ordered-by user to qos classification list
o moved traffic protection to access availability
o creating a choice in matching filter for VPN policy
o added dot1p matching field in flow-definition
14.15. Changes between versions -01 and-02
o A site is now a collection of site-accesses. This was introduced
to support M to N availability.
o Site-availability has been removed, replaced by availability
parameters under site-accesses
o Added transport-constraints within vpn-svc
o Add ToS support in match-flow
o nexthop in cascaded lan as mandatory
o customer-specific-info deleted and moved to routing protocols
o customer-lan-connection modified: need prefix and CE address
o add choice in managing PE-CE addressing
o Simplifying traffic protection
o Refine groupings for vpn-svc
o Removed name in vpn-svc
o id in vpn-svc moved to string
o Rename id in vpn-svc to vpn-id
o Changed key of vpn-svc list to vpn-id
o Add DSCP support in flow definition
o Removed ACL from security
o Add FW for site and cloud access
14.16. Changes between versions -00 and-01
o Creating multiple reusable groupings
o Added mpls leaf in vpn-svc for carrier's carrier case
o Modify identity single to single-site
o Modify site-type to site-role and also child identities.
o Creating OAM container under site and moved BFD in.
o Creating flow-definition grouping to be reused in ACL, QoS ...
o Simplified VPN policy.
o Adding multicast static group to RP mappings. IANA has assigned a new URI from the "IETF XML Registry" [RFC3688].
o Removed native-vpn and site-role from global site cfg, now managed ID: yang:ietf-l3vpn-svc
within the VPN policy. URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
Filename: http://www.iana.org/assignments/xml-registry/ns/yang/
ietf-l3vpn-svc.txt
Reference: RFC 8049
Registrant Contact: IESG
XML: N/A; the requested URI is an XML namespace.
o Creating a separate list for site templates. This document adds a new YANG module name in the "YANG Module Names"
registry [RFC6020]:
15. References Name: ietf-l3vpn-svc
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
Prefix: l3vpn-svc
Reference: RFC 8049
15.1. Normative References 12. References
[I-D.ietf-netconf-restconf] 12.1. Normative References
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-18 (work in
progress), October 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, DOI Private Network (VPN) Terminology", RFC 4026,
10.17487/RFC4026, March 2005, DOI 10.17487/RFC4026, March 2005,
<http://www.rfc-editor.org/info/rfc4026>. <http://www.rfc-editor.org/info/rfc4026>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>. 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the
Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577,
June 2006, <http://www.rfc-editor.org/info/rfc4577>. June 2006, <http://www.rfc-editor.org/info/rfc4577>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, DOI 10.17487/ Address Autoconfiguration", RFC 4862,
RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>. <http://www.rfc-editor.org/info/rfc4862>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>. 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, DOI Protocol (NETCONF) Access Control Model", RFC 6536,
10.17487/RFC6536, March 2012, DOI 10.17487/RFC6536, March 2012,
<http://www.rfc-editor.org/info/rfc6536>. <http://www.rfc-editor.org/info/rfc6536>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<http://www.rfc-editor.org/info/rfc7950>. <http://www.rfc-editor.org/info/rfc7950>.
15.2. Informative References [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<http://www.rfc-editor.org/info/rfc8040>.
12.2. Informative References
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)", Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4110, DOI 10.17487/RFC4110, July 2005, RFC 4110, DOI 10.17487/RFC4110, July 2005,
<http://www.rfc-editor.org/info/rfc4110>. <http://www.rfc-editor.org/info/rfc4110>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<http://www.rfc-editor.org/info/rfc4760>.
Acknowledgements
Thanks to Qin Wu, Maxim Klyus, Luis Miguel Contreras, Gregory Mirsky,
Zitao Wang, Jing Zhao, Kireeti Kompella, Eric Rosen, Aijun Wang,
Michael Scharf, Xufeng Liu, David Ball, Lucy Yong, Jean-Philippe
Landry, and Andrew Leu for their contributions to this document.
Contributors
The authors would like to thank Rob Shakir for his major
contributions to the initial modeling and use cases.
Authors' Addresses Authors' Addresses
Stephane Litkowski Stephane Litkowski
Orange Business Services Orange Business Services
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
Luis Tomotaki Luis Tomotaki
Verizon Verizon
 End of changes. 880 change blocks. 
2678 lines changed or deleted 2310 lines changed or added

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