| Network Working Group | X. Xu |
| Internet-Draft | Huawei |
| Intended status: Standards Track | H. Shah |
| Expires: April 20, 2016 | Ciena Corp |
| Y. Fan | |
| China Telecom | |
| October 18, 2015 |
NVo3 Control Plane Protocol Using IS-IS
draft-xu-nvo3-isis-cp-01
This document describes the use of IS-IS as a light-weight control plane protocol for Network Virtualization over L3 (NVo3) overlay networks. This light-weight control plane protocol is intended for small and even medium sized data center networks and is applicable to any specific NVo3 data encapsulation formats.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
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 http://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 April 20, 2016.
Copyright (c) 2015 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 (http://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.
[RFC7364] discusses the need of an overlay-based network virtualization approach, referred to as Network Virtualization over Layer3 (NVo3), for providing multi-tenancy capabilities in large data centers networks and outlines the needs for a control plane protocol to facilitate running these NVo3 overlay networks. [RFC7365] provides a framework for NVo3 overlay networks 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.
IS-IS protocol [IS-IS] is a much proven and well-known routing protocol which has been widely deployed in many large carrier networks and data center 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 [RFC1195]), but also used for propagating MAC reachability information in Layer2 networks or Layer2 overlay networks [RFC6165].
This document accordingly proposes using IS-IS as a simple control plane protocol of NVo3 overlay networks which can be workable with any specific NVo3 data encapsulation formats such as MPLS-in-UDP[RFC7510], VXLAN [RFC7348], VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] , MPLS-in-GRE [RFC4023] and NVGRE [RFC7637], It's no doubt that Border Gateway Protocol (BGP) is more scalable than IS-IS and hence the former is more suitable to be used as a common NVo3 control plane in large data center network environments. However, for some small and even medium sized data center networks, the complexity of BGP is perhaps too much and even unaffordable. IS-IS -based common NVo3 control plane could be a light-weight choice for these small and even medium data center networks where automating (e.g., no need for manually configuring BGP peers) and simplifying the network provisioning (e.g., only a single protocol to be deployed) is particularly important.
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 [RFC2119].
This memo makes use of the terms defined in [RFC7365] and [I-D.ietf-bier-architecture].
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) which is associated to a routable IP address of a NVE and MAY be present in any of the following TLVs originated by that NVE:
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:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VN ID | Sub-domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VN ID | Sub-domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Label | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [I-D.xu-isis-encapsulation-cap]
For those Layer2 overlay approaches which adopts 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. 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 [RFC6165]. One or more MAC-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. 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 NVo3 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.
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
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4971] | Vasseur, JP., Shen, N. and R. Aggarwal, "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, DOI 10.17487/RFC4971, July 2007. |
| [RFC5305] | Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008. |
| [RFC5308] | Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008. |