Internet DRAFT - draft-xu-isis-nvo-cp

draft-xu-isis-nvo-cp







Network Working Group                                              X. Xu
Internet-Draft                                                    Huawei
Intended status: Standards Track                              S. Dikshit
Expires: February 9, 2017                                          Cisco
                                                                 H. Shah
                                                              Ciena Corp
                                                                  Y. Fan
                                                           China Telecom
                                                          August 8, 2016


                 NVO Control Plane Protocol Using IS-IS
                        draft-xu-isis-nvo-cp-00

Abstract

   This document describes the use of IS-IS as a light-weight control
   plane protocol for Network Virtualization Overlays.  This light-
   weight control plane protocol is intended for small and even medium
   sized enterprise campus networks where the NVO date encapsulation
   technology is to be used.

Status of This Memo

   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 February 9, 2017.

Copyright Notice

   Copyright (c) 2016 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



Xu, et al.              Expires February 9, 2017                [Page 1]

Internet-Draft             NVO CP using IS-IS                August 2016


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  VN Membership Auto-discovery  . . . . . . . . . . . . . . . .   3
     3.1.  VN Membership Info Sub-TLV  . . . . . . . . . . . . . . .   3
   4.  Tunnel Encapsulation Capability Advertisement . . . . . . . .   4
   5.  MAC Address Learning  . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Control-plane based MAC Learning for Remote CE Hosts  . .   5
   6.  MAC/IP Binding Info Advertisement . . . . . . . . . . . . . .   5
   7.  IP Reachability Info Advertisement  . . . . . . . . . . . . .   6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     11.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   [RFC7364] 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.  [RFC7365] 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-IS] is a much proven and well-known routing
   protocol which has been widely deployed in campus networks for many



Xu, et al.              Expires February 9, 2017                [Page 2]

Internet-Draft             NVO CP using IS-IS                August 2016


   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].

   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 [RFC7348],
   VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] , and NVGRE [RFC7637].

1.1.  Requirements Language

   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].

2.  Terminology

   This memo makes use of the terms defined in [RFC7365] and
   [I-D.ietf-bier-architecture].

3.  VN Membership Auto-discovery

   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 [RFC5305].

   2.  TLV-236 (IPv6) defined in [RFC5308]

   When the above TLV is propagated across level boundaries, the VN
   Membership Info sub-TLV contained in that TLV SHOULD be kept.

3.1.  VN Membership Info Sub-TLV

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








Xu, et al.              Expires February 9, 2017                [Page 3]

Internet-Draft             NVO CP using IS-IS                August 2016


        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                        |S|   Reserved  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Sub-domain ID |                     Reserved                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                                                               :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  VN ID                        |S|   Reserved  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Sub-domain ID |                     Reserved                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      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
      [I-D.ietf-bier-architecture].  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.

4.  Tunnel Encapsulation Capability Advertisement

   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]








Xu, et al.              Expires February 9, 2017                [Page 4]

Internet-Draft             NVO CP using IS-IS                August 2016


5.  MAC Address Learning

   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.

5.1.  Control-plane based MAC Learning for Remote CE Hosts

   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 [RFC6165].  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.

6.  MAC/IP Binding Info Advertisement

   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



Xu, et al.              Expires February 9, 2017                [Page 5]

Internet-Draft             NVO CP using IS-IS                August 2016


7.  IP Reachability Info Advertisement

   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 [RFC1195] 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.

8.  IANA Considerations

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

9.  Security Considerations

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

10.  Acknowledgements

   TBD

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4971]  Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed.,
              "Intermediate System to Intermediate System (IS-IS)
              Extensions for Advertising Router Information", RFC 4971,
              DOI 10.17487/RFC4971, July 2007,
              <http://www.rfc-editor.org/info/rfc4971>.





Xu, et al.              Expires February 9, 2017                [Page 6]

Internet-Draft             NVO CP using IS-IS                August 2016


   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
              2008, <http://www.rfc-editor.org/info/rfc5305>.

   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
              DOI 10.17487/RFC5308, October 2008,
              <http://www.rfc-editor.org/info/rfc5308>.

11.2.  Informative References

   [I-D.ietf-bier-architecture]
              Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
              S. Aldrin, "Multicast using Bit Index Explicit
              Replication", draft-ietf-bier-architecture-04 (work in
              progress), July 2016.

   [I-D.ietf-nvo3-vxlan-gpe]
              Kreeger, L. and U. Elzur, "Generic Protocol Extension for
              VXLAN", draft-ietf-nvo3-vxlan-gpe-02 (work in progress),
              April 2016.

   [I-D.xu-isis-encapsulation-cap]
              Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras,
              L., and L. Jalil, "Advertising Tunnelling Capability in
              IS-IS", draft-xu-isis-encapsulation-cap-06 (work in
              progress), November 2015.

   [IS-IS]    "ISO/IEC 10589, "Intermediate System to Intermediate
              System Intra-Domain Routing Exchange Protocol for use in
              Conjunction with the Protocol for Providing the
              Connectionless-mode Network Service (ISO 8473)", 2005.".

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, DOI 10.17487/RFC1195,
              December 1990, <http://www.rfc-editor.org/info/rfc1195>.

   [RFC6165]  Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
              Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011,
              <http://www.rfc-editor.org/info/rfc6165>.

   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
              L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
              eXtensible Local Area Network (VXLAN): A Framework for
              Overlaying Virtualized Layer 2 Networks over Layer 3
              Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
              <http://www.rfc-editor.org/info/rfc7348>.





Xu, et al.              Expires February 9, 2017                [Page 7]

Internet-Draft             NVO CP using IS-IS                August 2016


   [RFC7364]  Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L.,
              Kreeger, L., and M. Napierala, "Problem Statement:
              Overlays for Network Virtualization", RFC 7364,
              DOI 10.17487/RFC7364, October 2014,
              <http://www.rfc-editor.org/info/rfc7364>.

   [RFC7365]  Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
              Rekhter, "Framework for Data Center (DC) Network
              Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
              2014, <http://www.rfc-editor.org/info/rfc7365>.

   [RFC7637]  Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
              Virtualization Using Generic Routing Encapsulation",
              RFC 7637, DOI 10.17487/RFC7637, September 2015,
              <http://www.rfc-editor.org/info/rfc7637>.

Authors' Addresses

   Xiaohu Xu
   Huawei

   Email: xuxiaohu@huawei.com


   Saumya Dikshit
   Cisco

   Email: sadikshi@cisco.com


   Himanshu Shah
   Ciena Corp

   Email: hshah@ciena.com


   Yongbing Fan
   China Telecom

   Email: fanyb@gsta.com











Xu, et al.              Expires February 9, 2017                [Page 8]