draft-ietf-opsawg-l3sm-l3nm-16.txt   draft-ietf-opsawg-l3sm-l3nm-17.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: 3 April 2022 M. Boucadair, Ed. Expires: 7 April 2022 M. Boucadair, Ed.
Orange Orange
L. Munoz L. Munoz
Vodafone Vodafone
A. Aguado A. Aguado
Nokia Nokia
30 September 2021 4 October 2021
A Layer 3 VPN Network YANG Model A Layer 3 VPN Network YANG Model
draft-ietf-opsawg-l3sm-l3nm-16 draft-ietf-opsawg-l3sm-l3nm-17
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 3 April 2022. This Internet-Draft will expire on 7 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 3, line 14 skipping to change at page 3, line 14
7.6. VPN Network Accesses . . . . . . . . . . . . . . . . . . 25 7.6. VPN Network Accesses . . . . . . . . . . . . . . . . . . 25
7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 28 7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 28
7.6.2. IP Connection . . . . . . . . . . . . . . . . . . . . 30 7.6.2. IP Connection . . . . . . . . . . . . . . . . . . . . 30
7.6.3. CE-PE Routing Protocols . . . . . . . . . . . . . . . 33 7.6.3. CE-PE Routing Protocols . . . . . . . . . . . . . . . 33
7.6.3.1. Static Routing . . . . . . . . . . . . . . . . . 35 7.6.3.1. Static Routing . . . . . . . . . . . . . . . . . 35
7.6.3.2. BGP . . . . . . . . . . . . . . . . . . . . . . . 37 7.6.3.2. BGP . . . . . . . . . . . . . . . . . . . . . . . 37
7.6.3.3. OSPF . . . . . . . . . . . . . . . . . . . . . . 40 7.6.3.3. OSPF . . . . . . . . . . . . . . . . . . . . . . 40
7.6.3.4. IS-IS . . . . . . . . . . . . . . . . . . . . . . 42 7.6.3.4. IS-IS . . . . . . . . . . . . . . . . . . . . . . 42
7.6.3.5. RIP . . . . . . . . . . . . . . . . . . . . . . . 44 7.6.3.5. RIP . . . . . . . . . . . . . . . . . . . . . . . 44
7.6.3.6. VRRP . . . . . . . . . . . . . . . . . . . . . . 45 7.6.3.6. VRRP . . . . . . . . . . . . . . . . . . . . . . 45
7.6.4. OAM . . . . . . . . . . . . . . . . . . . . . . . . . 46 7.6.4. OAM . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.6.5. Security . . . . . . . . . . . . . . . . . . . . . . 48 7.6.5. Security . . . . . . . . . . . . . . . . . . . . . . 48
7.6.6. Services . . . . . . . . . . . . . . . . . . . . . . 48 7.6.6. Services . . . . . . . . . . . . . . . . . . . . . . 49
7.6.6.1. Overview . . . . . . . . . . . . . . . . . . . . 48 7.6.6.1. Overview . . . . . . . . . . . . . . . . . . . . 49
7.6.6.2. QoS . . . . . . . . . . . . . . . . . . . . . . . 50 7.6.6.2. QoS . . . . . . . . . . . . . . . . . . . . . . . 50
7.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 55 7.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 55
8. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 59 8. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 59
9. Security Considerations . . . . . . . . . . . . . . . . . . . 121 9. Security Considerations . . . . . . . . . . . . . . . . . . . 121
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 122 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 122
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 123 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 123
11.1. Normative References . . . . . . . . . . . . . . . . . . 123 11.1. Normative References . . . . . . . . . . . . . . . . . . 123
11.2. Informative References . . . . . . . . . . . . . . . . . 127 11.2. Informative References . . . . . . . . . . . . . . . . . 127
Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 132 Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 132
A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 132 A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 132
skipping to change at page 40, line 20 skipping to change at page 40, line 20
action indicated in 'violate-action' will be followed. action indicated in 'violate-action' will be followed.
'warning-threshold': A warning notification is triggered when 'warning-threshold': A warning notification is triggered when
this limit is reached. this limit is reached.
'violate-action': Indicates which action to execute when the 'violate-action': Indicates which action to execute when the
maximum number of BGP prefixes is reached. Examples of such maximum number of BGP prefixes is reached. Examples of such
actions are: send a warning message, discard extra paths from actions are: send a warning message, discard extra paths from
the peer, or restart the session. the peer, or restart the session.
'restart-timer': Indicates, in seconds, the time interval after
which the BGP session will be reestablished.
'bgp-timers': Two timers can be captured in this container: (1) 'bgp-timers': Two timers can be captured in this container: (1)
'hold-time' which is the time interval that will be used for the 'hold-time' which is the time interval that will be used for the
HoldTimer (Section 4.2 of [RFC4271]) when establishing a BGP HoldTimer (Section 4.2 of [RFC4271]) when establishing a BGP
session. (2) 'keepalive' which is the time interval for the session. (2) 'keepalive' which is the time interval for the
KeepAlive timer between a PE and a BGP peer (Section 4.4 of KeepAlive timer between a PE and a BGP peer (Section 4.4 of
[RFC4271]). [RFC4271]). Both timers are expressed in seconds.
'authentication': The module adheres to the recommendations in 'authentication': The module adheres to the recommendations in
Section 13.2 of [RFC4364] as it allows enabling TCP-AO [RFC5925] Section 13.2 of [RFC4364] as it allows enabling TCP-AO [RFC5925]
and accommodates the installed base that makes use of MD5. In and accommodates the installed base that makes use of MD5. In
addition, the module includes a provision for the use of IPsec. addition, the module includes a provision for the use of IPsec.
This version of the L3NM assumes that TCP-AO specific parameters This version of the L3NM assumes that TCP-AO specific parameters
are preconfigured as part of the key-chain that is referenced in are preconfigured as part of the key-chain that is referenced in
the L3NM. No assumption is made about how such a key-chain is the L3NM. No assumption is made about how such a key-chain is
pre-configured. However, the structure of the key-chain should pre-configured. However, the structure of the key-chain should
skipping to change at page 44, line 10 skipping to change at page 44, line 10
'mode': Indicates the IS-IS interface mode type. It can be set to 'mode': Indicates the IS-IS interface mode type. It can be set to
'active' (that is, send or receive IS-IS protocol control packets) 'active' (that is, send or receive IS-IS protocol control packets)
or 'passive' (that is, suppress the sending of IS-IS updates or 'passive' (that is, suppress the sending of IS-IS updates
through the interface). through the interface).
'authentication': Controls the authentication schemes to be enabled 'authentication': Controls the authentication schemes to be enabled
for the IS-IS instance. Both the specification of a key-chain for the IS-IS instance. Both the specification of a key-chain
[RFC8177] and the direct specification of key and authentication [RFC8177] and the direct specification of key and authentication
algorithm are supported. algorithm are supported.
'status': Indicates the status of the OSPF routing instance. 'status': Indicates the status of the IS-IS routing instance.
7.6.3.5. RIP 7.6.3.5. RIP
The model (Figure 19) allows the user to configure RIP to run on the The model (Figure 19) allows the user to configure RIP to run on the
'vpn-network-access' interface. 'vpn-network-access' interface.
... ...
+--rw routing-protocols +--rw routing-protocols
| +--rw routing-protocol* [id] | +--rw routing-protocol* [id]
| ... | ...
skipping to change at page 45, line 22 skipping to change at page 45, line 22
'invalid-interval': Is the interval before a RIP route is 'invalid-interval': Is the interval before a RIP route is
declared invalid. declared invalid.
'holddown-interval': Is the interval before better RIP routes are 'holddown-interval': Is the interval before better RIP routes are
released. released.
'flush-interval': Is the interval before a route is removed from 'flush-interval': Is the interval before a route is removed from
the routing table. the routing table.
These timers are expressed in seconds.
'default-metric': Sets the default RIP metric. 'default-metric': Sets the default RIP metric.
'authentication': Controls the authentication schemes to be enabled 'authentication': Controls the authentication schemes to be enabled
for the RIP instance. for the RIP instance.
'status': Indicates the status of the RIP routing instance. 'status': Indicates the status of the RIP routing instance.
7.6.3.6. VRRP 7.6.3.6. VRRP
The model (Figure 20) allows enabling VRRP on the 'vpn-network- The model (Figure 20) allows enabling VRRP on the 'vpn-network-
skipping to change at page 47, line 46 skipping to change at page 47, line 52
that a PE would like to use when transmitting BFD Control packets that a PE would like to use when transmitting BFD Control packets
less any jitter applied. less any jitter applied.
'required-min-rx-interval': Is the minimum interval, in 'required-min-rx-interval': Is the minimum interval, in
microseconds, between received BFD Control packets that a PE is microseconds, between received BFD Control packets that a PE is
capable of supporting, less any jitter applied by the sender. capable of supporting, less any jitter applied by the sender.
'local-multiplier': The negotiated transmit interval, multiplied by 'local-multiplier': The negotiated transmit interval, multiplied by
this value, provides the detection time for the peer. this value, provides the detection time for the peer.
'holdtime': Is used to indicate the expected BFD holddown time. 'holdtime': Is used to indicate the expected BFD holddown time, in
This value may be inherited from the service request (see milliseconds. This value may be inherited from the service
Section 6.3.2.2.2 of [RFC8299]). request (see Section 6.3.2.2.2 of [RFC8299]).
'profile': Refers to a BFD profile (Section 7.2). Such a profile 'profile': Refers to a BFD profile (Section 7.2). Such a profile
can be set by the provider or inherited from the service request can be set by the provider or inherited from the service request
(see Section 6.3.2.2.2 of [RFC8299]). (see Section 6.3.2.2.2 of [RFC8299]).
'authentication': Includes the required information to enable the 'authentication': Includes the required information to enable the
BFD authentication modes discussed in Section 6.7 of [RFC5880]. BFD authentication modes discussed in Section 6.7 of [RFC5880].
In particular 'meticulous' controls the activation of the In particular 'meticulous' controls the activation of the
meticulous mode discussed in Sections 6.7.3 and 6.7.4 of meticulous mode discussed in Sections 6.7.3 and 6.7.4 of
[RFC5880]. [RFC5880].
skipping to change at page 49, line 36 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 the inbound bandwidth of the 'inbound-bandwidth': Indicates, in bytes per second (bps), the
connection (i.e., download bandwidth from the service provider to inbound bandwidth of the connection (i.e., download bandwidth from
the site). the service provider to the site).
'outbound-bandwidth': Indicates the outbound bandwidth of the 'outbound-bandwidth': Indicates, in bps, the outbound bandwidth of
connection (i.e., upload bandwidth from the site to the service the connection (i.e., upload bandwidth from the site to the
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
connection (refer to Section 7.6.6.2 for more details). connection (refer to Section 7.6.6.2 for more details).
'carriers-carrier': Groups a set of parameters that are used when 'carriers-carrier': Groups a set of parameters that are used when
Carriers' Carriers (CsC) is enabled such the use of BGP for Carriers' Carriers (CsC) is enabled such the use of BGP for
signaling purposes [RFC8277]. signaling purposes [RFC8277].
skipping to change at page 109, line 35 skipping to change at page 109, line 35
"The minimum interval between transmission of "The minimum interval between transmission of
BFD control packets that the operator BFD control packets that the operator
desires."; desires.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection "RFC 5880: Bidirectional Forwarding Detection
(BFD), Section 6.8.7"; (BFD), Section 6.8.7";
} }
leaf required-min-rx-interval { leaf required-min-rx-interval {
type uint32; type uint32;
units "microseconds"; units "microseconds";
default "1000000";
description description
"The minimum interval between received BFD "The minimum interval between received BFD
control packets that the PE should support."; control packets that the PE should support.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection "RFC 5880: Bidirectional Forwarding Detection
(BFD), Section 6.8.7"; (BFD), Section 6.8.7";
} }
leaf local-multiplier { leaf local-multiplier {
type uint8 { type uint8 {
range "1..255"; range "1..255";
skipping to change at page 110, line 12 skipping to change at page 110, line 13
The detection interval for the receiving The detection interval for the receiving
BFD peer is calculated by multiplying the value BFD peer is calculated by multiplying the value
of the negotiated transmission interval by of the negotiated transmission interval by
the received detection multiplier value."; the received detection multiplier value.";
reference reference
"RFC 5880: Bidirectional Forwarding Detection "RFC 5880: Bidirectional Forwarding Detection
(BFD), Section 6.8.7"; (BFD), Section 6.8.7";
} }
leaf holdtime { leaf holdtime {
type uint32; type uint32;
units "msec"; units "milliseconds";
description description
"Expected BFD holdtime. "Expected BFD holdtime.
The customer may impose some fixed The customer may impose some fixed
values for the holdtime period if the values for the holdtime period if the
provider allows the customer use of provider allows the customer use of
this function. this function.
If the provider doesn't allow the If the provider doesn't allow the
customer to use this function, customer to use this function,
skipping to change at page 111, line 33 skipping to change at page 111, line 34
type boolean; type boolean;
default "false"; default "false";
description description
"If true, traffic encryption on the "If true, traffic encryption on the
connection is required. Otherwise, it connection is required. Otherwise, it
is disabled."; is disabled.";
} }
leaf layer { leaf layer {
when "../enabled = 'true'" { when "../enabled = 'true'" {
description description
"It is included only when enryption "It is included only when encryption
is enabled."; is enabled.";
} }
type enumeration { type enumeration {
enum layer2 { enum layer2 {
description description
"Encryption occurs at Layer 2."; "Encryption occurs at Layer 2.";
} }
enum layer3 { enum layer3 {
description description
"Encryption occurs at Layer 3. "Encryption occurs at Layer 3.
skipping to change at page 120, line 51 skipping to change at page 121, line 4
"Indicates the preference in the DR election "Indicates the preference in the DR election
process. A larger value has a higher process. A larger value has a higher
priority over a smaller value."; priority over a smaller value.";
reference reference
"RFC 7761: Protocol Independent Multicast - "RFC 7761: Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol Sparse Mode (PIM-SM): Protocol
Specification (Revised), Specification (Revised),
Section 4.3.2"; Section 4.3.2";
} }
uses vpn-common:service-status; uses vpn-common:service-status;
}
}
} }
} }
} }
} }
} }
} }
} }
} }
} }
} }
skipping to change at page 133, line 29 skipping to change at page 133, line 29
{ {
"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": "vpn-common:dual-stack",
"vpn-targets": { "vpn-targets": {
"vpn-target": [ "vpn-target": [
{ {
"id": "1", "id": 1,
"route-targets": [ "route-targets": [
"0:65550:1" "0:65550:1"
], ],
"route-target-type": "both" "route-target-type": "both"
} }
] ]
} }
} }
] ]
} }
skipping to change at page 142, line 23 skipping to change at page 142, line 23
"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": "vpn-common:static-rp"
} }
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, and Benjamin Kaduk Zaheduzzaman Sarker, Roman Danyliw, Erik Kline, Benjamin Kaduk, and
for the IESG review. Francesca Palombini 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. 22 change blocks. 
26 lines changed or deleted 32 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/