Skip to main content

Enhancements to Multicast Source Redundancy in EVPN Networks
draft-nagaraj-bess-evpn-redundant-mcast-src-update-00

Document Type Active Internet-Draft (individual)
Authors Vinod Kumar Nagaraj , Vikram Nagarajan , Zhaohui (Jeffrey) Zhang , Jorge Rabadan
Last updated 2022-10-24
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-nagaraj-bess-evpn-redundant-mcast-src-update-00
bess                                                          V. Nagaraj
Internet-Draft                                              V. Nagarajan
Intended status: Standards Track                                Z. Zhang
Expires: 27 April 2023                                  Juniper Networks
                                                              J. Rabadan
                                                                   Nokia
                                                         24 October 2022

      Enhancements to Multicast Source Redundancy in EVPN Networks
         draft-nagaraj-bess-evpn-redundant-mcast-src-update-00

Abstract

   draft-ietf-bess-evpn-redundant-mcast-source specifies Warm Standby
   (WS) and Hot Standby (HS) procedures for handling redundant multicast
   traffic into an EVPN tenant domain.  With the Hot Standby procedure,
   multiple ingress PEs may inject traffic and an egress PE will decide
   from which ingress PE traffic will be accepted and forwarded.  The
   decision is based on certain signaling messages and/or BFD status of
   provider tunnels from the ingress PEs, and the traffic is associated
   with ingress PEs based on Ethernet Segment Identifier (ESI) labels.
   As a result, the procedures in that document only apply to MPLS data
   plane.  This document extends the Hot Standby procedures to non-MPLS
   data planes and EVPN Data Center Interconnect scenarios.

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 https://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 27 April 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Nagaraj, et al.           Expires 27 April 2023                 [Page 1]
Internet-Draft   EVPN Multicast Source Redundancy Update    October 2022

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Hot Standby mode in non-MPLS IP tunnels . . . . . . . . .   3
     1.2.  EVPN DCI Use Case . . . . . . . . . . . . . . . . . . . .   3
       1.2.1.  True Source Redundancy  . . . . . . . . . . . . . . .   3
       1.2.2.  GW-introduced Flow Redundancy . . . . . . . . . . . .   4
       1.2.3.  Co-existence of Source Redundancy and GW-introduced
               Redundancy  . . . . . . . . . . . . . . . . . . . . .   5
   2.  Specifications  . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Hot Standby Procedures for non-MPLS IP tunnels  . . . . .   5
     2.2.  Procedures for EVPN DCI Use Case  . . . . . . . . . . . .   7
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Background

   [I-D.ietf-bess-evpn-redundant-mcast-source] specifies Warm Standby
   and Hot Standby procedures for handling redundant multicast traffic
   into an EVPN tenant domain.  With the Hot Standby procedure, multiple
   ingress PEs will inject traffic and an egress PE will decide from
   which ingress PE traffic will be accepted and forwarded.

   The PEs that inject redundant traffic advertises Selective Provider
   Multicast Service Interface (S-PMSI) A-D routes.  The routes carry an
   EVPN Multicast Flags Extended Community with a bit to indicate that
   matching traffic is from redundant sources.  With MPLS data plane,
   the routes also carry an Ethernet Segment Identifier (ESI) label,
   indicating the Ethernet Segment on which the traffic is received.

   When an egress PE receives S-PMSI A-D routes, it decides from which
   ingress PE it should accept the traffic.  The decision could be based
   on the following factors:

Nagaraj, et al.           Expires 27 April 2023                 [Page 2]
Internet-Draft   EVPN Multicast Source Redundancy Update    October 2022

   *  The presence/lack of S-PMSI A-D routes from ingress PEs of the
      redundant traffic

   *  The presence/lack of Ethernet A-D per EVI routes from ingress PEs
      for the Ethernet Segment that redundant traffic arrives on

   *  BFD status of provider tunnels for redundant traffic

   All the above options are local behaviors on individual egress PEs.

1.1.  Hot Standby mode in non-MPLS IP tunnels

   With MPLS data plane, the Hot Standby redundant flows from different
   PEs are distinguished via ESI labels.  With non-MPLS IP
   encapsulations like VXLAN/NVGRE, this document specifies that the
   redundant flows are distinguished by the source IP address (Source
   VTEP IP) in the outer IP header.

   This document also makes explicit that non-MPLS IP tunnels that carry
   an identifier of the source Ethernet Segment reuse all the procedures
   of [I-D.ietf-bess-evpn-redundant-mcast-source] for Hot Standby
   redundancy.  Examples of these tunnels used by EVPN are GENEVE
   [I-D.ietf-bess-evpn-geneve] and SRv6 [RFC9252].

1.2.  EVPN DCI Use Case

   When an EVPN network is used as Data Center Interconnect (DCI) for
   DCs (e.g., VxLAN or EVPN), multiple gateways (GWs) are placed between
   a DC and DCI, as described in [RFC9014].  A virtual Ethernet Segment
   is defined for each EVPN (the DC and/or DCI) and multi-homed to the
   GWs.  A Designated Forwarder (DF) is elected for each virtual ES
   (ethernet segment).  Each GW can receive the same BUM traffic from a
   DC/DCI EVPN but only the DF will forward traffic to the next DCI/DC
   (corresponding to the virtual ES).

   This section discusses how source redundancy works with DCI, and how
   DCI GWs can optionally introduce redundant flows even when there is
   no source redundancy at source DC.

1.2.1.  True Source Redundancy

   [I-D.ietf-bess-evpn-redundant-mcast-source] is MPLS-based.  It is
   "true" source redundancy in that multiple of sources of the same flow
   are attached to different Ethernet Segments.  S-PMSI A-D routes
   announce the redundant flows and carry ESI Label Extended Communities
   (ECs) for the ESes so that an egress PE can choose from which source
   ES the packets will be accepted.

Nagaraj, et al.           Expires 27 April 2023                 [Page 3]
Internet-Draft   EVPN Multicast Source Redundancy Update    October 2022

   With DCI, the source ESes are hidden outside the source DC, and
   different DC/DCI may use different data planes.  Additionally,
   currently only the GW that is the DF for the Interconnect Ethernet
   Segment (I-ES) will forward BUM traffic to the downstream DC/DCI, so
   the benefit of HS is lost once the first DC boundary is crossed.

   The above issues are solved as following:

   *  The GWs forward accepted redundant flows regardless of DF status.
      Note that, a GW will only accept one of the redundant flows from
      its redundant upstream PEs/GWs.

   *  The GWs remove ESI Label ECs when they re-originate the S-PMSI A-D
      routes into the next DC/DCI.  Note that, Even if the downstream
      DC/DCI is MPLS, the re-originated S-PMSI A-D routes do not carry
      the ESI Label EC for the I-ES.  This is because the GWs use the
      same ESI label for the I-ES, so the ESI label cannot be used to
      distinguish the flows.

   *  When the S-PMSI A-D routes do not carry ESI Label ECs, an egress
      PE chooses from which PE/GW (vs.  ES) to accept traffic from.

      -  In case of IP based data plane, this is the same as non-DCI
         case.

      -  In case of MPLS data plane, a PE needs to be able to
         distinguish from which node the traffic is.  In some cases, the
         PE Distinguisher Label concept [RFC6513] need to be used.

1.2.2.  GW-introduced Flow Redundancy

   In the "true source redundancy" case, S-PMSI A-D routes announce the
   redundancy and the DCI GWs always forward accepted flows regardless
   of the DF status.

   The GWs may also forward all BUM traffic regardless of DF status -
   not just those redundant flows announced by S-PMSI A-D routes.  This
   creates a similar scenario of source redundancy, though it is
   introduced by the GWs.  A downstream GW/PE can choose which redundant
   flows need to be accepted/discarded based on the A-D per ES routes
   for the I-ES instead of S-PMSI A-D routes.

   This requires that all downstream PEs/GWs behave consistently.  That
   is ensured either based on provisioning or based on signaling
   (details to be added in a future revision).

Nagaraj, et al.           Expires 27 April 2023                 [Page 4]
Internet-Draft   EVPN Multicast Source Redundancy Update    October 2022

   In the "true source redundancy" case, all flows covered by the (_, g)
   or (s-prefix, g) in the S-PMSI A-D routes are treated as redundant
   flows.  In the GW-introduced redundancy, (_, g) flows are treated as
   distinct flows that have redundant copies.  They may be from
   different PEs in the local DC and all must be accepted, or they may
   be from different DCs in which case only traffic from one GW for each
   upstream DC can be accepted, as explained below.

   Consider that a DCI interconnects three DCs.  GW1a/GW1b connect DC1
   and the DCI, GW2a/GW2b connect DC2 and the DCI, and GW3a/GW3b connect
   DC3 and the DCI.

   An egress PE1 in DC1 may need to accept and forward (_, G) traffic
   from all local PEs in DC1 and GW1a but not from the GW1b.  To do so,
   it installs a (_, G) forwarding state in a BD (Broadcast Domain) with
   indication that traffic from GW1b must be discarded.  Similarly,
   GW3a/GE3b may need to accept and forward (_, G) traffic from GW1a/
   GW2a but not from GW1b/GW2b.  To do so, it installs a (_, G)
   forwarding state with indication that traffic from GW1b/GW2b must be
   discarded.

   The reverse logic (of specifying PEs/GWs from which traffic should
   not be accepted) is only needed for (*, G) entries in the DCI case.
   For (S, G) case, the reverse logic is not needed because an egress PE
   should be able to decide from which PE/GW the traffic should be
   accepted.

1.2.3.  Co-existence of Source Redundancy and GW-introduced Redundancy

   Both flavors of redundancy can co-exist.  For redundant flows
   announced by S-PMSI A-D routes, the method described in Section 1.2.1
   is used.  For GW-introduced redundancy, the method described in
   Section 1.2.2 is used.  The difference between the two on downstream
   PEs/GWs is that one uses S-PMSI A-D routes while the other uses I-ES
   A-D per ES routes to choose which flow to accept, and for (*,g) flows
   in the latter case, reverse logic is needed.

2.  Specifications

2.1.  Hot Standby Procedures for non-MPLS IP tunnels

   In case the EVPN network uses non-MPLS IP tunnels without source
   Ethernet Segment identification, e.g., VXLAN/NVGRE, the procedures in
   [I-D.ietf-bess-evpn-redundant-mcast-source] for Hot Standby
   redundancy are modified as follows:

Nagaraj, et al.           Expires 27 April 2023                 [Page 5]
Internet-Draft   EVPN Multicast Source Redundancy Update    October 2022

   *  The S-PMSI A-D routes advertised for each SFG (Single Flow Group)
      by the upstream PEs MUST NOT carry any ESI Label Extended
      Communities.  The rest of the procedures on the upstream PEs
      remain the same.

   *  Upon receiving the S-PMSI A-D routes, the downstream PEs select a
      primary upstream PE out of the list of (S-PMSI A-D route) next
      hops and add an RPF check to the (_,G)/(S,G) state in the BD or
      SBD (Supplementary Broadcast Domain).  This RPF check discards all
      ingress packets to (_,G)/(S,G) that are not received from the
      selected primary Source VTEP.  The selection of the primary
      upstream PE is a matter of local policy, for instance, an egress
      PE could keep track of traffic statistics of redundant flows and
      dynamically decide which flow is accepted based on traffic
      threshold information.

      The selection of the upstream PE for non-MPLS IP tunnels, instead
      of the primary Source Ethernet Segment, provides a solution for
      redundant sources connected to different upstream PEs, however it
      MUST NOT be used when the redundant sources are connected to the
      same upstream PE, or multi-homed to the same set of upstream PEs.

      In case the EVPN network uses non-MPLS IP tunnels that can carry a
      source Ethernet Segment identification, e.g., GENEVE or SRv6, all
      the procedures in [I-D.ietf-bess-evpn-redundant-mcast-source] for
      Hot Standby redundancy are followed.  The following considerations
      apply:

   *  In case of GENEVE [I-D.ietf-bess-evpn-geneve], an Ethernet option
      TLV MUST encode the ESI (Ethernet Segment Identifier) label value.
      This ESI label value is signaled by the EVPN A-D per ES routes,
      and advertised for SFG sources in S-PMSI A-D routes in the ESI
      Label Extended Communities as described in
      [I-D.ietf-bess-evpn-redundant-mcast-source].  The downstream PE
      can identify the packets coming from a selected primary Source
      Ethernet Segment based on a lookup on the Source Identifier of the
      Ethernet option TLV.

Nagaraj, et al.           Expires 27 April 2023                 [Page 6]
Internet-Draft   EVPN Multicast Source Redundancy Update    October 2022

   *  In case of SRv6 [RFC9252], the upstream PEs send multicast packets
      encapsulated in SRv6 tunnels that use End.DT2M as function and
      Arg.FE2 as argument.  The Arg.FE2 argument in the packets identify
      the Source Ethernet Segment.  The argument is signaled by the EVPN
      A-D per ES routes as specified in [RFC9252], and this document
      uses the same encoding of the argument also for the S-PMSI A-D
      routes that signal the Source Ethernet Segments for SFG sources,
      with the consideration that there may be multiple arguments
      signaled and that the arguments for the same Ethernet Segment in
      different upstream PEs MUST match.  The downstream PE can then
      identify the packets coming from a selected primary Source
      Ethernet Segment based on the received argument.

2.2.  Procedures for EVPN DCI Use Case

   To be added.

3.  Security Considerations

   No additional security considerations are needed besides what are in
   [I-D.ietf-bess-evpn-redundant-mcast-source].

4.  Acknowledgements

5.  References

5.1.  Normative References

   [I-D.ietf-bess-evpn-geneve]
              Boutros, S., Sajassi, A., Drake, J., Rabadan, J., and S.
              Aldrin, "EVPN control plane for Geneve", Work in Progress,
              Internet-Draft, draft-ietf-bess-evpn-geneve-04, 23 May
              2022, <https://www.ietf.org/archive/id/draft-ietf-bess-
              evpn-geneve-04.txt>.

   [I-D.ietf-bess-evpn-redundant-mcast-source]
              Rabadan, J., Kotalwar, J., Sathappan, S., Zhang, Z. J.,
              Lin, W., and E. C. Rosen, "Multicast Source Redundancy in
              EVPN Networks", Work in Progress, Internet-Draft, draft-
              ietf-bess-evpn-redundant-mcast-source-04, 7 October 2022,
              <https://www.ietf.org/archive/id/draft-ietf-bess-evpn-
              redundant-mcast-source-04.txt>.

   [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
              BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
              2012, <https://www.rfc-editor.org/info/rfc6513>.

Nagaraj, et al.           Expires 27 April 2023                 [Page 7]
Internet-Draft   EVPN Multicast Source Redundancy Update    October 2022

   [RFC9252]  Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
              B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
              Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
              DOI 10.17487/RFC9252, July 2022,
              <https://www.rfc-editor.org/info/rfc9252>.

5.2.  Informative References

   [RFC9014]  Rabadan, J., Ed., Sathappan, S., Henderickx, W., Sajassi,
              A., and J. Drake, "Interconnect Solution for Ethernet VPN
              (EVPN) Overlay Networks", RFC 9014, DOI 10.17487/RFC9014,
              May 2021, <https://www.rfc-editor.org/info/rfc9014>.

Authors' Addresses

   Vinod Kumar Nagaraj
   Juniper Networks
   Email: vinkumar@juniper.net

   Vikram Nagarajan
   Juniper Networks
   Email: vikramna@juniper.net

   Zhaohui Zhang
   Juniper Networks
   Email: zzhang@juniper.net

   Jorge Rabadan
   Nokia
   Email: jorge.rabadan@nokia.com

Nagaraj, et al.           Expires 27 April 2023                 [Page 8]