draft-ietf-opsawg-l3sm-l3nm-04.txt   draft-ietf-opsawg-l3sm-l3nm-05.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: April 7, 2021 M. Boucadair, Ed. Expires: April 19, 2021 M. Boucadair, Ed.
Orange Orange
L. Munoz L. Munoz
Vodafone Vodafone
A. Aguado A. Aguado
Nokia Nokia
October 4, 2020 October 16, 2020
A Layer 3 VPN Network YANG Model A Layer 3 VPN Network YANG Model
draft-ietf-opsawg-l3sm-l3nm-04 draft-ietf-opsawg-l3sm-l3nm-05
Abstract Abstract
This document defines a L3VPN Network YANG Model (L3NM) that can be This document defines a L3VPN Network YANG Model (L3NM) that can be
used to manage the provisioning of Layer 3 Virtual Private Network used to manage the provisioning of Layer 3 Virtual Private Network
(VPN) services within a Service Provider's network. The model (VPN) services within a Service Provider's network. The model
provides a network-centric view of L3VPN services. provides a network-centric view of L3VPN services.
L3NM is meant to be used by a Network Controller to derive the L3NM is meant to be used by a Network Controller to derive the
configuration information that will be sent to relevant network configuration information that will be sent to relevant network
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 April 7, 2021. This Internet-Draft will expire on April 19, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 24 skipping to change at page 3, line 24
13.1. Normative References . . . . . . . . . . . . . . . . . . 92 13.1. Normative References . . . . . . . . . . . . . . . . . . 92
13.2. Informative References . . . . . . . . . . . . . . . . . 93 13.2. Informative References . . . . . . . . . . . . . . . . . 93
Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 96 Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 96
A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 96 A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 96
A.2. Multicast VPN Provisioning Example . . . . . . . . . . . 100 A.2. Multicast VPN Provisioning Example . . . . . . . . . . . 100
Appendix B. Implementation Status . . . . . . . . . . . . . . . 104 Appendix B. Implementation Status . . . . . . . . . . . . . . . 104
B.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 104 B.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 104
B.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 104 B.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 104
B.3. Infinera Implementation . . . . . . . . . . . . . . . . . 104 B.3. Infinera Implementation . . . . . . . . . . . . . . . . . 104
B.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 104 B.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 104
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105
1. Introduction 1. Introduction
[RFC8299] defines a L3VPN Service YANG data Model (L3SM) that can be [RFC8299] defines a L3VPN Service YANG data Model (L3SM) that can be
used for communication between customers and network operators. Such used for communication between customers and network operators. Such
model is focused on describing the customer view of the Virtual model is focused on describing the customer view of the Virtual
Private Network (VPN) services, and provides an abstracted view of Private Network (VPN) services, and provides an abstracted view of
the customer's requested services. That approach limits the usage of the customer's requested services. That approach limits the usage of
the L3SM module to the role of a Customer Service Model, according to the L3SM module to the role of a Customer Service Model, according to
the terminology defined in [RFC8309]. the terminology defined in [RFC8309].
skipping to change at page 4, line 33 skipping to change at page 4, line 33
coordination of different VPNs in different underlying networks. coordination of different VPNs in different underlying networks.
More complex deployment scenarios involving the coordination of More complex deployment scenarios involving the coordination of
different VPN instances and different technologies to provide end-to- different VPN instances and different technologies to provide end-to-
end VPN connectivity are addressed by a complementary YANG model end VPN connectivity are addressed by a complementary YANG model
defined in [I-D.evenwu-opsawg-yang-composed-vpn]. defined in [I-D.evenwu-opsawg-yang-composed-vpn].
L3NM focuses on BGP PE-based Layer 3 VPNs as described in L3NM focuses on BGP PE-based Layer 3 VPNs as described in
[RFC4026][RFC4110][RFC4364] and Multicast VPNs as described in [RFC4026][RFC4110][RFC4364] and Multicast VPNs as described in
[RFC6037][RFC6513][RFC7988]. [RFC6037][RFC6513][RFC7988].
The YANG data model in this document conforms to the Network
Management Datastore Architecture (NMDA) defined in [RFC8342].
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 3. Terminology
skipping to change at page 20, line 28 skipping to change at page 20, line 28
Each 'vpn-network-access' SHOULD have a 'vpn-network-access-type' to Each 'vpn-network-access' SHOULD have a 'vpn-network-access-type' to
select the type of network interface to be deployed in the devices. select the type of network interface to be deployed in the devices.
The available options are: The available options are:
o Point-to-Point: The point-to-point type represent a direct o Point-to-Point: The point-to-point type represent a direct
connection between the end-points. It implies the controller must connection between the end-points. It implies the controller must
keep the association between a logical or physical interface on keep the association between a logical or physical interface on
the device with the 'id' of the vpn-network-access. the device with the 'id' of the vpn-network-access.
o Multipoint: This option represents a broadcast connection between o Multipoint: This option represents a broadcast connection between
two end-points. It implies the controller must keep the end-points. It implies the controller must keep the association
association between a logical or physical interface on the device between a logical or physical interface on the device with the
with the 'id' of the 'vpn-network-access'. 'id' of the 'vpn-network-access'.
o Pseudowire: Represent a connection coming from an L2VPN service. o Pseudowire: Represent a connection coming from an L2VPN service.
It implies the controller must keep the relationship between the It implies the controller must keep the relationship between the
logical tunnels or bridges on the devices with the 'id' of the' logical tunnels or bridges on the devices with the 'id' of the'
vpn-network-access'. vpn-network-access'.
o Loopback: It represents the creation of a logical interface on the o Loopback: It represents the creation of a logical interface on the
devices. devices.
A PNC [RFC8453] will accept VPN requests containing this construct, A PNC [RFC8453] will accept VPN requests containing this construct,
skipping to change at page 30, line 5 skipping to change at page 30, line 5
To be aligned with [RFC8299], this model supports the following CE-PE To be aligned with [RFC8299], this model supports the following CE-PE
routing protocols: routing protocols:
o OSPF: The model (Figure 17) allows the user to configure OSPF to o OSPF: The model (Figure 17) allows the user to configure OSPF to
run as routing protocol on the 'vpn-network-access interface'. An run as routing protocol on the 'vpn-network-access interface'. An
OSPF instance can be bound to IPv4, IPv6 or both. When only IPv4 OSPF instance can be bound to IPv4, IPv6 or both. When only IPv4
address-family is requested, it will be up to the implementation address-family is requested, it will be up to the implementation
to drive whether OSPFv2 or OSPFv3 is used. to drive whether OSPFv2 or OSPFv3 is used.
... ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
| +--rw vpn-network-access* [id] | +--rw vpn-network-access* [id]
| +--rw id | +--rw id
| | vpn-common:vpn-id | | vpn-common:vpn-id
| ... | ...
| +--rw ip-connection | +--rw ip-connection
| | ... | | ...
| +--rw routing-protocols | +--rw routing-protocols
| | +--rw routing-protocol* [id] | | +--rw routing-protocol* [id]
| | +--rw id string | | +--rw id string
| | +--rw type? identityref | | +--rw type? identityref
| | +--rw routing-profiles* [id] | | +--rw routing-profiles* [id]
| | | +--rw id leafref | | | +--rw id leafref
| | | +--rw type? identityref | | | +--rw type? identityref
| | +--rw ospf {vpn-common:rtg-ospf}? | | +--rw ospf {vpn-common:rtg-ospf}?
| | | +--rw address-family* | | | +--rw address-family*
| | | | vpn-common:address-family | | | | vpn-common:address-family
| | | +--rw area-address | | | +--rw area-address
| | | | yang:dotted-quad | | | | yang:dotted-quad
| | | +--rw metric? uint16 | | | +--rw metric? uint16
| | | +--rw mtu? uint16 | | | +--rw mtu? uint16
| | | +--rw process-id? uint16 | | | +--rw process-id? uint16
| | | +--rw security | | | +--rw security
| | | | +--rw auth-key? string | | | | +--rw auth-key? string
| | | +--rw sham-links | | | +--rw sham-links
| | | {vpn-common:rtg-ospf-sham-link}? | | | {vpn-common:rtg-ospf-sham-link}?
| | | +--rw sham-link* [target-site] | | | +--rw sham-link* [target-site]
| | | +--rw target-site | | | +--rw target-site
| | | | vpn-common:vpn-id | | | | vpn-common:vpn-id
| | | +--rw metric? uint16 | | | +--rw metric? uint16
| | +--rw bgp {vpn-common:rtg-bgp}? | | +--rw bgp {vpn-common:rtg-bgp}?
| | | ... | | | ...
| | +--rw isis {vpn-common:rtg-isis}? | | +--rw isis {vpn-common:rtg-isis}?
| | | ... | | | ...
| | +--rw static | | +--rw static
| | | ... | | | ...
| | +--rw rip {vpn-common:rtg-rip}? | | +--rw rip {vpn-common:rtg-rip}?
| | | ... | | | ...
| | +--rw vrrp {vpn-common:rtg-vrrp}? | | +--rw vrrp {vpn-common:rtg-vrrp}?
| | ... | | ...
| +--rw service | +--rw service
| ... | ...
... ...
Figure 17: OPSF Routing Subtree Structure Figure 17: OPSF Routing Subtree Structure
o BGP: The model (Figure 18) allows to configure a BGP neighbor, o BGP: The model (Figure 18) allows to configure a BGP neighbor,
including a set for parameters that are pertinent to be tweaked at including a set for parameters that are pertinent to be tweaked at
the network level for service customization purposes. This the network level for service customization purposes. This
container does not aim to include every BGP parameter; a container does not aim to include every BGP parameter; a
comprehensive set of parameters belongs more to the BGP device comprehensive set of parameters belongs more to the BGP device
model. The following parameters are captured in Figure 18. It is model. The following parameters are captured in Figure 18. It is
up to the implementation to drive the corresponding BGP device up to the implementation to drive the corresponding BGP device
skipping to change at page 32, line 7 skipping to change at page 32, line 7
prefixes can be received from a neighbor. If reached, the BGP prefixes can be received from a neighbor. If reached, the BGP
session will be teared down. session will be teared down.
* 'bgp-timer': Two timers can be captured in this container: (1) * 'bgp-timer': Two timers can be captured in this container: (1)
'hold-time' which is the time interval that will be used for 'hold-time' which is the time interval that will be used for
the HoldTimer (Section 4.2 of [RFC4271]) when establishing a the HoldTimer (Section 4.2 of [RFC4271]) when establishing a
BGP session. (2) 'keep-alive' which is the time interval for BGP session. (2) 'keep-alive' which is the time interval for
the KeepAlive timer between a PE and a BGP peer (Section 4.4 of the KeepAlive timer between a PE and a BGP peer (Section 4.4 of
[RFC4271]). [RFC4271]).
... ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
| +--rw vpn-network-access* [id] | +--rw vpn-network-access* [id]
| +--rw id | +--rw id
| | vpn-common:vpn-id | | vpn-common:vpn-id
| ... | ...
| +--rw ip-connection | +--rw ip-connection
| | ... | | ...
| +--rw routing-protocols | +--rw routing-protocols
| | +--rw routing-protocol* [id] | | +--rw routing-protocol* [id]
| | +--rw id string | | +--rw id string
| | +--rw type? identityref | | +--rw type? identityref
| | +--rw routing-profiles* [id] | | +--rw routing-profiles* [id]
| | | +--rw id leafref | | | +--rw id leafref
| | | +--rw type? identityref | | | +--rw type? identityref
| | +--rw ospf {vpn-common:rtg-ospf}? | | +--rw ospf {vpn-common:rtg-ospf}?
| | | ... | | | ...
| | +--rw bgp {vpn-common:rtg-bgp}? | | +--rw bgp {vpn-common:rtg-bgp}?
| | | +--rw peer-autonomous-system | | | +--rw peer-autonomous-system
| | | | inet:as-number | | | | inet:as-number
| | | +--rw local-autonomous-system? | | | +--rw local-autonomous-system?
| | | | inet:as-number | | | | inet:as-number
| | | +--rw address-family* | | | +--rw address-family*
| | | | vpn-common:address-family | | | | vpn-common:address-family
| | | +--rw neighbor* | | | +--rw neighbor*
| | | | inet:ip-address | | | | inet:ip-address
| | | +--rw multihop? uint8 | | | +--rw multihop? uint8
| | | +--rw security | | | +--rw security
| | | | +--rw auth-key? string | | | | +--rw auth-key? string
| | | +--rw status | | | +--rw status
| | | | +--rw admin-status | | | | +--rw admin-status
| | | | | +--rw status? identityref | | | | | +--rw status? identityref
| | | | | +--rw last-updated? | | | | | +--rw last-updated?
| | | | | | yang:date-and-time | | | | | | yang:date-and-time
| | | | +--ro oper-status | | | | +--ro oper-status
| | | | +--ro status? identityref | | | | +--ro status? identityref
| | | | +--ro last-updated? | | | | +--ro last-updated?
| | | | yang:date-and-time | | | | yang:date-and-time
| | | +--rw description? string | | | +--rw description? string
| | | +--rw as-override? boolean | | | +--rw as-override? boolean
| | | +--rw default-route? boolean | | | +--rw default-route? boolean
| | | +--rw bgp-max-prefix | | | +--rw bgp-max-prefix
| | | | +--rw max-prefix? uint32 | | | | +--rw max-prefix? uint32
| | | | +--rw warning-threshold? decimal64 | | | | +--rw warning-threshold? decimal64
| | | | +--rw violate-action? enumeration | | | | +--rw violate-action? enumeration
| | | | +--rw restart-interval? uint16 | | | | +--rw restart-interval? uint16
| | | +--rw bgp-timer | | | +--rw bgp-timer
| | | +--rw keep-alive? uint16 | | | +--rw keep-alive? uint16
| | | +--rw hold-time? uint16 | | | +--rw hold-time? uint16
| | +--rw isis {vpn-common:rtg-isis}? | | +--rw isis {vpn-common:rtg-isis}?
| | | ... | | | ...
| | +--rw static | | +--rw static
| | | ... | | | ...
| | +--rw rip {vpn-common:rtg-rip}? | | +--rw rip {vpn-common:rtg-rip}?
| | | ... | | | ...
| | +--rw vrrp {vpn-common:rtg-vrrp}? | | +--rw vrrp {vpn-common:rtg-vrrp}?
| | ... | | ...
| +--rw service | +--rw service
| ... | ...
... ...
Figure 18: BGP Routing Subtree Structure Figure 18: BGP Routing Subtree Structure
o IS-IS: The model (Figure 19) allows the user to configure IS-IS to o IS-IS: The model (Figure 19) allows the user to configure IS-IS to
run on the 'vpn-network-access' interface. An IS-IS instance can run on the 'vpn-network-access' interface. An IS-IS instance can
run L1, L2, or both levels. run L1, L2, or both levels.
... ...
+--rw vpn-network-accesses +--rw vpn-network-accesses
| +--rw vpn-network-access* [id] | +--rw vpn-network-access* [id]
skipping to change at page 40, line 10 skipping to change at page 40, line 10
| | | | | ... | | | | | ...
| | | | +--:(udp) | | | | +--:(udp)
| | | | ... | | | | ...
... ...
Figure 22: QoS Subtree Structure (L3) Figure 22: QoS Subtree Structure (L3)
* Layer 4: As shown in Figure 23, TCP or UDP-related match * Layer 4: As shown in Figure 23, TCP or UDP-related match
crietria can be specified. crietria can be specified.
+--rw qos {vpn-common:qos}? +--rw qos {vpn-common:qos}?
| +--rw qos-classification-policy | +--rw qos-classification-policy
| | +--rw rule* [id] | | +--rw rule* [id]
| | +--rw id | | +--rw id
| | | string | | | string
| | +--rw (match-type)? | | +--rw (match-type)?
| | | +--:(match-flow) | | | +--:(match-flow)
| | | | +--rw (l3)? | | | | +--rw (l3)?
| | | | | +--:(ipv4) | | | | | +--:(ipv4)
| | | | | | ... | | | | | | ...
| | | | | +--:(ipv6) | | | | | +--:(ipv6)
| | | | | ... | | | | | ...
| | | | +--rw (l4)? | | | | +--rw (l4)?
| | | | +--:(tcp) | | | | +--:(tcp)
| | | | | +--rw tcp | | | | | +--rw tcp
| | | | | +--rw sequence-number? | | | | | +--rw sequence-number?
| | | | | | uint32 | | | | | | uint32
| | | | | +--rw acknowledgement-number? | | | | | +--rw acknowledgement-number?
| | | | | | uint32 | | | | | | uint32
| | | | | +--rw data-offset? | | | | | +--rw data-offset?
| | | | | | uint8 | | | | | | uint8
| | | | | +--rw reserved? | | | | | +--rw reserved?
| | | | | | uint8 | | | | | | uint8
| | | | | +--rw flags? | | | | | +--rw flags?
| | | | | | bits | | | | | | bits
| | | | | +--rw window-size? | | | | | +--rw window-size?
| | | | | | uint16 | | | | | | uint16
| | | | | +--rw urgent-pointer? | | | | | +--rw urgent-pointer?
| | | | | | uint16 | | | | | | uint16
| | | | | +--rw options? | | | | | +--rw options?
| | | | | | binary | | | | | | binary
| | | | | +--rw (source-port)? | | | | | +--rw (source-port)?
| | | | | | +--:(source-port-range-or-operator) | | | | | | +--:(source-port-range-or-operator)
| | | | | | +--rw source-port-range-or-operator | | | | | | +--rw source-port-range-or-operator
| | | | | | +--rw (port-range-or-operator)? | | | | | | +--rw (port-range-or-operator)?
| | | | | | +--:(range) | | | | | | +--:(range)
| | | | | | | +--rw lower-port | | | | | | | +--rw lower-port
| | | | | | | | inet:port-number | | | | | | | | inet:port-number
| | | | | | | +--rw upper-port | | | | | | | +--rw upper-port
| | | | | | | inet:port-number | | | | | | | inet:port-number
| | | | | | +--:(operator) | | | | | | +--:(operator)
| | | | | | +--rw operator? | | | | | | +--rw operator?
| | | | | | | operator | | | | | | | operator
| | | | | | +--rw port | | | | | | +--rw port
| | | | | | inet:port-number | | | | | | inet:port-number
| | | | | +--rw (destination-port)? | | | | | +--rw (destination-port)?
| | | | +--:(destination-port-range-or-operator) | | | | +--:(destination-port-range-or-operator)
| | | | | +--rw destination-port-range-or-operator | | | | | +--rw destination-port-range-or-operator
| | | | | +--rw (port-range-or-operator)? | | | | | +--rw (port-range-or-operator)?
| | | | | +--:(range) | | | | | +--:(range)
| | | | | | +--rw lower-port | | | | | | +--rw lower-port
| | | | | | | inet:port-number | | | | | | | inet:port-number
| | | | | | +--rw upper-port | | | | | | +--rw upper-port
| | | | | | inet:port-number | | | | | | inet:port-number
| | | | | +--:(operator) | | | | | +--:(operator)
| | | | | +--rw operator? | | | | | +--rw operator?
| | | | | | operator | | | | | | operator
| | | | | +--rw port | | | | | +--rw port
| | | | | inet:port-number | | | | | inet:port-number
| | | | +--:(udp) | | | | +--:(udp)
| | | | +--rw udp | | | | +--rw udp
| | | | +--rw length? | | | | +--rw length?
| | | | | uint16 | | | | | uint16
| | | | +--rw (source-port)? | | | | +--rw (source-port)?
| | | | | +--:(source-port-range-or-operator) | | | | | +--:(source-port-range-or-operator)
| | | | | +--rw source-port-range-or-operator | | | | | +--rw source-port-range-or-operator
| | | | | +--rw (port-range-or-operator)? | | | | | +--rw (port-range-or-operator)?
| | | | | +--:(range) | | | | | +--:(range)
| | | | | | +--rw lower-port | | | | | | +--rw lower-port
| | | | | | | inet:port-number | | | | | | | inet:port-number
| | | | | | +--rw upper-port | | | | | | +--rw upper-port
| | | | | | inet:port-number | | | | | | inet:port-number
| | | | | +--:(operator) | | | | | +--:(operator)
| | | | | +--rw operator? | | | | | +--rw operator?
| | | | | | operator | | | | | | operator
| | | | | +--rw port | | | | | +--rw port
| | | | | inet:port-number | | | | | inet:port-number
| | | | +--rw (destination-port)? | | | | +--rw (destination-port)?
| | | | +--:(destination-port-range-or-operator) | | | | +--:(destination-port-range-or-operator)
| | | | +--rw destination-port-range-or-operator | | | | +--rw destination-port-range-or-operator
| | | | +--rw (port-range-or-operator)? | | | | +--rw (port-range-or-operator)?
| | | | +--:(range) | | | | +--:(range)
| | | | | +--rw lower-port | | | | | +--rw lower-port
| | | | | | inet:port-number | | | | | | inet:port-number
| | | | | +--rw upper-port | | | | | +--rw upper-port
| | | | | inet:port-number | | | | | inet:port-number
| | | | +--:(operator) | | | | +--:(operator)
| | | | +--rw operator? | | | | +--rw operator?
| | | | | operator | | | | | operator
| | | | +--rw port | | | | +--rw port
| | | | inet:port-number | | | | inet:port-number
... ...
Figure 23: QoS Subtree Structure (L4) Figure 23: QoS Subtree Structure (L4)
* Application match * Application match
7.3.4.3. Multicast 7.3.4.3. Multicast
Multicast MAY be enabled for a particular vpn-network-node (see Multicast MAY be enabled for a particular vpn-network-node (see
Figure 24). Figure 24).
skipping to change at page 44, line 5 skipping to change at page 44, line 5
+--rw peer? inet:ip-address +--rw peer? inet:ip-address
+--rw local-address? inet:ip-address +--rw local-address? inet:ip-address
Figure 24: Multicast Subtree Structure Figure 24: Multicast Subtree Structure
8. Layer 3 Network Model 8. Layer 3 Network Model
This module uses types defined in [RFC6991] and groupings defined in This module uses types defined in [RFC6991] and groupings defined in
[RFC8519]. [RFC8519].
<CODE BEGINS> file "ietf-l3vpn-ntw@2020-09-15.yang" <CODE BEGINS> file "ietf-l3vpn-ntw@2020-10-16.yang"
module ietf-l3vpn-ntw { module ietf-l3vpn-ntw {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw"; namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw";
prefix l3nm; prefix l3nm;
import ietf-vpn-common { import ietf-vpn-common {
prefix vpn-common; prefix vpn-common;
reference reference
"RFC UUUU: A Layer 2/3 VPN Common YANG Model"; "RFC UUUU: A Layer 2/3 VPN Common YANG Model";
} }
skipping to change at page 44, line 37 skipping to change at page 44, line 37
prefix pf; prefix pf;
reference reference
"RFC 8519: YANG Data Model for Network Access "RFC 8519: YANG Data Model for Network Access
Control Lists (ACLs)"; Control Lists (ACLs)";
} }
organization organization
"IETF OPSA (Operations and Management Area) Working Group "; "IETF OPSA (Operations and Management Area) Working Group ";
contact contact
"WG Web: <http://tools.ietf.org/wg/opsawg/> "WG Web: <http://tools.ietf.org/wg/opsawg/>
WG List: <mailto:opsawg@ietf.org> WG List: <mailto:opsawg@ietf.org>
Editor: Samier Barguil Editor: Samier Barguil
<mailto:samier.barguilgiraldo.ext@telefonica.com> <mailto:samier.barguilgiraldo.ext@telefonica.com>
Editor: Oscar Gonzalez de Dios Editor: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com> <mailto:oscar.gonzalezdedios@telefonica.com>
Editor: Mohamed Boucadair Editor: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Author: Luis Angel Munoz Author: Luis Angel Munoz
<mailto:luis-angel.munoz@vodafone.com> <mailto:luis-angel.munoz@vodafone.com>
Author: Alejandro Aguado Author: Alejandro Aguado
<mailto:alejandro.aguado_martin@nokia.com> <mailto:alejandro.aguado_martin@nokia.com>
"; ";
description description
"This YANG module defines a generic network-oriented model "This YANG module defines a generic network-oriented model
for the configuration of Layer 3 Virtual Private Networks. for the configuration of Layer 3 Virtual Private Networks.
Copyright (c) 2020 IETF Trust and the persons identified as Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices."; for full legal notices.";
revision 2020-09-15 { revision 2020-10-16 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A Layer 3 VPN Network YANG Model"; "RFC XXXX: A Layer 3 VPN Network YANG Model";
} }
/* Features */ /* Features */
feature msdp { feature msdp {
description description
skipping to change at page 56, line 30 skipping to change at page 56, line 30
"Encapsulation types"; "Encapsulation types";
} }
container ip-connection { container ip-connection {
container ipv4 { container ipv4 {
if-feature "vpn-common:ipv4"; if-feature "vpn-common:ipv4";
leaf address-allocation-type { leaf address-allocation-type {
type identityref { type identityref {
base address-allocation-type; base address-allocation-type;
} }
must "not(derived-from-or-self(current(), " must "not(derived-from-or-self(current(), "
+ "'slaac') or derived-from-or-self(current()," + "'slaac') or derived-from-or-self(current(),"
+ " 'provider-dhcp-slaac'))" { + " 'provider-dhcp-slaac'))" {
error-message "SLAAC is only applicable to error-message "SLAAC is only applicable to
IPv6"; IPv6";
} }
description description
"Defines how addresses are allocated. "Defines how addresses are allocated.
If there is no value for the address If there is no value for the address
allocation type, then IPv4 is not enabled."; allocation type, then IPv4 is not enabled.";
} }
choice allocation-type { choice allocation-type {
case provider-dhcp { case provider-dhcp {
when "derived-from-or-self(./address-" when "derived-from-or-self(./address-"
+ "allocation-type, 'provider-dhcp')" { + "allocation-type, 'provider-dhcp')" {
skipping to change at page 95, line 10 skipping to change at page 95, line 10
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
[RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco
Systems' Solution for Multicast in BGP/MPLS IP VPNs", Systems' Solution for Multicast in BGP/MPLS IP VPNs",
RFC 6037, DOI 10.17487/RFC6037, October 2010, RFC 6037, DOI 10.17487/RFC6037, October 2010,
<https://www.rfc-editor.org/info/rfc6037>. <https://www.rfc-editor.org/info/rfc6037>.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982,
DOI 10.17487/RFC6982, July 2013,
<https://www.rfc-editor.org/info/rfc6982>.
[RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., [RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E.,
and W. George, "Enhanced Duplicate Address Detection", and W. George, "Enhanced Duplicate Address Detection",
RFC 7527, DOI 10.17487/RFC7527, April 2015, RFC 7527, DOI 10.17487/RFC7527, April 2015,
<https://www.rfc-editor.org/info/rfc7527>. <https://www.rfc-editor.org/info/rfc7527>.
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>. <https://www.rfc-editor.org/info/rfc8277>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
skipping to change at page 95, line 32 skipping to change at page 95, line 37
<https://www.rfc-editor.org/info/rfc8299>. <https://www.rfc-editor.org/info/rfc8299>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>. <https://www.rfc-editor.org/info/rfc8309>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>. 2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349, Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018, DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>. <https://www.rfc-editor.org/info/rfc8349>.
skipping to change at page 100, line 32 skipping to change at page 100, line 32
A.2. Multicast VPN Provisioning Example A.2. Multicast VPN Provisioning Example
IPTV is mainly distributed through multicast over the LANs. In the IPTV is mainly distributed through multicast over the LANs. In the
following example, PIM-SM is enabled and functional between the PE following example, PIM-SM is enabled and functional between the PE
and the CE. The PE receives multicast traffic from a CE that is and the CE. The PE receives multicast traffic from a CE that is
directly connected to the multicast source. The signaling between PE directly connected to the multicast source. The signaling between PE
and CE is achieved using BGP. Also, RP is statically configured for and CE is achieved using BGP. Also, RP is statically configured for
a multicast group. a multicast group.
+-----------+ +------+ +------+ +-----------+ +-----------+ +------+ +------+ +-----------+
| Multicast |---| CE |--/--| PE |----| Backbone | | Multicast |---| CE |--/--| PE |----| Backbone |
| source | +------+ +------+ | IP/MPLS | | source | +------+ +------+ | IP/MPLS |
+-----------+ +-----------+ +-----------+ +-----------+
Figure 30: Multicast L3VPN Service Example Figure 30: Multicast L3VPN Service Example
To configure a Multicast L3VPN service using the L3NM model the To configure a Multicast L3VPN service using the L3NM model the
procedure and the JSON with the data structure is the following: procedure and the JSON with the data structure is the following:
First, the multicast service is created (see the excerpt of the First, the multicast service is created (see the excerpt of the
request message body shown in Figure 31) request message body shown in Figure 31)
{ {
"ietf-l3vpn-ntw:vpn-services": { "ietf-l3vpn-ntw:vpn-services": {
skipping to change at page 104, line 9 skipping to change at page 104, line 9
"protocol-type": "router" "protocol-type": "router"
} }
} }
} }
} }
Figure 33: Create VPN Network Access (Excerpt of the Message Request Figure 33: Create VPN Network Access (Excerpt of the Message Request
Body) Body)
Appendix B. Implementation Status Appendix B. Implementation Status
This section records the status of known implementations of the Yang
module defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC6982], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
Note the RFC Editor: As per [RFC6982] guidelines, please remove this
Implementation Status apendix prior publication.
B.1. Nokia Implementation B.1. Nokia Implementation
Details can be found at: https://github.com/IETF-OPSAWG- Details can be found at: https://github.com/IETF-OPSAWG-
WG/l3nm/blob/master/Implementattion/Nokia.txt WG/l3nm/blob/master/Implementattion/Nokia.txt
B.2. Huawei Implementation B.2. Huawei Implementation
Details can be found at: https://github.com/IETF-OPSAWG- Details can be found at: https://github.com/IETF-OPSAWG-
WG/l3nm/blob/master/Implementattion/Huawei.txt WG/l3nm/blob/master/Implementattion/Huawei.txt
 End of changes. 19 change blocks. 
224 lines changed or deleted 260 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/