NVO Control Plane Protocol Using IS-IS

discusses the need of an overlay-based network virtualization approach, referred to as Network Virtualization Overlays (NVO), for providing multi-tenancy capabilities in large data centers networks and outlines the needs for a control plane protocol to facilitate running NVO. provides a framework for NVO and meanwhile describes the needs for a control plane protocol to provide the following capabilities such as auto-provisioning/service discovery, address mapping advertisement and tunnel management. Due to the success of the NVO technology in data center networks, more and more enterprises are considering the deployment of this technology in their campus networks so as to replace the old spanning tree protocols. Although BGP or Software Defined Network (SDN) controller could still be used as the control plane protocol in campus networks, both of them seem a bit heavyweight, especially for small and even medium sized campus networks. IS-IS protocol is a much proven and well-known routing protocol which has been widely deployed in campus networks for many years. Due to its extendibility, IS-IS protocol now is not only used for propagating IP reachability information in Layer3 networks (see ), but also used for propagating MAC reachability information in Layer2 networks or Layer2 overlay networks . By using IS-IS as a lightweight control plane protocol for NVO, the network provisioning is greatly simplified ((e.g., only a single protocol to be deployed)), which is much significant to campus networks. This IS-IS based NVO control plane protocol could support any specific NVO data encapsulation formats such as VXLAN , VXLAN-GPE , and NVGRE .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

This memo makes use of the terms defined in and .

By propagating the VN membership info among Network Virtualization Edges (NVEs), NVEs belonging to the same VN instance could discover one another automatically. The VN membership info is carried in a VN Membership Info sub-TLV (as shown in Section 3.1) of the following TLVs originated by that NVE: 1. TLV-135 (IPv4) defined in . 2. TLV-236 (IPv6) defined in When the above TLV is propagated across level boundaries, the VN Membership Info sub-TLV contained in that TLV SHOULD be kept.

The VN Membership Info sub-TLV has the following format:

Type: TBD; Length: Variable; VN ID: This field is filled with a 24-bit globally significant VN ID for a particular attached VN instance. S-Flag: This field indicates the existence of the Sub-domain ID field. When the S-Flag is set, the Sub-domain ID field MUST be filled with a valid sub-domain ID. Otherwise, it SHOULD be set to zero. Sub-domain ID: This field is filled with a 8-bit BIER sub-domain ID to which the VN has been associated . The field is only useful in the case where the Broadcast, Unknown-unicast and Multicast (BUM) packets within a VN are transported across the underlay by using the BIER forwarding mode.

To reach a consensus on what specific tunnel encapsulation format to be used between ingress and egress NVE pairs automatically, egress NVEs SHOULD advertise their own tunnel encapsulation capabilities by using the Encapsulation Capability sub-TLV as defined in

For Layer2 overlays, MAC addresses of local CE hosts would still be learnt by NVEs as normal bridges. As for learning MAC addresses of remote CE hosts, there are two options: 1) data-plane based MAC learning and 2) control- plane based MAC learning. If unknown unicast flood suppression is strongly required even at the cost of consuming more forwarding table resources, the control-plane based MAC learning option could be considered. Otherwise, the data-plane based MAC learning option is RECOMMENDED.

In the control-plane based MAC address learning mechanism, MAC reachability information of a given VN instance would be exchanged across NVEs of that VN instance via IS-IS as well. Upon learning MAC addresses of their local TES's somehow, NVEs SHOULD immediately advertise these MAC addresses to remote NVEs of the same VN instance by using the MAC-Reachability TLV as defined in . One or more MAC-Reachability TLVs are carried in an LSP which in turn is encapsulated with an Ethernet header. The source MAC address is the originating NVE's MAC address whereas the destination MAC address is a to-be-defined multicast MAC address specifically identifying all NVEs. Although in Ingress Replication case for networks not supporting multicast, the remote NVE unicast addresses can be pre-learned via configuration, and used as destination MAC address instead of multicast MAC address. Such Ethernet frames containing IS-IS LSPs are forwarded towards remote NVEs as if they were customer multicast Ethernet frames. Egress NVEs receiving the above frames SHOULD intercept them and accordingly process them. The routable IP address of the NVE originating these MAC routes could be derived either from the "IP Interface Address" field contained in the corresponding LSPs (Note that the IP address here SHOULD be identical to the routable IP address associated with the VN membership Info) or from the tunnel source IP address of the NVO encapsulated packet containing such MAC routes. Since these LSPs are fully transparent to core routers of the underlying networks (i.e., non-NVE routers), there is no impact on the control plane of core routers at all.

To refrain from flooding ARP/ND messages generated by end-hosts, across all NVEs for a given VN, IP/MAC bindings for these end-hosts can be potentially exchanged between NVEs through IS-IS. ARP/ND caching can be enabled on NVEs to allow local NVE to respond for an ARP/ND requests on behalf of remote hosts. Thus there is no need to flood ARP/ND messages to all other NVEs of a given VN. This potential extension is for further study

For Layer3 overlays, IP reachability information of a given VN instance, including both host routes and/or subnet routes, SHOULD be exchanged across NVEs of that VN instance. The IP-Reachability TLV defined in could be used directly here. One or more IP-Reachability TLVs are carried in a LSP which in turn is encapsulated with an Ethernet header. The source MAC address is the originating NVE's MAC address whereas the destination MAC address is a to-be-defined multicast MAC address specifically identifying all NVEs. Such Ethernet frames containing IS-IS LSPs are forwarded towards remote NVEs as if they were customer multicast Ethernet frames. Egress NVEs receiving the above frames SHOULD intercept them and accordingly process them. Similarly, since these LSPs are fully transparent to core routers of the underlying networks (i.e., non-NVE routers), there is no impact on the control plane of core routers at all.

The type code for VN Membership Info sub-TLV is required to be allocated by IANA.

This document doesn't introduce additional security risk to IS-IS, nor does it provide any additional security feature for IS-IS.

TBD