[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 draft-ietf-bess-evpn-irb-mcast

BESS                                                              W. Lin
Internet-Draft                                                  Z. Zhang
Intended status: Standards Track                                J. Drake
Expires: September 18, 2016                       Juniper Networks, Inc.
                                                              J. Rabadan
                                                                   Nokia
                                                          March 17, 2016


                 EVPN Inter-subnet Multicast Forwarding
                    draft-lin-bess-evpn-irb-mcast-02

Abstract

   This document describes inter-subnet multicast forwarding procedures
   for Ethernet VPNs (EVPN).

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

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 September 18, 2016.

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



Lin, et al.            Expires September 18, 2016               [Page 1]


Internet-Draft               evpn-irb-mcast                   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.  EVPN-aware Solution . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  IGMP/MLD Snooping Consideration . . . . . . . . . . . . .   5
     2.2.  Receiver sites not connected to a source subnet . . . . .   5
     2.3.  Receiver sites without IRB  . . . . . . . . . . . . . . .   6
     2.4.  Multi-homing Support  . . . . . . . . . . . . . . . . . .   7
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   EVPN offers an efficient L2 VPN solution with all-active multi-homing
   support for intra-subnet connectivity over MPLS/IP network.  EVPN
   also provides an integrated L2 and L3 service.  When forwarding among
   Tenant Systems (TS) across different IP subnets is required,
   Integrated Routing and Bridging (IRB) can be used [ietf-bess-evpn-
   inter-subnet-forwarding].

   An network virtualization endpoint (NVE) device supporting IRB is
   called a L3 Gateway.  In a centralized approach, a centralized
   gateway provides all L3 routing functionality, and even two tenant
   systems on two subnets connected to the same NVE need to go through
   the central gateway, which is inefficient.  In a distributed
   approach, each NVE has IRB configured, and inter-subnet traffic will
   be locally routed without having to go through a central gateway.

   Inter-subnet multicast forwarding is more complicated and not covered
   in [ietf-bess-evpn-inter-subnet-forwarding].  This document describes
   the procedures for inter-subnet multicast forwarding.

   For multicast traffic sourced from a TS in subnet 1, EVPN Broadcast,
   Unknow unicast, Multicast (BUM) forwarding based on RFC 7432, will
   deliver it to all sites in subnet 1.  When IRBs in subnet 1 receive
   the mulitcast traffic, they deliver to other corresponding IRBs in



Lin, et al.            Expires September 18, 2016               [Page 2]


Internet-Draft               evpn-irb-mcast                   March 2016


   other subnets at L3.  From L3 point of view, those NVEs are routers
   connected to the subnet via the IRB interfaces and the source is
   locally attached.  Nothing is different from a traditional LAN and
   regular IGMP/MLD/PIM procedures kick in.

   If a TS is a multicast receiver, it uses IGMP/MLD to signal its
   interest in some multicast flows.  One of the gateways is the IGMP/
   MLD querier for a given subnet.  It sends queries out the IRB for
   that subnet, which in turn causes the queries to be forwarded
   throughout the subnet following the EVPN BUM procedures.  TS's send
   IGMP/MLD joins via multicast, which are also forwarded throughout the
   subnet via EVPN BUM procedure.  The gateways receive the joins via
   their IRB interfaces.  From layer 3 point of view, again it is
   nothing different from a traditional LAN.

   On a traditional LAN, only one router can send multicast to the LAN.
   That is either the PIM Designated Router (DR) or IGMP/MLD querier
   (when PIM is not needed - e.g., the LAN is a stub network).  On the
   source subnet, PIM is typically needed so that traffic can be
   delivered to other subnets via other routers.  For example, in case
   of PIM-SM, the DR on the source network encapsulates the initial
   packets for a particular flow in PIM Register messages and unicasts
   the Register messages to the Rendezvous Point (RP) for that flow,
   triggering necessary states for that flow to be built throughout the
   network.

   That also works in the EVPN scenario, although not efficiently.
   Consider the example depicted in Figure 1, where a tenant has two
   subnets corresponding to two VLANs realized by two EVPN Instances
   (EVIs) at three sites.  The VLAN1 and VLAN 2 shown in Figure 1
   correspond to subnet 1 and subnet 2 respectively.  A multicast source
   is located at site 1 on subnet 1 and three receivers are located at
   site 2 on subnet 1, site 1 and 2 on subnet 2 respectively.  On subnet
   1, NVE1 is the PIM DR while on subnet 2, NVE3 is the PIM DR.  The
   connection drawn in Figure 1 among NVEs are L3 connections.

   Multicast traffic from the source at site 1 on subnet 1 is forwarded
   to all three sites on VLAN 1 following EVPN BUM procedure.  Rcvr1
   gets the traffic when NVE2 sends it out of its local Attachment
   Circuit (AC).  The three gateways for EVI1 also receive the traffic
   on their IRB interfaces to potentially route to other subnets.  NVE3
   is the DR on subnet 2 so it routes the local traffic (from L3 point
   of view) to subnet 2 while NVE1/2 is not the DR on subnet 2 so they
   don't.  Once traffic gets onto subnet 2, it is forwarded back to
   NVE1/2 and delivered to rcvr2/3 following the EVPN BUM procedures.

   Notice that both NVE1 and NVE2 receive the multicast traffic from
   subnet 1 on their IRB interfaces for subnet 1, but they do not route



Lin, et al.            Expires September 18, 2016               [Page 3]


Internet-Draft               evpn-irb-mcast                   March 2016


   to subnet 2 where they are not the PIM DRs.  Instead, they wait to
   receive traffic at L2 from NVE3.  For example, for receiver 3
   connected to NVE1 but on different IP subnet as the multicast source,
   the multicast traffic from source has to go from NVE1 to NVE3 and
   then back to NVE1 before it is being delivered to the receiver 3.
   This is similar to the hairpinning issue with centralized approach,
   here the multicast forwarding is centralized via the DR, even though
   distributed approach is being used for unicast (in that each NVE is
   supporting IRB and routing inter-subnet unicast traffic locally).


           site 1     .      site 2      .       site 3
                      .                  .
            src       .      rcvr1       .
             |        .        |         .
         --------------------------------------------  VLAN 1 (EVI1)
             |        .        |         .         |
         IRB1| DR     .    IRB1|         .     IRB1|
            NVE1------------NVE2-----------------NVE3---RP
         IRB2|        .    IRB2|         .     IRB2| DR
             |        .        |         .         |
         --------------------------------------------  VLAN 2 (EVI2)
             |        .        |         .
            rcvr3     .       rcvr2      .
                      .                  .
           site 1     .     site 2       .      site 3

           Figure 1 - EVPN IRB multicast scenario


2.  EVPN-aware Solution

   This multicast hairpinning can be avoided if the following procedures
   are followed:

   o  On the IRB interface, the gateway receives multicast traffic from
      a source subnet, it sends the traffic on its IRB interfaces to any
      other subnets that have receivers for the traffic, regardless
      whether the gateway is DR for that subnet or not.

   o  On the IRB interface, if a gateway receives Membership Reports
      from one of its ACs, it sends PIM joins towards the RP or source
      regardless if it is DR/querier or not.

   o  Multicast data traffic sent out of the IRB interfaces is forwarded
      to local ACs only and not to other EVPN sites.





Lin, et al.            Expires September 18, 2016               [Page 4]


Internet-Draft               evpn-irb-mcast                   March 2016


   Essentially, each router on an IRB interface behaves as a DR/querier
   for receivers (but only the true DR behaves as a DR for sources), and
   multicast data traffic from IRB interfaces is limited to local
   receivers.

   Note that link local multicast traffic (e.g. addressed to 224.0.0.x
   in case of IPv4)), typically use for protocols, is not subject to the
   above procedures and still forwarded to remote sites following EVPN
   procedures.

   In the example in Figure 1, when NVE1 gets traffic on its IRB1
   interface it will route the traffic out of its IRB2 and deliver to
   local rcvr3.  It also sends register messages to the RP, since it is
   the DR on the source network.  Both NVE2 and NVE3 will receive the
   traffic on IRB1 but neither sends register messages to the RP, since
   they are not the DR on the source subnet.  NVE2 will route the
   traffic out of its IRB2 and deliver to local rcvr2.  NVE3 will also
   route the traffic out of IRB2 even though there is no receiver at the
   local site, because the IGMP/MLD joins from rcvr2/3 are also received
   by NVE3.

2.1.  IGMP/MLD Snooping Consideration

   In the example in Figure 1, NVE3 receives IGMP/MLD joins from rcvr2/3
   and will route packets out of IRB2, even though there are no
   receivers at the local site.  IGMP/MLD snooping on NVE3 can prevent
   the traffic from actually being sent out of ACs but at L3 there will
   still be related states and processing/forwarding (e.g., IRB2 will be
   in the downstream interface list for PIM join states and forwarding
   routes).

   To prevent NVE3 from learning those remote receivers at all, IGMP/MLD
   snooping on NVE3 could optionally suppress the joins from remote
   sites being sent to its IRB interface.  With that, in the example in
   Figure 1, NVE3 will not learn of rcvr2/3 on IRB2 and will not try to
   route packets out of IRB2 at all.

2.2.  Receiver sites not connected to a source subnet

   In the example in Figure 1, the source subnet is connected to all
   NVEs that has receiver sites, and there are no receivers outside the
   EVPN network.  As a result, PIM is not really needed and each NVE can
   just route multicast traffic locally.  In that case, IGMP/MLD querier
   will be responsible to send traffic to a subnet.

   If there is a receiver subnet connected to an NVE that is not
   connected to the source subnet, then there must exist layer 3
   multicast paths between them.  This could be over an L3VPN core (in



Lin, et al.            Expires September 18, 2016               [Page 5]


Internet-Draft               evpn-irb-mcast                   March 2016


   this revision it is assumed that the subnets realized by EVPN are
   stub only and not transit) and normal PIM and MVPN procedures will be
   followed.

   The L3VPN routes can be propagated either per RFC 4364 procedures or
   per EVPN Type 5 procedures [bess-evpn-prefix-advertisement].  BGP-
   MVPN [RFC 6514] requires that the routes used for RPF checking carry
   two extended communities (ECs) - VRF Route Import EC and Source AS
   EC.  That must be applied to EVPN Prefix Advertisement (Type 5)
   routes as well.

2.3.  Receiver sites without IRB

   It is possible that a particular NVE may not have an IRB interface
   for its l2 domain.  In that case, for traffic from another l2 domain,
   receivers need to receive from another NVE following EVPN procedures.
   The obvious choice is that it receives from the DR of that subnet.
   Because an NVE does not deliver traffic out of IRBs to remote sites
   with IRB, the DR needs to use a separate provider tunnel to deliver
   traffic only to sites that do not have IRB interfaces.  The tunnel is
   advertised in new EVPN route type that is analogous to the MVPN
   "S-PMSI A-D" route [RFC6514].  This route will carry an EVPN Non-IRB
   Extended Community, indicating that a PE attached to the EVI
   identified in the route should join the advertised tunnel only if it
   does not have an IRB for that EVI.  The routes could be either be a
   (*,*) wildcard S-PMSI A-D routes if an inclusive tunnel is used (but
   only for all sites without IRBs), or individual (*,g)/(s,*) S-PMSI
   A-D routes if selective tunnels are used per [draft-zzhang-bess-evpn-
   bum-procedure-updates].  The (*,*) wildcard S-PMSI A-D route may be
   advertised by the NVE carrying Non-IRB Site extended community for
   each of its BD to deliver multicast traffic routed out of the IRB
   interface to remote sites that do not have IRBs.  Different RDs MUST
   be used for this (*, *) S-PMSI A-D route in the following case: if
   instead of an inclusive multicast Ethernet tag route, the NVE also
   uses (*,*) S-PMSI to deliver BUM traffic received from local ACs to
   remote PEs.

   If [draft-sajassi-bess-evpn-igmp-mld-proxy] procedures are used, then
   routes from those non-IRB sites MUST also carry the EVPN non-IRB
   extended community, so that the DR will only forward traffic to those
   non-IRB NVEs.

   The EVPN non-IRB Extended Community is a new EVPN extended community.
   EVPN extended communities are transitive extended community with a
   Type field of 6.  The subtype of this new EVPN extended community
   will be assigned by IANA, and with the following 8-octet encoding:





Lin, et al.            Expires September 18, 2016               [Page 6]


Internet-Draft               evpn-irb-mcast                   March 2016


        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  |  Flag(Octet)  | Reserved=0    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Reserved=0                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The lower-order bit of the Flag is defined as non-IRB bit.  A value
   one indicates non-IRB NVE.  The rest of the undefined bits are set to
   zero.

2.4.  Multi-homing Support

   The solution works equally well in multi-homing situations, as long
   as the multi-homed PEs attached to the same Ethernet segment have the
   same IRB capability, which is expected to be the normal deployment.

   As shown in Figure 2, both rcvr4 and rcvr5 are active-active multi-
   homed to NVE2 and NVE3.  Receiver 4 is on subnet VLAN 1 and receiver
   5 is on VLAN 2.  When IRBs on NVE1 and NVE2 forward multicast traffic
   to its local attached access interface(s) based on EVPN BUM
   procedure, only DF for the ES deliveries multicast traffic to its
   multi-homed receiver.  Hence no duplicated multicast traffic will be
   forwarded to receiver 4 or receiver 5.




                      .
            src       .        +-------- rcvr4-----+
             |        .        |         .         |
         --------------------------------------------  VLAN 1 (EVI1)
             |        .        |         .         |
         IRB1| DR     .    IRB1|         .     IRB1|
            NVE1------------NVE2-----------------NVE3---RP
         IRB2|        .    IRB2|         .     IRB2| DR
             |        .        |         .         |
         --------------------------------------------  VLAN 2 (EVI2)
             |        .        |         .         |
            rcvr3     .        +-------- rcvr5-----+
                      .

           Figure 2 - EVPN IRB multicast and multi-homing







Lin, et al.            Expires September 18, 2016               [Page 7]


Internet-Draft               evpn-irb-mcast                   March 2016


3.  IANA Considerations

   This document requests the following IANA assignments:

   o  A "Non-IRB Site" Sub-Type in "EVPN Extended Community Sub-Types"
      registry for the EVPN Non-IRB Extended Community.

   o  A "non-IRB" flag bit in the EVPN Non-IRB Extended Community.

4.  Security Considerations

   This document does not introduce new security risks.

5.  Acknowledgements

   The authors would like to thank Eric Rosen for his detailed review
   and valuable comments.

6.  References

6.1.  Normative References

   [I-D.sajassi-bess-evpn-igmp-mld-proxy]
              Sajassi, A., Patel, K., Thoria, S., Yeung, D., Drake, J.,
              and W. Lin, "IGMP and MLD Proxy for EVPN", draft-sajassi-
              bess-evpn-igmp-mld-proxy-00 (work in progress), October
              2015.

   [I-D.zzhang-bess-evpn-bum-procedure-updates]
              Zhang, J., Lin, W., Rabadan, J., and K. Patel, "Updates on
              EVPN BUM Procedures", draft-zzhang-bess-evpn-bum-
              procedure-updates-01 (work in progress), December 2015.

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

   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
              2015, <http://www.rfc-editor.org/info/rfc7432>.

6.2.  Informative References







Lin, et al.            Expires September 18, 2016               [Page 8]


Internet-Draft               evpn-irb-mcast                   March 2016


   [I-D.ietf-bess-evpn-inter-subnet-forwarding]
              Sajassi, A., Salam, S., Thoria, S., Rekhter, Y., Drake,
              J., Yong, L., and L. Dunbar, "Integrated Routing and
              Bridging in EVPN", draft-ietf-bess-evpn-inter-subnet-
              forwarding-00 (work in progress), November 2014.

   [I-D.ietf-bess-evpn-prefix-advertisement]
              Rabadan, J., Henderickx, W., Palislamovic, S., Balus, F.,
              and A. Isaac, "IP Prefix Advertisement in EVPN", draft-
              ietf-bess-evpn-prefix-advertisement-01 (work in progress),
              March 2015.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <http://www.rfc-editor.org/info/rfc4364>.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <http://www.rfc-editor.org/info/rfc6514>.

Authors' Addresses

   Wen Lin
   Juniper Networks, Inc.

   EMail: wlin@juniper.net


   Zhaohui Zhang
   Juniper Networks, Inc.

   EMail: zzhang@juniper.net


   John Drake
   Juniper Networks, Inc.

   EMail: jdrake@juniper.net


   Jorge Rabadan
   Nokia

   EMail: jorge.rabadan@nokia.com






Lin, et al.            Expires September 18, 2016               [Page 9]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/