--- 1/draft-ietf-opsawg-l3sm-l3nm-10.txt 2021-09-09 23:13:12.930326779 -0700 +++ 2/draft-ietf-opsawg-l3sm-l3nm-11.txt 2021-09-09 23:13:13.230334296 -0700 @@ -1,47 +1,47 @@ -OPSAWG S. Barguil -Internet-Draft O. Gonzalez de Dios, Ed. +OPSAWG S.B. Barguil +Internet-Draft O.G.D. Gonzalez de Dios, Ed. Intended status: Standards Track Telefonica -Expires: January 14, 2022 M. Boucadair, Ed. +Expires: 14 March 2022 M. Boucadair, Ed. Orange - L. Munoz + L.A. Munoz Vodafone - A. Aguado + A.A. Aguado Nokia - July 13, 2021 + 10 September 2021 A Layer 3 VPN Network YANG Model - draft-ietf-opsawg-l3sm-l3nm-10 + draft-ietf-opsawg-l3sm-l3nm-11 Abstract This document defines an L3VPN Network YANG Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (VPN) services within a service provider network. The model provides a network-centric view of L3VPN services. L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate the communication between a service orchestrator and a network controller/orchestrator. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: - o "This version of this YANG module is part of RFC XXXX;" + * "This version of this YANG module is part of RFC XXXX;" - o "RFC XXXX: Layer 3 VPN Network Model"; + * "RFC XXXX: Layer 3 VPN Network Model"; - o reference: RFC XXXX + * reference: RFC XXXX Please update "RFC UUUU" to the RFC number to be assigned to I- D.ietf-opsawg-vpn-common. Also, please update the "revision" date of the YANG module. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -49,36 +49,35 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 14, 2022. + This Internet-Draft will expire on 14 March 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (https://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. + Provisions Relating to IETF Documents (https://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Code Components + extracted from this document must include Simplified BSD License text + as described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. L3NM Reference Architecture . . . . . . . . . . . . . . . . . 7 5. Relation with other YANG Models . . . . . . . . . . . . . . . 10 6. Sample Uses of the L3NM Data Model . . . . . . . . . . . . . 11 6.1. Enterprise Layer 3 VPN Services . . . . . . . . . . . . . 11 @@ -88,41 +87,43 @@ 7.1. Overall Structure of the Module . . . . . . . . . . . . . 13 7.2. VPN Profiles . . . . . . . . . . . . . . . . . . . . . . 13 7.3. VPN Services . . . . . . . . . . . . . . . . . . . . . . 15 7.4. VPN Instance Profiles . . . . . . . . . . . . . . . . . . 18 7.5. VPN Nodes . . . . . . . . . . . . . . . . . . . . . . . . 20 7.6. VPN Network Access . . . . . . . . . . . . . . . . . . . 23 7.6.1. Connection . . . . . . . . . . . . . . . . . . . . . 26 7.6.2. IP Connection . . . . . . . . . . . . . . . . . . . . 27 7.6.3. CE-PE Routing Protocols . . . . . . . . . . . . . . . 31 7.6.4. OAM . . . . . . . . . . . . . . . . . . . . . . . . . 43 - 7.6.5. Security . . . . . . . . . . . . . . . . . . . . . . 44 + 7.6.5. Security . . . . . . . . . . . . . . . . . . . . . . 45 7.6.6. Services . . . . . . . . . . . . . . . . . . . . . . 45 7.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 51 8. L3NM YANG Module . . . . . . . . . . . . . . . . . . . . . . 55 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 115 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 116 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 117 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 11.1. Normative References . . . . . . . . . . . . . . . . . . 117 11.2. Informative References . . . . . . . . . . . . . . . . . 121 - Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 125 - A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 125 - A.2. Loopback Interface . . . . . . . . . . . . . . . . . . . 130 - A.3. Multicast VPN Provisioning Example . . . . . . . . . . . 130 - Appendix B. Implementation Status . . . . . . . . . . . . . . . 135 - B.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 135 - B.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 135 - B.3. Infinera Implementation . . . . . . . . . . . . . . . . . 135 - B.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 135 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 136 - Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 136 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 137 + Appendix A. L3VPN Examples . . . . . . . . . . . . . . . . . . . 126 + A.1. 4G VPN Provisioning Example . . . . . . . . . . . . . . . 126 + A.2. Loopback Interface . . . . . . . . . . . . . . . . . . . 131 + A.3. Overriding VPN Instance Profile Parameters . . . . . . . 132 + A.4. Multicast VPN Provisioning Example . . . . . . . . . . . 135 + Appendix B. Implementation Status . . . . . . . . . . . . . . . 139 + B.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 139 + B.2. Huawei Implementation . . . . . . . . . . . . . . . . . . 139 + B.3. Infinera Implementation . . . . . . . . . . . . . . . . . 139 + B.4. Ribbon-ECI Implementation . . . . . . . . . . . . . . . . 139 + B.5. Juniper Implementation . . . . . . . . . . . . . . . . . 140 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 140 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 140 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141 1. Introduction [RFC8299] defines a Layer 3 Virtual Private Network Service YANG data Model (L3SM) that can be used for communication between customers and network operators. Such a model focuses on describing the customer view of the Virtual Private Network (VPN) services and provides an abstracted view of the customer's requested services. That approach limits the usage of the L3SM to the role of a customer service model (as per [RFC8309]). @@ -146,21 +147,21 @@ The L3NM YANG module was initially built with a prune and extend approach, taking as a starting points the YANG module described in [RFC8299]. Nevertheless, the L3NM is not defined as an augment to L3SM because a specific structure is required to meet network- oriented L3 needs. Some information captured in the L3SM can be passed by the orchestrator in the L3NM (e.g., customer) or be used to feed some L3NM attributes (e.g., actual forwarding policies). Also, some information captured in the L3SM may be maintained locally within the - orchestrator; which is in charge of maintaining the correspondence + orchestrator; which is in charge of maintaining the correlation between a customer view and its network instantiation. Likewise, some information captured and exposed using the L3NM can feed the service layer (e.g., capabilities) to drive VPN service order handling, and thus the L3SM. Section 5.1 of [RFC8969] illustrates how the L3NM can be used within the network management automation architecture. The L3NM does not attempt to address all deployment cases, especially those where the L3VPN connectivity is supported through the @@ -236,23 +237,23 @@ into a Virtual Routing and Forwarding (VRF). VPN network access: An abstraction that represents the network interfaces that are associated to a given VPN node. Traffic coming from the VPN network access belongs to the VPN. The attachment circuits (bearers) between CEs and PEs are terminated in the VPN network access. A reference to the bearer is maintained to allow keeping the link between L3SM and L3NM when both models are used in a given deployment. - VPN site: A VPN customer's location that is connected to the - service provider network via a CE-PE link, which can access at - least one VPN [RFC4176]. + VPN site: A VPN customer's location that is connected to the service + provider network via a CE-PE link, which can access at least one + VPN [RFC4176]. VPN service provider: A service provider that offers VPN-related services [RFC4176]. Service provider network: A network that is able to provide VPN- related services. The document is aimed at modeling BGP PE-based VPNs in a service provider network, so the terms defined in [RFC4026] and [RFC4176] are used. @@ -262,20 +263,21 @@ The following acronyms are used in the document: ACL Access Control List AS Autonomous System ASM Any-Source Multicast ASN AS Number BSR Bootstrap Router BFD Bidirectional Forwarding Detection BGP Border Gateway Protocol CE Customer Edge + CsC Carriers' Carriers IGMP Internet Group Management Protocol L3VPN Layer 3 Virtual Private Network L3SM L3VPN Service Model L3NM L3VPN Network Model MLD Multicast Listener Discovery MSDP Multicast Source Discovery Protocol MVPN Multicast VPN NAT Network Address Translation OAM Operations, Administration, and Maintenance OSPF Open Shortest Path First @@ -449,22 +451,24 @@ provider and do not map directly to L3SM. Note that the use of L3NM within a service provider does not assume nor preclude exposing the VPN service via the L3SM. This is deployment-specific. Nevertheless, the design of L3NM tries to align as much as possible with the features supported by the L3SM to ease grafting both L3NM and L3SM for the sake of highly automated VPN service provisioning and delivery. Network Topology Modules: An L3VPN involves nodes that are part of a - topology managed by the service provider network. Such topology - can be represented using the network topology module in [RFC8345]. + topology managed by the service provider network. The topology + can be represented using the network topology YANG module defined + in [RFC8345] or its extension such as a User-Network Interface + (UNI) topology module (e.g., [I-D.ogondio-opsawg-uni-topology]). Device Modules: L3NM is not a device model. Once a global VPN service is captured by means of L3NM, the actual activation and provisioning of the VPN service will involve a variety of device modules to tweak the required functions for the delivery of the service. These functions are supported by the VPN nodes and can be managed using device YANG modules. A non- comprehensive list of such device YANG modules is provided below: @@ -492,39 +496,38 @@ Enterprise L3VPNs are one of the most demanded services for carriers, and therefore, L3NM can be useful to automate the provisioning and maintenance of these VPNs. Templates and batch processes can be built, and as a result many parameters are needed for the creation from scratch of a VPN that can be abstracted to the upper Software- Defined Networking (SDN) [RFC7149][RFC7426] layer, but some manual intervention will still be required. A common function that is supported by VPNs is the addition or - removal of customer sites. Workflows can use the L3NM in these - scenarios to add or prune nodes from the network data model as - required. + removal of VPN nodes. Workflows can use the L3NM in these scenarios + to add or prune nodes from the network data model as required. 6.2. Multi-Domain Resource Management The implementation of L3VPN services which span across administratively separated domains (i.e., that are under the administration of different management systems or controllers) requires some network resources to be synchronized between systems. Particularly, resources must be adequately managed in each domain to avoid broken configuration. For example, route targets (RTs) shall be synchronized between PEs. When all PEs are controlled by the same management system, RT allocation can be performed by that management system. In cases where the service spans across multiple management systems, the task of allocating RTs has to be aligned across the domains, therefore, - the service model must provide a way to specify RTs. In addition, + the network model must provide a way to specify RTs. In addition, route distinguishers (RDs) must also be synchronized to avoid collisions in RD allocation between separate management systems. An incorrect allocation might lead to the same RD and IP prefixes being exported by different PEs. 6.3. Management of Multicast Services Multicast services over L3VPN can be implemented using dual PIM MVPNs (also known as, Draft Rosen model) [RFC6037] or Multiprotocol BGP (MP-BGP)-based MVPNs [RFC6513][RFC6514]. Both methods are supported @@ -806,21 +809,21 @@ +--rw vpn-profiles | ... +--rw vpn-services +--rw vpn-service* [vpn-id] +--rw vpn-id vpn-common:vpn-id ... +--rw vpn-instance-profiles | +--rw vpn-instance-profile* [profile-id] | +--rw profile-id string | +--rw role? identityref - | +--rw local-autonomous-system? inet:as-number + | +--rw local-as? inet:as-number | | {vpn-common:rtg-bgp}? | +--rw (rd-choice)? | | +--:(directly-assigned) | | | +--rw rd? | | | rt-types:route-distinguisher | | +--:(directly-assigned-suffix) | | | +--rw rd-suffix? uint16 | | +--:(auto-assigned) | | | +--rw rd-auto | | | +--rw (auto-mode)? @@ -862,24 +865,24 @@ Figure 6: Subtree Structure of VPN Instance Profiles The description of the listed data nodes is as follows: 'profile-id': Is used to uniquely identify a VPN instance profile. 'role': Indicates the role of the VPN instance profile in the VPN. Role values are defined in [I-D.ietf-opsawg-vpn-common] (e.g., any-to-any-role, spoke-role, hub-role). - 'local-autonomous-system': Indicates the Autonomous System Number - (ASN) that is configured for the VPN node. + 'local-as': Indicates the Autonomous System Number (ASN) that is + configured for the VPN node. - 'rd': As defined in [I-D.ietf-opsawg-vpn-common], these RD + 'rd': As defined in [I-D.ietf-opsawg-vpn-common], the following RD assignment modes are supported: direct assignment, automatic assignment from a given pool, automatic assignment, and no assignment. For illustration purposes, the following modes can be used in the deployment cases: 'directly-assigned': The VPN service provider (service orchestrator) assigns explicitly RDs. This case will fit with a brownfield scenario where some existing services need to be updated by the VPN service provider. @@ -929,30 +932,30 @@ +--rw vpn-profiles | ... +--rw vpn-services +--rw vpn-service* [vpn-id] ... +--rw vpn-nodes +--rw vpn-node* [vpn-node-id] +--rw vpn-node-id vpn-common:vpn-id +--rw description? string +--rw ne-id? string - +--rw local-autonomous-system? inet:as-number + +--rw local-as? inet:as-number | {vpn-common:rtg-bgp}? +--rw router-id? rt-types:router-id +--rw active-vpn-instance-profiles | +--rw vpn-instance-profile* [profile-id] | +--rw profile-id leafref | +--rw router-id* [address-family] | | +--rw address-family identityref | | +--rw router-id? inet:ip-address - | +--rw local-autonomous-system? inet:as-number + | +--rw local-as? inet:as-number | | {vpn-common:rtg-bgp}? | +--rw (rd-choice)? | | .... | +--rw address-family* [address-family] | | +--rw address-family identityref | | | ... | | +--rw vpn-targets | | | ... | | +--rw maximum-routes* [protocol] | | ... @@ -1005,21 +1008,22 @@ profiles that are defined at the VPN service level can be enabled at the VPN node level; each of these profiles is uniquely identified by means of 'profile-id'. The structure of 'active- vpn-instance-profiles' is the same as the one discussed in Section 7.4 except 'router-id'. Indeed, Router IDs can be configured per address family. This capability can be used, for example, to configure an IPv6 address as a Router ID when such capability is supported by involved routers. Values defined in 'active-vpn-instance-profiles' overrides the - ones defined in the VPN service level. + ones defined in the VPN service level. An example is shown in + Appendix A.3. 'msdp': For redundancy purposes, Multicast Source Discovery Protocol (MSDP) [RFC3618] may be enabled and used to share the state about sources between multiple rendez-vous points (RPs). The purpose of MSDP in this context is to enhance the robustness of the multicast service. MSDP may be configured on non-RP routers, which is useful in a domain that does not support multicast sources, but does support multicast transit. 'groups': Lists the groups to which a VPN node belongs to @@ -1435,26 +1440,26 @@ automatically imply that, from a device configuration perspective, there will be parallel instances (e.g., multiple processes) running on the PE-CE link. It is up to each implementation to decide about the appropriate configuration as a function of underlying capabilities and service provider operational guidelines. As an example, when multiple BGP peers need to be implemented, multiple instances of BGP must be configured as part of this model. However, from a device configuration point of view, this could be implemented as: - o Multiple BGP processes with a single neighbor running in each + * Multiple BGP processes with a single neighbor running in each process. - o A single BGP process with multiple neighbors running. + * A single BGP process with multiple neighbors running. - o A combination thereof. + * A combination thereof. Routing configuration does not include low-level policies. Such policies are handled at the device configuration level. Local policies of a service provider (e.g., filtering) are implemented as part of the device configuration; these are not captured in the L3NM, but the model allows local profiles to be associated with routing instances ('routing-profiles'). The L3NM supports the configuration of one or more IPv4/IPv6 static routes. Since the same structure is used for both IPv4 and IPv6, it @@ -1474,22 +1479,22 @@ static route entry. 'metric': Indicates the metric associated with the static route entry. 'preference': Indicates the preference associated with the static route entry. This preference is used to selecting a preferred route among routes to the same destination prefix. 'status': Used to convey the status of a static route entry. This - data node is used to control the (de)activation of individual - static route entries. + data node can also be used to control the (de)activation of + individual static route entries. ... +--rw routing-protocols | +--rw routing-protocol* [id] | ... | +--rw static | | +--rw cascaded-lan-prefixes | | +--rw ipv4-lan-prefixes* | | | [lan next-hop] | | | {vpn-common:ipv4}? @@ -1535,69 +1540,77 @@ This container does not aim to include every BGP parameter; a comprehensive set of parameters belongs more to the BGP device model. The following data nodes are captured in Figure 16. It is up to the implementation to derive the corresponding BGP device configuration: 'description': Includes a description of the BGP session. - 'local-autonomous-system': Indicates a local AS Number (ASN) if a - distinct ASN is required, other than the one configured at the - VPN node level. + 'local-as': Indicates a local AS Number (ASN) if a distinct ASN + is required, other than the one configured at the VPN node + level. - 'peer-autonomous-system': Conveys the customer's ASN. + 'peer-as': Conveys the customer's ASN. 'address-family': Indicates the address-family of the peer. It can be set to IPv4, IPv6, or dual-stack. + This address family will be used together with the 'vpn-type' + to derive the appropriate Address Family Identifiers + (AFIs)/Subsequent Address Family Identifiers (SAFIs) that will + be part of the derived device configurations (e.g., Unicast + IPv4 MPLS L3VPN (AFI,SAFI = 1,128) defined in Section 4.3.4 of + [RFC4364]). + 'local-address': Specifies an address or a reference to an interface to use when establishing the BGP transport session. 'neighbor': Can indicate two neighbors (each for a given address- family) or one neighbor (if 'address-family' attribute is set to dual-stack). A list of IP address(es) of the BGP neighbors can be then conveyed in this data node. 'multihop': Indicates the number of allowed IP hops between a PE and its BGP peer. 'as-override': If set, this parameter indicates whether ASN override is enabled, i.e., replace the ASN of the customer specified in the AS_PATH BGP attribute with the ASN identified - in the 'local-autonomous-system' attribute. + in the 'local-as' attribute. 'allow-own-as': Is used in some topologies (e.g., hub-and-spoke) to allow the provider's ASN to be included in the AS_PATH BGP attribute received from a CE. Loops are prevented by setting 'allow-own-as' to a maximum number of provider's ASN occurrences. This parameter is set by default to '0' (that is, reject any AS_PATH attribute that includes the provider's ASN). 'prepend-global-as': When distinct ASNs are configured in the VPN node and network access levels, this parameter controls whether the ASN provided at the VPN node level is prepended to the AS_PATH attribute. - 'default-route': Controls whether default routes can be + 'send-default-route': Controls whether default routes can be advertised to the peer. 'site-of-origin': Is meant to uniquely identify the set of routes learned from a site via a particular CE/PE connection and is used to prevent routing loops (Section 7 of [RFC4364]). The Site of Origin attribute is encoded as a Route Origin Extended Community. 'ipv6-site-of-origin': Carries an IPv6 Address Specific BGP - Extended that is used to indicate the Site of Origin for VRF - information [RFC5701]. It is used to prevent routing loops. + Extended Community that is used to indicate the Site of Origin + for VRF information [RFC5701]. It is used to prevent routing + loops. 'redistribute-connected': Controls whether the PE-CE link is advertised to other PEs. 'bgp-max-prefix': Controls the behavior when a prefix maximum is reached. 'max-prefix': Indicates the maximum number of BGP prefixes allowed in the BGP session. If the limit is reached, the action indicated in 'action-violate' will be followed. @@ -1624,40 +1637,40 @@ of IPsec. 'status': Indicates the status of the BGP routing instance. ... +--rw routing-protocols | +--rw routing-protocol* [id] | ... | +--rw bgp {vpn-common:rtg-bgp}? | | +--rw description? string - | | +--rw local-autonomous-system? inet:as-number - | | +--rw peer-autonomous-system inet:as-number + | | +--rw local-as? inet:as-number + | | +--rw peer-as inet:as-number | | +--rw address-family? identityref | | +--rw local-address? union | | +--rw neighbor* inet:ip-address | | +--rw multihop? uint8 | | +--rw as-override? boolean | | +--rw allow-own-as? uint8 | | +--rw prepend-global-as? boolean - | | +--rw default-route? boolean + | | +--rw send-default-route? boolean | | +--rw site-of-origin? rt-types:route-origin | | +--rw ipv6-site-of-origin? rt-types:ipv6-route-origin | | +--rw redistribute-connected* [address-family] | | | +--rw address-family identityref | | | +--rw enable? boolean | | +--rw bgp-max-prefix | | | +--rw max-prefix? uint32 | | | +--rw warning-threshold? decimal64 | | | +--rw violate-action? enumeration - | | | +--rw restart-interval? uint16 + | | | +--rw restart-timer? uint32 | | +--rw bgp-timers | | | +--rw keepalive? uint16 | | | +--rw hold-time? uint16 | | +--rw authentication | | | +--rw enable? boolean | | | +--rw keying-material | | | +--rw (option)? | | | +--:(tcp-ao) | | | | +--rw enable-tcp-ao? boolean | | | | +--rw ao-keychain? key-chain:key-chain-ref @@ -1680,23 +1693,25 @@ Figure 16: BGP Routing Subtree Structure OSPF: OSPF can be configured to run as a routing protocol on the 'vpn-network-access'. The following data nodes are captured in Figure 17: 'address-family': Indicates whether IPv4, IPv6, or both address families are to be activated. - When only the IPv4 address-family is requested, it will be up - to the implementation to decide whether OSPFv2 [RFC4577] or - OSPFv3 [RFC6565] is used. + When the IPv4 or dual-stack address-family is requested, it is + up to the implementation to decide whether OSPFv2 [RFC4577] or + OSPFv3 [RFC6565] is used to announce IPv4 routes. Such + decision will be typically reflected in the device + configurations that will be derived to implement the L3VPN. 'area-id': Indicates the OSPF Area ID. 'metric': Associates a metric with OSPF routes. 'sham-links': Is used to create OSPF sham links between two VPN network accesses sharing the same area and having a backdoor link (Section 4.2.7 of [RFC4577] and Section 5 of [RFC6565]). 'max-lsa': Sets the maximum number of LSAs that the OSPF instance @@ -1913,53 +1928,61 @@ Figure 20: VRRP Subtree Structure 7.6.4. OAM This container (Figure 21) defines the Operations, Administration, and Maintenance (OAM) mechanisms used for a VPN network access. In the current version of the L3NM, only BFD is supported. The current data nodes can be specified: + 'session-type': Indicates which BFD flavor is used to setup the + session (e.g., classic BFD [RFC5880], Seamless BFD [RFC7880]). By + default, the BFD session is assumed to follow the behavior + specified in [RFC5880]. + 'desired-min-tx-interval': Is the minimum interval, in microseconds, that a PE would like to use when transmitting BFD Control packets less any jitter applied. 'required-min-rx-interval': Is the minimum interval, in microseconds, between received BFD Control packets that a PE is capable of supporting, less any jitter applied by the sender. - 'detection-multiplier': The negotiated transmit interval, multiplied - by this value, provides the detection time for the PE. + 'local-multiplier': The negotiated transmit interval, multiplied by + this value, provides the detection time for the peer. - 'holdtime': Is used to indicate the expected BFD holddown time. The - value can be set by the customer or selected from a profile. + 'holdtime': Is used to indicate the expected BFD holddown time. + This value may be inherited from the service request (see + Section 6.3.2.2.2 of [RFC8299]). + + 'profile': Refers to a BFD profile (Section 7.2). Such a profile + can be set by the provider or inherited from the service request + (see Section 6.3.2.2.2 of [RFC8299]). 'authentication': Includes the required information to enable the BFD authentication modes discussed in Section 6.7 of [RFC5880]. In particular 'meticulous' controls the activation of the meticulous mode discussed in Sections 6.7.3 and 6.7.4 of [RFC5880]. 'status': Indicates the status of BFD. ... +--rw oam | +--rw bfd {vpn-common:bfd}? + | +--rw session-type? identityref | +--rw desired-min-tx-interval? uint32 | +--rw required-min-rx-interval? uint32 - | +--rw detection-multiplier? uint8 - | +--rw (holdtime)? - | | +--:(fixed) - | | | +--rw fixed-value? uint32 - | | +--:(profile) - | | | +--rw profile-name? leafref + | +--rw local-multiplier? uint8 + | +--rw holdtime? uint32 + | +--rw profile? leafref | +--rw authentication! | | +--rw key-chain? key-chain:key-chain-ref | | +--rw meticulous? boolean | +--rw status | +--rw admin-status | | +--rw status? identityref | | +--rw last-change? yang:date-and-time | +--ro oper-status | +--ro status? identityref | +--ro last-change? yang:date-and-time @@ -2006,21 +2029,21 @@ The 'service' container specifies the service parameters to apply for a given VPN network access (Figure 23). ... +--rw vpn-network-accesses +--rw vpn-network-access* [id] ... +--rw service +--rw inbound-bandwidth? uint64 {vpn-common:inbound-bw}? +--rw outbound-bandwidth? uint64 {vpn-common:outbound-bw}? - +--rw mtu? uint16 + +--rw mtu? uint32 +--rw qos {vpn-common:qos}? | ... +--rw carriers-carrier | {vpn-common:carriers-carrier}? | +--rw signaling-type? enumeration +--rw ntp | +--rw broadcast? enumeration | +--rw auth-profile | | +--rw profile-id? string | +--rw status @@ -2453,21 +2475,21 @@ +--ro status? identityref +--ro last-change? yang:date-and-time Figure 30: Multicast Subtree Structure (VPN Network Access Level) 8. L3NM YANG Module This module uses types defined in [RFC6991] and [RFC8343]. It also uses groupings defined in [RFC8519], [RFC8177], and [RFC8294]. - file "ietf-l3vpn-ntw@2021-07-12.yang" + file "ietf-l3vpn-ntw@2021-09-10.yang" module ietf-l3vpn-ntw { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw"; prefix l3nm; import ietf-vpn-common { prefix vpn-common; reference "RFC UUUU: A Layer 2/3 VPN Common YANG Model"; } @@ -2523,21 +2545,21 @@ Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision 2021-07-12 { + revision 2021-09-10 { description "Initial revision."; reference "RFC XXXX: A Layer 3 VPN Network YANG Model"; } /* Features */ feature msdp { description @@ -2661,21 +2683,21 @@ } /* Groupings */ grouping vpn-instance-profile { description "Grouping for data nodes that may be factorized among many levels of the model. The grouping can be used to define generic profiles at the VPN service level and then called at the VPN node and VPN network access levels."; - leaf local-autonomous-system { + leaf local-as { if-feature "vpn-common:rtg-bgp"; type inet:as-number; description "Provider's Autonomous System (AS) number. Used if the customer requests BGP routing."; } uses vpn-common:route-distinguisher; list address-family { key "address-family"; description @@ -2975,22 +2997,22 @@ reference "RFC 7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised), Section 4.11"; } leaf dr-priority { type uint32; default "1"; description "Indicates the preference in the Designated Router (DR) - election process. Numerically larger DR priority allows - a node to be elected as a DR."; + election process. A larger value has a higher + priority over a smaller value."; reference "RFC 7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised), Section 4.3.2"; } } } } /* Main Blocks */ @@ -3101,21 +3123,21 @@ type string; description "Textual description of the VPN node."; } leaf ne-id { type string; description "Unique identifier of the network element where the VPN node is deployed."; } - leaf local-autonomous-system { + leaf local-as { if-feature "vpn-common:rtg-bgp"; type inet:as-number; description "Provider's AS number in case the customer requests BGP routing."; } leaf router-id { type rt-types:router-id; description "A 32-bit number in the dotted-quad format that is used @@ -3979,28 +4001,28 @@ leaf description { type string; description "Includes a description of the BGP session. This description is meant to be used for diagnosis purposes. The semantic of the description is local to an implementation."; } - leaf local-autonomous-system { + leaf local-as { type inet:as-number; description "Indicates a local AS Number (ASN) if a distinct ASN than the one configured at the VPN node level is needed."; } - leaf peer-autonomous-system { + leaf peer-as { type inet:as-number; mandatory true; description "Indicates the customer's ASN when the customer requests BGP routing."; } leaf address-family { type identityref { base vpn-common:address-family; } @@ -4062,21 +4084,21 @@ VPN network access level. When such ASNs are provided, they are both prepended to the BGP route updates for this access. To disable that behavior, the prepend-global-as must be set to 'false'. In such a case, the ASN that is provided at the VPN node level is not prepended to the BGP route updates for this access."; } - leaf default-route { + leaf send-default-route { type boolean; default "false"; description "Defines whether default routes can be advertised to its peer. If set, the default routes are advertised to its peer."; } leaf site-of-origin { when "../address-family = 'vpn-common:ipv4' or " @@ -4176,28 +4198,28 @@ limit is exceeded."; } enum restart { description "The BGP session restarts after a time interval."; } } description "BGP neighbor max-prefix violate - action"; + action."; } - leaf restart-interval { - type uint16; - units "minutes"; + leaf restart-timer { + type uint32; + units "seconds"; description - "Time interval (min) after which the - BGP session will be reestablished."; + "Time interval after which the BGP + session will be reestablished."; } } container bgp-timers { description "Includes two BGP timers that can be customized when building a VPN service with BGP used as CE-PE routing protocol."; leaf keepalive { type uint16 { @@ -4284,21 +4306,21 @@ "Uses MD5 to secure the session."; reference "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs), Section 13.2"; leaf md5-keychain { type key-chain:key-chain-ref; description "Reference to the MD5 key chain."; reference - "RFC 8177: YANG Key Chain."; + "RFC 8177: YANG Key Chain"; } } case explicit { leaf key-id { type uint32; description "Key Identifier"; } leaf key { @@ -4382,21 +4404,22 @@ Customer Edge (PE-CE) Routing Protocol, Section 5"; list sham-link { key "target-site"; description "Creates a sham link with another site."; leaf target-site { type string; description "Target site for the sham link connection. - The site is referred to by its ID."; + The site is referred to by its + identifier."; } leaf metric { type uint16; default "1"; description "Metric of the sham link. It is used in the routing state calculation and path selection. The default value is set to 1."; reference @@ -4556,21 +4579,21 @@ leaf key-chain { type key-chain:key-chain-ref; description "key-chain name."; } } case auth-key-explicit { leaf key-id { type uint32; description - "Key Identifier"; + "Key Identifier."; } leaf key { type string; description "IS-IS authentication key."; } leaf crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } @@ -4610,21 +4634,21 @@ "RFC 2453: RIP Version 2"; leaf update-interval { type uint16 { range "1..32767"; } units "seconds"; default "30"; description "Indicates the RIP update time. That is, the amount of time for which - routing updates are sent."; + RIP updates are sent."; } leaf invalid-interval { type uint16 { range "1..32767"; } units "seconds"; default "180"; description "Is the interval before a route is declared invalid after no updates are received. @@ -4640,21 +4665,21 @@ default "180"; description "Specifies the interval before better routes are released."; } leaf flush-interval { type uint16 { range "1..32767"; } units "seconds"; - default "180"; + default "240"; description "Indicates the RIP flush timer. That is, the amount of time that must elapse before a route is removed from the routing table."; } } leaf default-metric { type uint8 { range "0..16"; @@ -4773,21 +4799,28 @@ "Defines the Operations, Administration, and Maintenance (OAM) mechanisms used. BFD is set as a fault detection mechanism, but other mechanisms can be defined in the future."; container bfd { if-feature "vpn-common:bfd"; description "Container for BFD."; - + leaf session-type { + type identityref { + base vpn-common:bfd-session-type; + } + default "vpn-common:classic-bfd"; + description + "Specifies the BFD session type."; + } leaf desired-min-tx-interval { type uint32; units "microseconds"; default "1000000"; description "The minimum interval between transmission of BFD control packets that the operator desires."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), Section 6.8.7"; @@ -4795,73 +4828,69 @@ leaf required-min-rx-interval { type uint32; units "microseconds"; description "The minimum interval between received BFD control packets that the PE should support."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), Section 6.8.7"; } - leaf detection-multiplier { + leaf local-multiplier { type uint8 { - range "1..max"; + range "1..255"; } + default "3"; description - "The detection interval for the BFD session - is calculated by multiplying the value of - the negotiated transmission interval by - the detection multiplier value."; + "Specifies the detection multiplier that is + transmitted to a BFD peer. + + The detection interval for the receiving + BFD peer is calculated by multiplying the value + of the negotiated transmission interval by + the received detection multiplier value."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), Section 6.8.7"; } - choice holdtime { - default "fixed"; - description - "Choice for holdtime flavor."; - case fixed { - leaf fixed-value { + leaf holdtime { type uint32; units "msec"; description "Expected BFD holdtime. The customer may impose some fixed values for the holdtime period if the provider allows the customer use of this function. If the provider doesn't allow the customer to use this function, the fixed-value will not be set."; + reference + "RFC 5880: Bidirectional Forwarding Detection + (BFD), Section 6.8.18"; } - } - case profile { - description - "Well-known SP profile."; - leaf profile-name { + leaf profile { type leafref { path "/l3vpn-ntw/vpn-profiles" + "/valid-provider-identifiers" + "/bfd-profile-identifier/id"; } description "Well-known service provider profile name. The provider can propose some profiles to the customer, depending on the service level the customer wants to achieve."; } - } - } container authentication { presence "Enables BFD authentication"; description "Parameters for BFD authentication."; leaf key-chain { type key-chain:key-chain-ref; description "Name of the key-chain."; } leaf meticulous { @@ -4966,31 +4997,30 @@ if-feature "vpn-common:outbound-bw"; type uint64; units "bps"; description "From the customer site's perspective, the service oubtound bandwidth of the connection or upload bandwidth from the site to the SP. Note that the L3SM uses 'output-bandwidth' to refer to the same concept."; - } leaf mtu { - type uint16; + type uint32; units "bytes"; description "MTU at service level. If the service is IP, it refers to the IP MTU. If Carriers' Carriers (CsC) is enabled, the requested MTU - will refer to the MPLS MTU and not to the - IP MTU."; + will refer to the MPLS maximum labeled packet + size and not to the IP MTU."; } container qos { if-feature "vpn-common:qos"; description "QoS configuration."; container qos-classification-policy { description "Configuration of the traffic classification policy."; uses vpn-common:qos-classification-policy; @@ -5325,22 +5358,22 @@ "RFC 7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised), Section 4.11"; } leaf dr-priority { type uint32; default "1"; description "Indicates the preference in the DR election - process. Numerically larger DR priority - allows a node to be elected as a DR."; + process. A larger value has a higher + priority over a smaller value."; reference "RFC 7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised), Section 4.3.2"; } uses vpn-common:service-status; } } } @@ -5371,56 +5404,51 @@ There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/ vulnerability in the "ietf-l3vpn-ntw" module: - o 'vpn-service': An attacker who is able to access network nodes can + * 'vpn-service': An attacker who is able to access network nodes can undertake various attacks, such as deleting a running L3VPN service, interrupting all the traffic of a client. In addition, an attacker may modify the attributes of a running service (e.g., QoS, bandwidth, routing protocols), leading to malfunctioning of the service and therefore to SLA violations. In addition, an attacker could attempt to create an L3VPN service or adding a new network access. In addition to using NACM to prevent authorized access, such activity can be detected by adequately monitoring and tracking network configuration changes. Some readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: - o 'customer-name' and 'ip-connection': An attacker can retrieve + * 'customer-name' and 'ip-connection': An attacker can retrieve privacy-related information which can be used to track a customer. Disclosing such information may be considered as a violation of the customer-provider trust relationship. - Several data nodes defined in the L3NM rely upon [RFC8177] for - authentication purposes. Therefore, this module inherits the - security considerations discussed in Section 5 of [RFC8177]. - - The following summarizes the foreseen risks of using the "ietf-l3vpn- - ntw" module can be classified into: - - o Malicious clients attempting to delete or modify VPN services. - - o Unauthorized clients attempting to create/modify/delete a VPN - service. + Several data nodes ('bgp', 'ospf', 'isis', 'rip', and 'bfd') rely + upon [RFC8177] for authentication purposes. Therefore, this module + inherits the security considerations discussed in Section 5 of + [RFC8177]. - o Unauthorized clients attempting to read VPN service related - information. + As discussed in Section 7.6.3, the module supports MD5 to basically + accommodate the installed BGP base. MD5 suffers from the security + weaknesses discussed in Section 2 of [RFC6151] or Section 2.1 of + [RFC6952]. 10. IANA Considerations This document requests IANA to register the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-ntw Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. @@ -5433,25 +5461,26 @@ maintained by IANA: N prefix: l3nm reference: RFC XXXX 11. References 11.1. Normative References [I-D.ietf-opsawg-vpn-common] Barguil, S., Dios, O. G. D., Boucadair, M., and Q. Wu, "A - Layer 2/3 VPN Common YANG Model", draft-ietf-opsawg-vpn- - common-07 (work in progress), April 2021. + Layer 2/3 VPN Common YANG Model", Work in Progress, + Internet-Draft, draft-ietf-opsawg-vpn-common-09, 15 July + 2021, . - [ISO10589] - ISO, "Intermediate System to Intermediate System intra- + [ISO10589] ISO, "Intermediate System to Intermediate System intra- domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", 2002, . [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, . [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and @@ -5633,56 +5662,79 @@ [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, "YANG Data Model for Network Access Control Lists (ACLs)", RFC 8519, DOI 10.17487/RFC8519, March 2019, . 11.2. Informative References [I-D.evenwu-opsawg-yang-composed-vpn] Even, R., Wu, B., Wu, Q., and YingCheng, "YANG Data Model - for Composed VPN Service Delivery", draft-evenwu-opsawg- - yang-composed-vpn-03 (work in progress), March 2019. + for Composed VPN Service Delivery", Work in Progress, + Internet-Draft, draft-evenwu-opsawg-yang-composed-vpn-03, + 8 March 2019, . [I-D.ietf-bess-evpn-prefix-advertisement] Rabadan, J., Henderickx, W., Drake, J. E., Lin, W., and A. - Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- - bess-evpn-prefix-advertisement-11 (work in progress), May - 2018. + Sajassi, "IP Prefix Advertisement in EVPN", Work in + Progress, Internet-Draft, draft-ietf-bess-evpn-prefix- + advertisement-11, 18 May 2018, + . [I-D.ietf-idr-bgp-model] Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP - YANG Model for Service Provider Networks", draft-ietf-idr- - bgp-model-10 (work in progress), November 2020. + YANG Model for Service Provider Networks", Work in + Progress, Internet-Draft, draft-ietf-idr-bgp-model-11, 11 + July 2021, . [I-D.ietf-pim-yang] Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, Y., and F. Hu, "A YANG Data Model for Protocol Independent - Multicast (PIM)", draft-ietf-pim-yang-17 (work in - progress), May 2018. + Multicast (PIM)", Work in Progress, Internet-Draft, draft- + ietf-pim-yang-17, 19 May 2018, + . [I-D.ietf-rtgwg-qos-model] Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., - and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos- - model-03 (work in progress), February 2021. + and I. Chen, "A YANG Data Model for Quality of Service + (QoS)", Work in Progress, Internet-Draft, draft-ietf- + rtgwg-qos-model-04, 12 July 2021, + . [I-D.ietf-teas-enhanced-vpn] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for Enhanced Virtual Private Network (VPN+) - Services", draft-ietf-teas-enhanced-vpn-07 (work in - progress), February 2021. + Services", Work in Progress, Internet-Draft, draft-ietf- + teas-enhanced-vpn-08, 12 July 2021, + . [I-D.ietf-teas-ietf-network-slices] Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, - "Framework for IETF Network Slices", draft-ietf-teas-ietf- - network-slices-00 (work in progress), April 2021. + "Framework for IETF Network Slices", Work in Progress, + Internet-Draft, draft-ietf-teas-ietf-network-slices-04, 23 + August 2021, . + + [I-D.ogondio-opsawg-uni-topology] + Dios, O. G. D., Barguil, S., Wu, Q., and M. Boucadair, "A + YANG Model for User-Network Interface (UNI) Topologies", + Work in Progress, Internet-Draft, draft-ogondio-opsawg- + uni-topology-01, 2 April 2020, + . [PYANG] "pyang", November 2020, . [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, DOI 10.17487/RFC3618, October 2003, . [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. @@ -5715,36 +5767,52 @@ [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, DOI 10.17487/RFC6037, October 2010, . + [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations + for the MD5 Message-Digest and the HMAC-MD5 Algorithms", + RFC 6151, DOI 10.17487/RFC6151, March 2011, + . + + [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of + BGP, LDP, PCEP, and MSDP Issues According to the Keying + and Authentication for Routing Protocols (KARP) Design + Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, + . + [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, . [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, . [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, . + [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. + Pallagatti, "Seamless Bidirectional Forwarding Detection + (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, + . + [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, . [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, @@ -5837,21 +5905,21 @@ "vpn-service": [ { "vpn-id": "4G", "customer-name": "mycustomer", "vpn-service-topology": "custom", "description": "VPN to deploy 4G services", "vpn-instance-profiles": { "vpn-instance-profile": [ { "profile-id": "simple-profile", - "local-autonomous-system": 65550, + "local-as": 65550, "rd": "0:65550:1", "address-family": [ { "address-family": "vpn-common:dual-stack", "vpn-targets": { "vpn-target": [ { "id": "1", "route-targets": [ "0:65550:1" @@ -6055,56 +6123,194 @@ } } } ] } } Figure 35: VPN Network Access with a Loopback Interface (Message Body) -A.3. Multicast VPN Provisioning Example +A.3. Overriding VPN Instance Profile Parameters + + Figure 36 shows a simplified example to illustrate how some + information that is provided at the VPN service level (particularly + 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 + inherit the 'vpn-instance-profiles' parameters that are specified at + 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 + specified at the VPN service level. + + { + "ietf-l3vpn-ntw:vpn-services": { + "vpn-service": [ + { + "vpn-id": "override-example", + "vpn-service-topology": "vpn-common:hub-spoke", + "vpn-instance-profiles": { + "vpn-instance-profile": [ + { + "profile-id": "HUB", + "role": "vpn-common:hub-role", + "local-as": 64510, + "rd-suffix": 1001, + "address-family": [ + { + "address-family": "vpn-common:dual-stack", + "maximum-routes": [ + { + "protocol": "vpn-common:any", + "maximum-routes": 100 + } + ] + } + ] + }, + { + "profile-id": "SPOKE", + "role": "vpn-common:spoke-role", + "local-as": 64510, + "address-family": [ + { + "address-family": "vpn-common:dual-stack", + "maximum-routes": [ + { + "protocol": "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": [ + { + "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" + } + ] + } + } + ] + } + } + ] + } + } + + Figure 36: VPN Instance Profile Example (Message Body) + +A.4. Multicast VPN Provisioning Example IPTV is mainly distributed through multicast over the LANs. In the following example, PIM-SM is enabled and functional between the PE and the CE. The PE receives multicast traffic from a CE that is directly connected to the multicast source. The signaling between PE and CE is achieved using BGP. Also, RP is statically configured for a multicast group. +-----------+ +------+ +------+ +-----------+ | Multicast |---| CE |--/--| PE |----| Backbone | | source | +------+ +------+ | IP/MPLS | +-----------+ +-----------+ - Figure 36: Multicast L3VPN Service Example + Figure 37: Multicast L3VPN Service Example An example is provided below to illustrate how to configure a multicast L3VPN service using the L3NM. First, the multicast service is created together with a generic VPN instance profile (see the excerpt of the request message body shown - in Figure 37) + in Figure 38) { "ietf-l3vpn-ntw:vpn-services": { "vpn-service": [ { "vpn-id": "Multicast-IPTV", "vpn-description": "Multicast IPTV VPN service", "customer-name": "a-name", "vpn-service-topology": "vpn-common:hub-spoke", "vpn-instance-profiles": { "vpn-instance-profile": [ { "profile-id": "multicast", "role": "ietf-vpn-common:hub-role", - "local-autonomous-system": 65536, + "local-as": 65536, "multicast": { "rp": { "rp-group-mappings": { "rp-group-mapping": [ { "id": "1", "rp-address": "203.0.113.17", "groups": { "group": [ { @@ -6122,25 +6328,25 @@ } } } ] } } ] } } - Figure 37: Create Multicast VPN Service (Excerpt of the Message + Figure 38: Create Multicast VPN Service (Excerpt of the Message Request Body) Then, the VPN nodes are created (see the excerpt of the request - message body shown in Figure 38). 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. { "ietf-l3vpn-ntw:vpn-node": [ { "vpn-node-id": "500003105", "description": "VRF-IPTV-MULTICAST", "ne-id": "198.51.100.10", "router-id": "198.51.100.10", "active-vpn-instance-profiles": { @@ -6148,25 +6354,25 @@ { "profile-id": "multicast", "rd": "65536:31050202" } ] } } ] } - Figure 38: Create Multicast VPN Node (Excerpt of the Message Request - Body) + Figure 39: Create Multicast VPN Node (Excerpt of the Message + Request Body) Finally, create the VPN network access with multicast enabled (see - the excerpt of the request message body shown in Figure 39). + the excerpt of the request message body shown in Figure 40). { "ietf-l3vpn-ntw:vpn-network-access": { "id": "1/1/1", "description": "Connected-to-source", "vpn-network-access-type": "vpn-common:point-to-point", "vpn-instance-profile": "multicast", "status": { "admin-status": { "status": "vpn-common:admin-state-up" @@ -6187,21 +6393,21 @@ } } }, "routing-protocols": { "routing-protocol": [ { "id": "1", "type": "vpn-common:bgp-routing", "bgp": { "description": "Connected to CE", - "peer-autonomous-system": "65537", + "peer-as": "65537", "address-family": "vpn-common:ipv4", "neighbor": "203.0.113.2" } } ] }, "service": { "inbound-bandwidth": "100000000", "outbound-bandwidth": "100000000", "mtu": 1500, @@ -6216,22 +6422,22 @@ "status": "vpn-common:admin-state-up" } } } } } } } } - Figure 39: Create VPN Network Access (Excerpt of the Message Request - Body) + Figure 40: Create VPN Network Access (Excerpt of the Message + Request Body) 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 document and is based on a proposal described in [RFC7942]. 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 @@ -6264,41 +6470,46 @@ B.3. Infinera Implementation Details can be found at: https://github.com/IETF-OPSAWG- WG/l3nm/blob/master/Implementattion/Infinera.txt B.4. Ribbon-ECI Implementation Details can be found at: https://github.com/IETF-OPSAWG- WG/l3nm/blob/master/Implementattion/Ribbon-ECI.txt +B.5. Juniper Implementation + + https://github.com/IETF-OPSAWG-WG/lxnm/blob/master/Implementattion/ + Juniper + Acknowledgements During the discussions of this work, helpful comments, suggestions, and reviews were received from (listed alphabetically): Raul Arco, Miguel Cros Cecilia, Joe Clarke, Dhruv Dhody, Adrian Farrel, Roque - Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, and - Tom Petch. Many thanks to them. Thanks to Philip Eardly for the - review of an early version of the document. + Gagliano, Christian Jacquenet, Kireeti Kompella, Julian Lucek, Greg + Mirsky, and Tom Petch. Many thanks to them. Thanks to Philip Eardly + for the review of an early version of the document. Daniel King, Daniel Voyer, Luay Jalil, and Stephane Litkowski - contributed to early version of the individual submission. - - Many thanks to Robert Wilton for the AD review. + contributed to early version of the individual submission. Many + thanks to Robert Wilton for the AD review. Thanks to Andrew Malis + for the routing directorate review, Rifaat Shekh-Yusef for the + security directorate review, and Qin Wu for the opsdir review. This work was supported in part by the European Commission funded H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727) and Horizon 2020 Secured autonomic traffic management for a Tera of SDN flows (Teraflow) project (G.A. 101015857). Contributors - Victor Lopez Telefonica Email: victor.lopezalvarez@telefonica.com Qin Wu Huawei Email: bill.wu@huawei.com> Manuel Julian Vodafone @@ -6314,40 +6525,39 @@ Paul Sherratt Gamma Telecom Email: paul.sherratt@gamma.co.uk Authors' Addresses Samier Barguil Telefonica Madrid - ES + Spain Email: samier.barguilgiraldo.ext@telefonica.com Oscar Gonzalez de Dios (editor) Telefonica Madrid - ES + Spain Email: oscar.gonzalezdedios@telefonica.com Mohamed Boucadair (editor) Orange Rennes 35000 France Email: mohamed.boucadair@orange.com - Luis Angel Munoz Vodafone - ES + Spain Email: luis-angel.munoz@vodafone.com Alejandro Aguado Nokia Madrid - ES + Spain Email: alejandro.aguado_martin@nokia.com