draft-ietf-opsawg-l3sm-l3nm-17.txt   draft-ietf-opsawg-l3sm-l3nm-18.txt 
OPSAWG S. Barguil OPSAWG S. Barguil
Internet-Draft O. Gonzalez de Dios, Ed. Internet-Draft O. Gonzalez de Dios, Ed.
Intended status: Standards Track Telefonica Intended status: Standards Track Telefonica
Expires: 7 April 2022 M. Boucadair, Ed. Expires: 11 April 2022 M. Boucadair, Ed.
Orange Orange
L. Munoz L. Munoz
Vodafone Vodafone
A. Aguado A. Aguado
Nokia Nokia
4 October 2021 8 October 2021
A Layer 3 VPN Network YANG Model A Layer 3 VPN Network YANG Model
draft-ietf-opsawg-l3sm-l3nm-17 draft-ietf-opsawg-l3sm-l3nm-18
Abstract Abstract
As a complement to the Layer 3 Virtual Private Network Service YANG As a complement to the Layer 3 Virtual Private Network Service YANG
data Model (L3SM), used for communication between customers and data Model (L3SM), used for communication between customers and
service providers, this document defines an L3VPN Network YANG Model service providers, this document defines an L3VPN Network YANG Model
(L3NM) that can be used for the provisioning of Layer 3 Virtual (L3NM) that can be used for the provisioning of Layer 3 Virtual
Private Network (VPN) services within a service provider network. Private Network (VPN) services within a service provider network.
The model provides a network-centric view of L3VPN services. The model provides a network-centric view of L3VPN services.
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 April 2022. This Internet-Draft will expire on 11 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 49, line 43 skipping to change at page 49, line 43
| +--ro oper-status | +--ro oper-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
+--rw multicast {vpn-common:multicast}? +--rw multicast {vpn-common:multicast}?
... ...
Figure 23: Services Subtree Structure Figure 23: Services Subtree Structure
The following data nodes are defined: The following data nodes are defined:
'inbound-bandwidth': Indicates, in bytes per second (bps), the 'inbound-bandwidth': Indicates, in bits per second (bps), the
inbound bandwidth of the connection (i.e., download bandwidth from inbound bandwidth of the connection (i.e., download bandwidth from
the service provider to the site). the service provider to the site).
'outbound-bandwidth': Indicates, in bps, the outbound bandwidth of 'outbound-bandwidth': Indicates, in bps, the outbound bandwidth of
the connection (i.e., upload bandwidth from the site to the the connection (i.e., upload bandwidth from the site to the
service provider). service provider).
'mtu': Indicates the MTU at the service level. 'mtu': Indicates the MTU at the service level.
'qos': Is used to define a set of QoS policies to apply on a given 'qos': Is used to define a set of QoS policies to apply on a given
skipping to change at page 133, line 5 skipping to change at page 133, line 5
| | | |
+------------------+ +------------------+
Figure 31: Mobile Backhaul Example Figure 31: Mobile Backhaul Example
To create an L3VPN service using the L3NM, the following steps can be To create an L3VPN service using the L3NM, the following steps can be
followed. followed.
First: Create the 4G VPN service (Figure 32). First: Create the 4G VPN service (Figure 32).
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/vpn-services
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-l3vpn-ntw:vpn-services": { "ietf-l3vpn-ntw:vpn-services": {
"vpn-service": [ "vpn-service": [
{ {
"vpn-id": "4G", "vpn-id": "4G",
"customer-name": "mycustomer", "customer-name": "mycustomer",
"vpn-service-topology": "custom", "vpn-service-topology": "custom",
"description": "VPN to deploy 4G services", "vpn-description": "VPN to deploy 4G services",
"vpn-instance-profiles": { "vpn-instance-profiles": {
"vpn-instance-profile": [ "vpn-instance-profile": [
{ {
"profile-id": "simple-profile", "profile-id": "simple-profile",
"local-as": 65550, "local-as": 65550,
"rd": "0:65550:1", "rd": "0:65550:1",
"address-family": [ "address-family": [
{ {
"address-family": "vpn-common:dual-stack", "address-family": "ietf-vpn-common:dual-stack",
"vpn-targets": { "vpn-target": [
"vpn-target": [ {
"id": 1,
"route-targets": [
{ {
"id": 1, "route-target": "0:65550:1"
"route-targets": [
"0:65550:1"
],
"route-target-type": "both"
} }
] ],
"route-target-type": "both"
} }
} ]
] }
} ]
] }
} ]
} }
] }
} ]
} }
}
Figure 32: Create VPN Service Figure 32: Create VPN Service
Second: Create a VPN node as depicted in Figure 33. In this type of Second: Create a VPN node as depicted in Figure 33. In this type of
service, the VPN node is equivalent to the VRF configured in the service, the VPN node is equivalent to the VRF configured in the
physical device ('ne-id'=198.51.100.1). physical device ('ne-id'=198.51.100.1).
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ =============== NOTE: '\' line wrapping per RFC 8792 ================
vpn-services/vpn-service=4G
Host: example.com
Content-Type: application/yang-data+json
{ POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
"ietf-l3vpn-ntw:vpn-nodes": { vpn-services/vpn-service=4G
"vpn-node": [ Host: example.com
{ Content-Type: application/yang-data+json
"vpn-node-id": "44",
"ne-id": "198.51.100.1", {
"active-vpn-instance-profiles": { "ietf-l3vpn-ntw:vpn-nodes": {
"vpn-instance-profile": [ "vpn-node": [
{ {
"profile-id": "simple-profile" "vpn-node-id": "44",
} "ne-id": "198.51.100.1",
] "active-vpn-instance-profiles": {
} "vpn-instance-profile": [
} {
] "profile-id": "simple-profile"
} }
} ]
}
}
]
}
}
Figure 33: Create VPN Node Figure 33: Create VPN Node
Finally, two VPN network accesses are created using the same physical Finally, two VPN network accesses are created using the same physical
port ('interface-id'=1/1/1). Each 'vpn-network-access' has a port ('interface-id'=1/1/1). Each 'vpn-network-access' has a
particular VLAN (1,2) to differentiate the traffic between: Sync and particular VLAN (1,2) to differentiate the traffic between: Sync and
data (Figure 34). data (Figure 34).
POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\ =============== NOTE: '\' line wrapping per RFC 8792 ================
vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44
content-type: application/yang-data+json POST: /restconf/data/ietf-l3vpn-ntw:l3vpn-ntw/\
vpn-services/vpn-service=4G/vpn-nodes/vpn-node=44
content-type: application/yang-data+json
{
"ietf-l3vpn-ntw:vpn-network-accesses": {
"vpn-network-access": [
{
"id": "1/1/1.1",
"interface-id": "1/1/1",
"description": "Interface SYNC to eNODE-B",
"vpn-network-access-type": "ietf-vpn-common:point-to-point",
"vpn-instance-profile": "simple-profile",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"encapsulation": {
"type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 1
}
}
},
"ip-connection": {
"ipv4": {
"local-address": "192.0.2.1",
"prefix-length": 30,
"address-allocation-type": "static-address",
"static-addresses": {
"primary-address": "1",
"address": [
{
"address-id": "1",
"customer-address": "192.0.2.2"
}
]
}
},
"ipv6": {
"local-address": "2001:db8::1",
"prefix-length": 64,
"address-allocation-type": "static-address",
"primary-address": "1",
"address": [
{
"address-id": "1",
"customer-address": "2001:db8::2"
}
]
}
},
"routing-protocols": {
"routing-protocol": [
{
"id": "1",
"type": "ietf-vpn-common:direct"
}
]
}
},
{
"id": "1/1/1.2",
"interface-id": "1/1/1",
"description": "Interface DATA to eNODE-B",
"vpn-network-access-type": "ietf-vpn-common:point-to-point",
"vpn-instance-profile": "simple-profile",
"status": {
"admin-status": {
"status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"encapsulation": {
"type": "ietf-vpn-common:dot1q",
"dot1q": {
"cvlan-id": 2
}
}
},
"ip-connection": {
"ipv4": {
"local-address": "192.0.2.1",
"prefix-length": 30,
"address-allocation-type": "static-address",
"static-addresses": {
"primary-address": "1",
"address": [
{
"address-id": "1",
"customer-address": "192.0.2.2"
}
]
}
},
"ipv6": {
"local-address": "2001:db8::1",
"prefix-length": 64,
"address-allocation-type": "static-address",
"primary-address": "1",
"address": [
{
"address-id": "1",
"customer-address": "2001:db8::2"
}
]
}
},
"routing-protocols": {
"routing-protocol": [
{
"id": "1",
"type": "ietf-vpn-common:direct"
}
]
}
}
]
}
}
Figure 34: Create VPN Network Access
A.2. Loopback Interface
An example of loopback interface is depicted in Figure 35.
{ {
"ietf-l3vpn-ntw:vpn-network-accesses": { "ietf-l3vpn-ntw:vpn-network-accesses": {
"vpn-network-access": [ "vpn-network-access": [
{ {
"id": "1/1/1.1", "id": "vpn-access-loopback",
"interface-id": "1/1/1", "interface-id": "Loopback1",
"description": "Interface SYNC to eNODE-B", "description": "An example of loopback interface.",
"vpn-network-access-type": "vpn-common:point-to-point", "vpn-network-access-type": "ietf-vpn-common:loopback",
"vpn-instance-profile": "simple-profile",
"status": { "status": {
"admin-status": { "admin-status": {
"status": "vpn-common:admin-state-up" "status": "ietf-vpn-common:admin-up"
}
},
"connection": {
"encapsulation": {
"type": "dot1q",
"dot1q": {
"cvlan-id": 1
}
} }
}, },
"ip-connection": { "ip-connection": {
"ipv4": {
"local-address": "192.0.2.1",
"prefix-length": 30,
"address-allocation-type": "static-address",
"static-addresses": {
"primary-address": "1",
"address": [
{
"address-id": "1",
"customer-address": "192.0.2.2"
}
]
}
},
"ipv6": { "ipv6": {
"local-address": "2001:db8::1", "local-address": "2001:db8::4",
"prefix-length": 64, "prefix-length": 128
"address-allocation-type": "static-address",
"primary-address": "1",
"address": [
{
"address-id": "1",
"customer-address": "2001:db8::2"
}
]
} }
},
"routing-protocols": {
"routing-protocol": [
{
"id": "1",
"type": "vpn-common:direct"
}
]
}
},
{
"id": "1/1/1.2",
"interface-id": "1/1/1",
"description": "Interface DATA to eNODE-B",
"vpn-network-access-type": "vpn-common:point-to-point",
"vpn-instance-profile": "simple-profile",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"connection": {
"encapsulation": {
"type": "dot1q",
"dot1q": {
"cvlan-id": 2
}
}
},
"ip-connection": {
"ipv4": {
"local-address": "192.0.2.1",
"prefix-length": 30,
"address-allocation-type": "static-address",
"static-addresses": {
"primary-address": "1",
"address": [
{
"address-id": "1",
"customer-address": "192.0.2.2"
}
]
}
},
"ipv6": {
"local-address": "2001:db8::1",
"prefix-length": 64,
"address-allocation-type": "static-address",
"primary-address": "1",
"address": [
{
"address-id": "1",
"customer-address": "2001:db8::2"
}
]
}
},
"routing-protocols": {
"routing-protocol": [
{
"id": "1",
"type": "vpn-common:direct"
}
]
} }
} }
] ]
} }
} }
Figure 34: Create VPN Network Access
A.2. Loopback Interface
An example of loopback interface is depicted in Figure 35.
{
"ietf-l3vpn-ntw:vpn-network-accesses": {
"vpn-network-access": [
{
"id": "vpn-access-loopback",
"interface-id": "Loopback1",
"description": "An example of loopback interface.",
"vpn-network-access-type": "vpn-common:loopback",
"status": {
"admin-status": {
"status": "vpn-common:admin-state-up"
}
},
"ip-connection": {
"ipv6": {
"local-address": "2001:db8::4",
"prefix-length": 128
}
}
}
]
}
}
Figure 35: VPN Network Access with a Loopback Interface (Message Figure 35: VPN Network Access with a Loopback Interface (Message
Body) Body)
A.3. Overriding VPN Instance Profile Parameters A.3. Overriding VPN Instance Profile Parameters
Figure 36 shows a simplified example to illustrate how some Figure 36 shows a simplified example to illustrate how some
information that is provided at the VPN service level (particularly information that is provided at the VPN service level (particularly
as part of the 'vpn-instance-profiles') can be overridden by the one as part of the 'vpn-instance-profiles') can be overridden by the one
configured at the VPN node level. In this example, PE3 and PE4 configured at the VPN node level. In this example, PE3 and PE4
inherit the 'vpn-instance-profiles' parameters that are specified at inherit the 'vpn-instance-profiles' parameters that are specified at
the VPN service level, but PE1 and PE2 are provided with "maximum- the VPN service level, but PE1 and PE2 are provided with "maximum-
routes" values at the VPN node level that override the ones that are routes" values at the VPN node level that override the ones that are
specified at the VPN service level. specified at the VPN service level.
{ {
"ietf-l3vpn-ntw:vpn-services": { "ietf-l3vpn-ntw:vpn-services": {
"vpn-service": [ "vpn-service": [
{ {
"vpn-id": "override-example", "vpn-id": "override-example",
"vpn-service-topology": "vpn-common:hub-spoke", "vpn-service-topology": "ietf-vpn-common:hub-spoke",
"vpn-instance-profiles": { "vpn-instance-profiles": {
"vpn-instance-profile": [ "vpn-instance-profile": [
{ {
"profile-id": "HUB", "profile-id": "HUB",
"role": "vpn-common:hub-role", "role": "ietf-vpn-common:hub-role",
"local-as": 64510, "local-as": 64510,
"rd-suffix": 1001, "rd-suffix": 1001,
"address-family": [ "address-family": [
{
"address-family": "ietf-vpn-common:dual-stack",
"maximum-routes": [
{
"protocol": "ietf-vpn-common:any",
"maximum-routes": 100
}
]
}
]
},
{
"profile-id": "SPOKE",
"role": "ietf-vpn-common:spoke-role",
"local-as": 64510,
"address-family": [
{
"address-family": "ietf-vpn-common:dual-stack",
"maximum-routes": [
{
"protocol": "ietf-vpn-common:any",
"maximum-routes": 1000
}
]
}
]
}
]
},
"vpn-nodes": {
"vpn-node": [
{
"vpn-node-id": "PE1",
"ne-id": "pe1",
"router-id": "198.51.100.1",
"active-vpn-instance-profiles": {
"vpn-instance-profile": [
{ {
"address-family": "vpn-common:dual-stack", "profile-id": "HUB",
"maximum-routes": [ "rd": "1:198.51.100.1:1001",
"address-family": [
{ {
"protocol": "vpn-common:any", "address-family": "ietf-vpn-common:dual-stack",
"maximum-routes": 100 "maximum-routes": [
{
"protocol": "ietf-vpn-common:any",
"maximum-routes": 10
}
]
} }
] ]
} }
] ]
}, }
{ },
"profile-id": "SPOKE", {
"role": "vpn-common:spoke-role", "vpn-node-id": "PE2",
"local-as": 64510, "ne-id": "pe2",
"address-family": [ "router-id": "198.51.100.2",
"active-vpn-instance-profiles": {
"vpn-instance-profile": [
{ {
"address-family": "vpn-common:dual-stack", "profile-id": "SPOKE",
"maximum-routes": [ "address-family": [
{ {
"protocol": "vpn-common:any", "address-family": "ietf-vpn-common:dual-stack",
"maximum-routes": 1000 "maximum-routes": [
} {
"protocol": "ietf-vpn-common:any",
"maximum-routes": 100
}
]
}
] ]
} }
] ]
} }
] },
}, {
"vpn-nodes": { "vpn-node-id": "PE3",
"vpn-node": [ "ne-id": "pe3",
{ "router-id": "198.51.100.3",
"vpn-node-id": "PE1", "active-vpn-instance-profiles": {
"ne-id": "pe1", "vpn-instance-profile": [
"router-id": "198.51.100.1", {
"active-vpn-instance-profiles": { "profile-id": "SPOKE"
"vpn-instance-profile": [ }
{ ]
"profile-id": "HUB",
"rd": "1:198.51.100.1:1001",
"address-family": [
{
"address-family": "vpn-common:dual-stack",
"maximum-routes": [
{
"protocol": "vpn-common:any",
"maximum-routes": 10
}
]
}
]
}
]
}
},
{
"vpn-node-id": "PE2",
"ne-id": "pe2",
"router-id": "198.51.100.2",
"active-vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "SPOKE",
"address-family": [
{
"address-family": "vpn-common:dual-stack",
"maximum-routes": [
{
"protocol": "vpn-common:any",
"maximum-routes": 100
}
]
}
]
}
]
}
},
{
"vpn-node-id": "PE3",
"ne-id": "pe3",
"router-id": "198.51.100.3",
"active-vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "SPOKE"
}
]
}
},
{
"vpn-node-id": "PE4",
"ne-id": "pe4",
"router-id": "198.51.100.4",
"active-vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "SPOKE"
}
]
}
} }
] },
} {
"vpn-node-id": "PE4",
"ne-id": "pe4",
"router-id": "198.51.100.4",
"active-vpn-instance-profiles": {
"vpn-instance-profile": [
{
"profile-id": "SPOKE"
}
]
}
}
]
} }
] }
} ]
} }
}
Figure 36: VPN Instance Profile Example (Message Body) Figure 36: VPN Instance Profile Example (Message Body)
A.4. Multicast VPN Provisioning Example A.4. Multicast VPN Provisioning Example
IPTV is mainly distributed through multicast over the LANs. In the IPTV is mainly distributed through multicast over the LANs. In the
following example, PIM-SM is enabled and functional between the PE following example, PIM-SM is enabled and functional between the PE
and the CE. The PE receives multicast traffic from a CE that is and the CE. The PE receives multicast traffic from a CE that is
directly connected to the multicast source. The signaling between PE directly connected to the multicast source. The signaling between PE
and CE is achieved using BGP. Also, RP is statically configured for and CE is achieved using BGP. Also, RP is statically configured for
a multicast group. a multicast group.
skipping to change at page 142, line 4 skipping to change at page 142, line 4
+-----------+ +-----------+ +-----------+ +-----------+
Figure 37: Multicast L3VPN Service Example Figure 37: Multicast L3VPN Service Example
An example is provided below to illustrate how to configure a An example is provided below to illustrate how to configure a
multicast L3VPN service using the L3NM. multicast L3VPN service using the L3NM.
First, the multicast service is created together with a generic VPN First, the multicast service is created together with a generic VPN
instance profile (see the excerpt of the request message body shown instance profile (see the excerpt of the request message body shown
in Figure 38) in Figure 38)
{ {
"ietf-l3vpn-ntw:vpn-services": { "ietf-l3vpn-ntw:vpn-services": {
"vpn-service": [ "vpn-service": [
{ {
"vpn-id": "Multicast-IPTV", "vpn-id": "Multicast-IPTV",
"vpn-description": "Multicast IPTV VPN service", "vpn-description": "Multicast IPTV VPN service",
"customer-name": "a-name", "customer-name": "a-name",
"vpn-service-topology": "vpn-common:hub-spoke", "vpn-service-topology": "ietf-vpn-common:hub-spoke",
"vpn-instance-profiles": { "vpn-instance-profiles": {
"vpn-instance-profile": [ "vpn-instance-profile": [
{ {
"profile-id": "multicast", "profile-id": "multicast",
"role": "ietf-vpn-common:hub-role", "role": "ietf-vpn-common:hub-role",
"local-as": 65536, "local-as": 65536,
"multicast": { "multicast": {
"rp": { "rp": {
"rp-group-mappings": { "rp-group-mappings": {
"rp-group-mapping": [ "rp-group-mapping": [
{ {
"id": 1, "id": 1,
"rp-address": "203.0.113.17", "rp-address": "203.0.113.17",
"groups": { "groups": {
"group": [ "group": [
{ {
"id": 1, "id": 1,
"group-address": "239.130.0.0/15" "group-address": "239.130.0.0/15"
} }
] ]
} }
} }
] ]
}, },
"rp-discovery": { "rp-discovery": {
"rp-discovery-type": "vpn-common:static-rp" "rp-discovery-type": "ietf-vpn-common:static-rp"
} }
} }
} }
} }
] ]
} }
} }
] ]
} }
} }
Figure 38: Create Multicast VPN Service (Excerpt of the Message Figure 38: Create Multicast VPN Service (Excerpt of the Message
Request Body) Request Body)
Then, the VPN nodes are created (see the excerpt of the request Then, the VPN nodes are created (see the excerpt of the request
message body shown in Figure 39). In this example, the VPN node will message body shown in Figure 39). In this example, the VPN node will
represent VRF configured in the physical device. represent VRF configured in the physical device.
{ {
"ietf-l3vpn-ntw:vpn-node": [ "ietf-l3vpn-ntw:vpn-node": [
skipping to change at page 143, line 38 skipping to change at page 143, line 38
Figure 39: Create Multicast VPN Node (Excerpt of the Message Figure 39: Create Multicast VPN Node (Excerpt of the Message
Request Body) Request Body)
Finally, create the VPN network access with multicast enabled (see Finally, create the VPN network access with multicast enabled (see
the excerpt of the request message body shown in Figure 40). the excerpt of the request message body shown in Figure 40).
{ {
"ietf-l3vpn-ntw:vpn-network-access": { "ietf-l3vpn-ntw:vpn-network-access": {
"id": "1/1/1", "id": "1/1/1",
"description": "Connected-to-source", "description": "Connected-to-source",
"vpn-network-access-type": "vpn-common:point-to-point", "vpn-network-access-type": "ietf-vpn-common:point-to-point",
"vpn-instance-profile": "multicast", "vpn-instance-profile": "multicast",
"status": { "status": {
"admin-status": { "admin-status": {
"status": "vpn-common:admin-state-up" "status": "vpn-common:admin-up"
}, },
"ip-connection": { "ip-connection": {
"ipv4": { "ipv4": {
"local-address": "203.0.113.1", "local-address": "203.0.113.1",
"prefix-length": 30, "prefix-length": 30,
"address-allocation-type": "static-address", "address-allocation-type": "static-address",
"static-addresses": { "static-addresses": {
"primary-address": "1", "primary-address": "1",
"address": [ "address": [
{ {
skipping to change at page 144, line 15 skipping to change at page 144, line 15
"customer-address": "203.0.113.2" "customer-address": "203.0.113.2"
} }
] ]
} }
} }
}, },
"routing-protocols": { "routing-protocols": {
"routing-protocol": [ "routing-protocol": [
{ {
"id": "1", "id": "1",
"type": "vpn-common:bgp-routing", "type": "ietf-vpn-common:bgp-routing",
"bgp": { "bgp": {
"description": "Connected to CE", "description": "Connected to CE",
"peer-as": "65537", "peer-as": "65537",
"address-family": "vpn-common:ipv4", "address-family": "ietf-vpn-common:ipv4",
"neighbor": "203.0.113.2" "neighbor": "203.0.113.2"
} }
} }
] ]
}, },
"service": { "service": {
"inbound-bandwidth": "100000000", "inbound-bandwidth": "100000000",
"outbound-bandwidth": "100000000", "outbound-bandwidth": "100000000",
"mtu": 1500, "mtu": 1500,
"multicast": { "multicast": {
"access-type": "source-only", "access-type": "source-only",
"address-family": "vpn-common:ipv4", "address-family": "ietf-vpn-common:ipv4",
"protocol-type": "router", "protocol-type": "router",
"pim": { "pim": {
"hello-interval": 30, "hello-interval": 30,
"status": { "status": {
"admin-status": { "admin-status": {
"status": "vpn-common:admin-state-up" "status": "ietf-vpn-common:admin-up"
} }
} }
} }
} }
} }
} }
} }
} }
Figure 40: Create VPN Network Access (Excerpt of the Message Figure 40: Create VPN Network Access (Excerpt of the Message
skipping to change at page 146, line 26 skipping to change at page 146, line 26
Mirsky, and Tom Petch. Many thanks to them. Thanks to Philip Eardly Mirsky, and Tom Petch. Many thanks to them. Thanks to Philip Eardly
for the review of an early version of the document. for the review of an early version of the document.
Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski
contributed to early version of the individual submission. Many contributed to early version of the individual submission. Many
thanks to Robert Wilton for the AD review. Thanks to Andrew Malis thanks to Robert Wilton for the AD review. Thanks to Andrew Malis
for the routing directorate review, Rifaat Shekh-Yusef for the for the routing directorate review, Rifaat Shekh-Yusef for the
security directorate review, Qin Wu for the opsdir review, and Pete security directorate review, Qin Wu for the opsdir review, and Pete
Resnick for the genart directorate review. Thanks to Michael Scharf Resnick for the genart directorate review. Thanks to Michael Scharf
for the discussion on TCP-AO. Thanks to Martin Duke, Lars Eagert, for the discussion on TCP-AO. Thanks to Martin Duke, Lars Eagert,
Zaheduzzaman Sarker, Roman Danyliw, Erik Kline, Benjamin Kaduk, and Zaheduzzaman Sarker, Roman Danyliw, Erik Kline, Benjamin Kaduk,
Francesca Palombini for the IESG review. Francesca Palombini, and Eric Vyncke for the IESG review.
This work was supported in part by the European Commission funded This work was supported in part by the European Commission funded
H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727) and Horizon 2020 H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727) and Horizon 2020
Secured autonomic traffic management for a Tera of SDN flows Secured autonomic traffic management for a Tera of SDN flows
(Teraflow) project (G.A. 101015857). (Teraflow) project (G.A. 101015857).
Contributors Contributors
Victor Lopez Victor Lopez
Telefonica Telefonica
Email: victor.lopezalvarez@telefonica.com Email: victor.lopezalvarez@telefonica.com
 End of changes. 41 change blocks. 
357 lines changed or deleted 362 lines changed or added

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