Weighted Multi-Path Procedures for EVPN Multi-Homing
draft-ietf-bess-evpn-unequal-lb-21

7.3.  Weighted Load-balancing without EVPN aliasing

   [RFC7432] defines per-[ES, EVI] RT-1 based EVPN aliasing procedure as
   an optional propcedure.  In an unlikely scenario where an EVPN
   implementation does not support EVPN aliasing procedures, MAC
   forwarding path-list at the ingress PE is computed based on per-ES
   RT-1 and RT-2 routes received from egress PEs instead of per-ES RT-1
   and per-[ES, EVI] RT-1 from egress PEs.  In such a case, only the
   weights received via per-ES RT-1 from the egress PEs included in the
   MAC path-list are to be considered for weighted path-list
   computation.

7.4.  EVPN IRB Multi-homing With Non-EVPN routing

   EVPN-LAG based multi-homing on an IRB gateway may also be deployed
   together with non-EVPN routing, such as global routing or an L3VPN
   routing control plane.  Key property that differentiates this set of
   use cases from EVPN IRB use cases discussed earlier is that EVPN
   control plane is used only to enable LAG interface based multi-homing
   and not as an overlay VPN control plane.  Applicability of weighted
   ECMP procedures specified in this document to these set of use cases
   is an area of further consideration beyond the scope of this
   document.

8.  Operational Considerations

   *  In order for the solution specified in this document to function
      correctly, implementation SHOULD ensure that EVPN Link Bandwidth
      Extended Comminiuty is being advertised with same "Value-Units"
      across all PEs.

   *  Further, when a generalized weight option is used with "Value-
      Units = 0x1", implementation SHOULD ensure that the weights are
      assigned to each PE in a consistent manner.

   *  Implementation SHOULD alert the users via syslog when an
      inconsistency in "Value-Units" is detected across the PE set for a
      given ESI or prefix.

   *  Implementation SHOULD also alert users via syslog if an
      unreasonable discrepancy is detected across advertised BW or
      weights from different PEs, such that the implementation is unable
      to compute a weighted pathlist that can be programmed in hardware.
      This could likely result from inconsistent units of weight used by
      different PEs.

Malhotra, et al.           Expires 9 June 2024                 [Page 18]
Internet-Draft         EVPN Weighted Multi-Pathing         December 2023

   *  Operators MAY monitor the traffic flow distribution and DF
      election distribution across the egress PE set to ensure that the
      implementation is working as expected.

9.  Security Considerations

   Security considerations discussed in [RFC7432] and [RFC8584] apply to
   this document.  Methods described in this document further extend
   signaling of multi-homed devices using ESI LAG.  They are hence
   subject to same considerations if the control plane or data plane was
   to be compromised.  As an example, if control plane is compromised,
   signaling of heavily skewed Link Bandwidth Attributes could result in
   all traffic to be directed towards one PE resulting in its host
   facing links to be overloaded.  Exposure to such an attack is limited
   by suggested syslogs discussed in Operational Consideration section.
   Considerations for protecting control and data plane described in
   [RFC7432] are equally applicable to signaling of Link Bandwidth
   Attribute defined in this document.

10.  IANA Considerations

   [RFC8584] defines a new extended community for PEs within a
   redundancy group to signal and agree on uniform DF Election Type and
   Capabilities for each ES.  This document requests IANA to allocate a
   bit in the "DF Election capabilities" registry setup by [RFC8584]
   with the following suggested bit number:

   Bit 4: BW (Bandwidth Weighted DF Election)

   A new EVPN Link Bandwidth extended community is defined to signal
   local ES link bandwidth to ingress PEs.  This extended community is
   defined of type 0x06 (EVPN Extended Community Sub-Types).  IANA has
   assigned a sub-type value of 0x10 for the EVPN Link bandwidth
   extended community, of type 0x06 (EVPN Extended Community Sub-Types).
   EVPN Link Bandwidth extended community is defined as transitive.

   IANA is requested to set up a registry called "Value-Units" for the
   1-octet field in the EVPN Link Bandwidth Extended Community.  New
   registrations will be made through the "RFC Required" procedure
   defined in [RFC8126].  The following are suggested initial values in
   that registry exist:

   Value       Name                             Reference
   ----        ----------------                 -------------
   0           Weight in units of Mbps          This document
   1           Generalized Weight               This document
   2-255       Unassigned

Malhotra, et al.           Expires 9 June 2024                 [Page 19]
Internet-Draft         EVPN Weighted Multi-Pathing         December 2023

11.  Acknowledgements

   Authors would like to thank Satya Mohanty for valuable review and
   inputs with respect to HRW and weighted HRW algorithm refinements
   specified in this document.  Authors would also like to thank Bruno
   Decraene and Sergey Fomin for valuable review and comments.

12.  Contributors

   Satya Ranjan Mohanty
   Cisco Systems
   US
   Email: satyamoh@cisco.com

13.  References

13.1.  Normative References

   [EVPN-DF-PREF]
              Rabadan, J., Sathappan, S., Przygienda, T., Lin, W.,
              Drake, J., Sajassi, A., Mohanty, S., and , "Preference-
              based EVPN DF Election", Work in Progress, Internet-Draft,
              draft-ietf-bess-evpn-pref-df-06, 19 June 2020,
              <https://tools.ietf.org/html/draft-ietf-bess-evpn-pref-df-
              06.txt>.

   [EVPN-PER-MCAST-FLOW-DF]
              Sajassi, A., mishra, m., Thoria, S., Rabadan, J., and J.
              Drake, "Per multicast flow Designated Forwarder Election
              for EVPN", Work in Progress, Internet-Draft, draft-ietf-
              bess-evpn-per-mcast-flow-df-election-04, 31 August 2020,
              <http://www.ietf.org/internet-drafts/draft-ietf-bess-evpn-
              per-mcast-flow-df-election-04.txt>.

   [EVPN-VIRTUAL-ES]
              Sajassi, A., Brissette, P., Schell, R., Drake, J.,
              Rabadan, J., and , "EVPN Virtual Ethernet Segment", Work
              in Progress, Internet-Draft, draft-ietf-bess-evpn-virtual-
              eth-segment-06, 9 March 2020,
              <https://tools.ietf.org/html/draft-ietf-bess-evpn-virtual-
              eth-segment-06.txt>.

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

Malhotra, et al.           Expires 9 June 2024                 [Page 20]
Internet-Draft         EVPN Weighted Multi-Pathing         December 2023

   [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, <https://www.rfc-editor.org/info/rfc7432>.

   [RFC7814]  Xu, X., Jacquenet, C., Raszuk, R., Boyes, T., and B. Fee,
              "Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension
              Solution", RFC 7814, DOI 10.17487/RFC7814, March 2016,
              <https://tools.ietf.org/html/rfc7814>.

   [RFC8584]  Rabadan, J., Ed., Mohanty, R., Sajassi, N., Drake, A.,
              Nagaraj, K., and S. Sathappan, "Framework for Ethernet VPN
              Designated Forwarder Election Extensibility", RFC 8584,
              DOI 10.17487/RFC8584, April 2019,
              <https://www.rfc-editor.org/info/rfc8584>.

13.2.  Informative References

   [BGP-LINK-BW]
              Mohapatra, P. and R. Fernando, "BGP Link Bandwidth
              Extended Community", Work in Progress, Internet-Draft,
              draft-ietf-idr-link-bandwidth-07, March 2019,
              <https://tools.ietf.org/html/draft-ietf-idr-link-
              bandwidth-07.txt>.

   [RFC9135]  Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
              Rabadan, "Integrated Routing and Bridging in EVPN",
              RFC 9135, DOI 10.17487/RFC9135, October 2021,
              <https://www.rfc-editor.org/rfc/rfc9135>.

Appendix A.  BGP-Link-Bandwidth-Extended-Community

   Link bandwidth extended community described in [BGP-LINK-BW] for
   layer 3 VPNs was considered for re-use here.  This Link bandwidth
   extended community is however defined in [BGP-LINK-BW] as optional
   non-transitive.  Since it is not possible to change deployed behavior
   of extended community defined in [BGP-LINK-BW], it was decided to
   define a new one.  In inter-AS scenarios, link-bandwidth needs to be
   signaled to eBGP neighbors.  When signaled across AS boundary, this
   extended community can be used to achieve optimal load-balancing
   towards egress PEs in a different AS.  This is applicable both when
   next-hop is changed or unchanged across AS boundaries.

Authors' Addresses

Malhotra, et al.           Expires 9 June 2024                 [Page 21]
Internet-Draft         EVPN Weighted Multi-Pathing         December 2023

   Neeraj Malhotra (editor)
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA 95134
   United States of America
   Email: nmalhotr@cisco.com

   Ali Sajassi
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA 95134
   United States of America
   Email: sajassi@cisco.com

   Jorge Rabadan
   Nokia
   777 E. Middlefield Road
   Mountain View, CA 94043
   United States of America
   Email: jorge.rabadan@nokia.com

   John Drake
   Juniper
   Email: jdrake@juniper.net

   Avinash Lingala
   ATT
   200 S. Laurel Avenue
   Middletown, CA 07748
   United States of America
   Email: ar977m@att.com

   Samir Thoria
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA 95134
   United States of America
   Email: sthoria@cisco.com

Malhotra, et al.           Expires 9 June 2024                 [Page 22]