BESS                                                             W. Hao
                                                                  Y. Li
                                                                L. Wang
Internet Draft                                  Huawei Technologies Ltd.
Intended status: Standards Track
Expires: September 2016                                  March 8, 2016



         Multicast Group Address Auto-Provisioning For NVO3 Network
                   draft-hao-bess-mcast-auto-nvo3-01.txt

Abstract

   This document provides dynamic underlay multicast group address
   provisioning mechanism for each VNI or combination of VNI and
   overlay multicast group address. The underlay multicast group
   address allocation function is provided on NVA(centralized point),
   NVE communicates with NVA using BGP protocol extension.

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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

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



Hao & Li,et,al        Expires September 8, 2016               [Page 1]


Internet-Draft NVO3 Multicast Group Auto-Provisioning       March 2016


   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 ................................................ 2
   2. Terminology ................................................. 4
   3. Solution overview ........................................... 4
   4. BGP Protocol extension....................................... 6
      4.1. P-Multicast Allocation Extended Community............... 6
   5. Security Considerations...................................... 7
   6. IANA Considerations ......................................... 7
      6.1. Normative References.................................... 7
      6.2. Informative References.................................. 8
   7. Acknowledgments ............................................. 8

   1. Introduction

   Network virtualization over Layer 3 (NVO3) is a technology that is
   used to address issues that arise in building large, multitenant
   data centers that make extensive use of server virtualization
   [RFC7364]. VXLAN and NVGRE are two typical NVO3 technologies. Both
   of these technologies include 24 bits Virtual Network Identifier
   (VNI) as tenant identification. NVO3 overlay network can be
   controlled through centralized NVE-NVA architecture or through
   distributed BGP VPN protocol.

   For multicast traffic handling, using the multicast capabilities of
   the underlying Network is one possible way. In this method, the
   underlay supports IP multicast and the ingress NVE encapsulates the
   packet with the appropriate underlay IP multicast address in the
   tunnel encapsulation header for delivery to the desired set of NVEs.
   The underlay multicast distribution tree is called P-multicast tree,
   the underlay multicast group is called P-multicast group. The
   protocol in the underlay to construct P-multicast tree could be any
   variant of Protocol Independent Multicast (PIM), or protocol
   dependent multicast, such as [ISIS-Multicast]. The method is
   mentioned in the NVO3 architecture [NVO3-ARCH] and multicast
   framework [MCASTFM] documents. In this method, for layer 2 directly
   connecting TSs, each NVE acts as a multicast router and supports


Hao & Li,et,al        Expires September 8, 2016               [Page 2]


Internet-Draft NVO3 Multicast Group Auto-Provisioning       March 2016


   proper mapping of IGMP/MLD's messages to the messages needed by the
   underlay IP multicast protocols.

   For broadcast, unknown unicast and bidirectional multicast
   application traffic in each VN, the associated VTEPs should act as
   both the source and destination of the traffic, bidirectional P-
   Multicast tree offer better scalability then PIM-SM/SSM with the
   number of flows required being g. Also Bidir tree is share tree, in
   regular data center spine-leaf network architecture, share tree has
   same optimal forwarding path as source tree established by PIM-
   SM/SSM. So in most cases, the underlay P-multicast tree in NVO3
   network should be Bidir tree than source tree. Both BIDIR-PIM and
   ISIS-Multicast protocol are suitable to construct the bidirectional
   P-multicast tree. Each bidirectional P-multicast tree corresponds to
   one P-Multicast group address.

   To transport overlay BUM(broadcast, unknown unicast and multicast)
   traffic, we need to have a mapping between the VNI/VNI plus C-
   Multicast group and the P-Multicast group that it will use. The
   overlay multicast group is called C-Multicast group. There are
   multiple mapping methods as follows:

   1. Dedicated inclusive tree. In this case, a multicast tree is
      dedicated to a VNI, a separate underlay multicast group address is
      allocated for each VNI.

   2. Aggregate inclusive tree. In this case, a multicast tree is shared
      by multiple VNIs, a shared multicast group address is allocated
      for multiple VNIs.

   3. Dedicated selective tree. In this case, a multicast tree is
      dedicated to a combination of VNI plus overlay multicast group, a
      separate underlay multicast group address is allocated for a
      combination.

   4. Aggregate selective tree. In this case, a multicast tree is shared
      by multiple combinations of VNI plus overlay multicast group, a
      shared underlay multicast group address is allocated for multiple
      combinations.

   When inclusive tree solution is used, if a VN has multiple TSs and
   these TSs spread over multiple NVEs, then these NVEs should ensure
   same P-multicast group address is provisioned for the VN, i.e., P-
   Multicast group provisioning consistency should be ensured among
   multiple NVEs connecting to same underlay multicast tree. For VN and
   P-Multicast group mapping, it can be done at the management layer
   which provided to the individual VTEPs through a management channel


Hao & Li,et,al        Expires September 8, 2016               [Page 3]


Internet-Draft NVO3 Multicast Group Auto-Provisioning       March 2016


   or through control plane protocol which is introduced in this
   document.

   In selective tree solution, because NVE can't get the list of
   participants for each C-multicast group ahead of time, the mapping
   between C-multicast group and P-multicast group on each NVE can't be
   configured statically through a management channel, P-multicast
   group and the mapping between P-multicast group and C-multicast
   group should be provided dynamically using control plane protocol.

   This draft proposes a control plane method to dynamically allocate
   P-multicast group for each NVE on a centralized point like NVA, the
   communication protocol between each NVE and NVA uses BGP EVPN
   protocol extension. In the future, other protocols also can be
   considered.

   2. Terminology

      EVI: An EVPN instance spanning the Provider Edge (PE) devices
   participating in that EVPN.

      Ethernet Tag: An Ethernet tag identifies a particular broadcast
   domain, e.g., a VLAN.  An EVPN instance consists of one or more
   broadcast domains.

      NVA: Network Virtualization Authority

      NVE: Network Virtualization Edge

      NVGRE: Network Virtualization using GRE

      VXLAN: Virtual eXtensible LAN

   3. Solution overview

   P-multicast group address allocation function is provided on
   NVA(centralized point), NVA and each NVE establish BGP EVPN session
   in beforehand for communication. NVA configures P-multicast group
   address pool and allocation policy ahead of time. A non-exhaustive
   list of allocation policies on NVA are described as follows:

   1. Per VN/VN plus C-Multicast group per P-Multicast group.

   2. Per NVE sets per P-Multicast group. If multiple VNs attach to same
      NVE devices, then a same P-Multicast group is allocated for these
      VNs.



Hao & Li,et,al        Expires September 8, 2016               [Page 4]


Internet-Draft NVO3 Multicast Group Auto-Provisioning       March 2016


   3. All VN share same P-Multicast group, but per P-Multicast group
      allocated per VN plus C-Multicast group.



   EVPN can be used for NVO3 network for both unicast and multicast
   traffic forwarding [EVPN-OVERLAY]. VNI to EVPN EVI mapping supports
   1:1 model and N:1 model.

   The E-VPN Multicast BGP route combined with a new BGP Extended
   Community attribute(P-Multicast Allocation Extended Community) is
   used for P-multicast group address auto-provisioning process. The
   new BGP Extended Community attribute is defined to identify the
   group address request and reply message, the attribute may be
   advertised along with the E-VPN Inclusive Multicast BGP route and
   the E-VPN Selective Multicast BGP route [EVPN-SELMCST]. The E-VPN
   Inclusive Multicast BGP route is used to discover the multicast
   tunnels among the NVEs associated with a VNI. The E-VPN Selective
   Multicast BGP route is used to discover the multicast tunnels among
   the NVEs associated with a VNI plus C-multicast group [EVPN-SELMCST].

   The P-Multicast group allocation interaction process between NVE and
   NVA is as follows:

   1. When a NVE detects a local VN creation or first C-multicast
      joining event, the NVE sends P-multicast group address request
      message to NVA(centralized point). PMSI Tunnel attribute isn't
      needed to be associated with the route. Request flag in the new
      BGP Extended Community attribute is set.

   2. NVA allocates P-multicast group address relying on local policy,
      and then sends P-multicast group address reply message to original
      NVE. The allocated P-multicast group address is carried in the
      tunnel identifier of PMSI Tunnel attribute. Reply flag in the new
      BGP Extended Community attribute is set. NVA records the mapping
      between P-Multicast group and NVE's information. The NVE's
      information includes the NVE's VTEP IP address, VNID or
      combination of VNID plus C-multicast group.

   3. The NVE sends E-VPN Multicast BGP route to other NVEs through
      regular EVPN process for multicast tunnel discovery [RFC7432]. The
      Multicast route is tagged with the PMSI Tunnel attribute, which is
      used to encode the type of multicast tunnel to be used as well as
      the multicast tunnel identifier which fills the allocated P-
      multicast group address.




Hao & Li,et,al        Expires September 8, 2016               [Page 5]


Internet-Draft NVO3 Multicast Group Auto-Provisioning       March 2016


   The P-Multicast group release interaction process between NVE and
   NVA is as follows:

   1. When a NVE detects a local VN deletion or last C-multicast leaving
      event, the NVE sends P-multicast group address withdraw message to
      NVA(centralized point). PMSI Tunnel attribute isn't needed to be
      associated with the route. Request flag in the new BGP Extended
      Community attribute is set.

   2. NVA releases local record of the NVE's information. If this is the
      last NVE using the P-Multicast group, the NVA will release the P-
      Multicast group to pool for future re-allocation.



   For the network wide global unique VNID, RD field can be set to zero
   in the allocation request and reply message, NVA relies on the VNID
   to allocate P-Multicast group address. For NVE local VNID, RD should
   be used to identify each virtual network, NVA relies on the global
   unique RD to allocate P-Multicast group address.



   4. BGP Protocol extension

4.1.  P-Multicast Allocation Extended Community

   This Extended Community is a new transitive Extended Community
   having a Type field value of 0x06 and the Sub-Type TBD.  It may be
   advertised along with Inclusive Multicast Ethernet Tag Routes or
   Selective Multicast Ethernet Tag Route.

   Each P-Multicast Allocation extended community is encoded as an 8-
   octet value, as follows:

      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=0x06     | Sub-Type=TBD  |G|R|     Reserved=0            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Reserved=0                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The "G" bit of 1 indicates "Request" message. The "R" bit of 1
   indicates "Reply" message.




Hao & Li,et,al        Expires September 8, 2016               [Page 6]


Internet-Draft NVO3 Multicast Group Auto-Provisioning       March 2016


   5. Security Considerations

   NVA processes all NVE's P-Multicast group address allocation request
   message, it is vulnerable for attacking by inappropriate NVE in data
   center. NVE's identity should be strictly inspected on NVA, possible
   security solution need to be further researched.

   6. IANA Considerations

   IANA is requested to allocate the following EVPN Extended Community
   sub-type besides [RFC7432].



         0x00     MAC Mobility                 [RFC7432]

         0x01     ESI Label                    [RFC7432]

         0x02     ES-Import Route Target       [RFC7432]

         TBD      P-Multicast Allocation       [This document]



   6.1. Normative References

   [1]  [NVO3MFM] A. Ghanwani, et al, "A Framework for Multicast in
         NVO3",draft-ietf-nvo3-mcast-framework-00, work in progress.
         May 10, 2015.

   [2]  [EVPN-OVERLAY] A. Sajassi, et al, "A Network Virtualization
         Overlay Solution using EVPN"draft-sd-l2vpn-evpn-overlay-03,
         work in progress. June 18, 2014.

   [3]  [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN",
         RFC7432, February 2015.

   [4]  [NVO3-ARCH] Narten, T. et al.," An Architecture for Overlay
         Networks (NVO3)", work in progress, February 2014.

   [5]  [NVO3-ARCH] J. Zhang, Z. Li, ''Selective Multicast in EVPN'',
         draft-zhang-l2vpn-evpn-selective-mcast-01, work in progress,
         July 2014.






Hao & Li,et,al        Expires September 8, 2016               [Page 7]


Internet-Draft NVO3 Multicast Group Auto-Provisioning       March 2016


   6.2. Informative References

   [1]  [RFC7348] Mahalingam, M. et al., "Virtual eXtensible Local
         Area Network (VXLAN): A Framework for Overlaying Virtualized
         Layer 2 Networks over Layer 3 Networks", August 2014.

   [2]  [NVGRE]   Sridharan, M. et al., "NVGRE: Network virtualization
         using Generic Routing Encapsulation", work in progress.

   [3]  [ISIS-Multicast] L. Yong, et al, "ISIS Protocol Extension For
         Building Distribution Trees", work in progress. Oct 2013.



   7. Acknowledgments

   The authors wish to acknowledge the important contributions of
   Yisong Liu, Shunwan Zhuang and Qiandeng Liang.






























Hao & Li,et,al        Expires September 8, 2016               [Page 8]


Internet-Draft NVO3 Multicast Group Auto-Provisioning       March 2016


   Authors' Addresses

   Weiguo Hao
   Huawei Technologies
   101 Software Avenue,
   Nanjing 210012
   China
   Email: haoweiguo@huawei.com

   Yizhou Li
   Huawei Technologies
   101 Software Avenue,
   Nanjing 210012
   China
   Email: liyizhou@huawei.com


   Lili Wang
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China
   Email: lily.wong@huawei.com

























Hao & Li,et,al        Expires September 8, 2016               [Page 9]