doc: Add RFC documents

1 files changed, 589 insertions, 0 deletions

diff --git a/doc/rfc/rfc9541.txt b/doc/rfc/rfc9541.txt
new file mode 100644
index 0000000..13bc25c
--- /dev/null
+++ b/doc/rfc/rfc9541.txt
@@ -0,0 +1,589 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                   J. Rabadan, Ed.
+Request for Comments: 9541                                  S. Sathappan
+Category: Standards Track                                     K. Nagaraj
+ISSN: 2070-1721                                                    Nokia
+                                                               M. Miyake
+                                                              T. Matsuda
+                                                                Softbank
+                                                              March 2024
+
+
+  Flush Mechanism for Customer MAC Addresses Based on Service Instance
+    Identifier (I-SID) in Provider Backbone Bridging EVPN (PBB-EVPN)
+
+Abstract
+
+   Provider Backbone Bridging (PBB) can be combined with Ethernet
+   Virtual Private Networks (EVPNs) to deploy Ethernet Local Area
+   Network (E-LAN) services in large Multiprotocol Label Switching
+   (MPLS) networks.  That combination is what we refer to as "PBB-EVPN."
+   Single-Active multihoming and per Service Instance Identifier (I-SID)
+   load-balancing can be provided to access devices and aggregation
+   networks.  In order to speed up the network convergence in case of
+   failures on Single-Active multihomed Ethernet Segments (ESs), PBB-
+   EVPN defines a flush mechanism for Customer MACs (C-MACs) called
+   "C-MAC flush" that works for different Ethernet Segment Backbone MAC
+   (B-MAC) address allocation models.  This document complements those
+   C-MAC flush procedures for cases in which no PBB-EVPN ESs are defined
+   (i.e., the attachment circuit is associated with a zero Ethernet
+   Segment Identifier (ESI)) and the C-MAC flush requires I-SID-level
+   granularity.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9541.
+
+Copyright Notice
+
+   Copyright (c) 2024 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
+   (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.  Introduction
+     1.1.  Abbreviations
+     1.2.  Terminology and Conventions
+   2.  Solution Requirements
+   3.  EVPN BGP Encoding for I-SID-Based C-MAC Flush
+   4.  Solution Description
+     4.1.  I-SID-Based C-MAC Flush Activation Procedures
+     4.2.  C-MAC Flush Generation
+     4.3.  C-MAC Flush Process upon Receiving a C-MAC Flush
+           Notification
+   5.  Conclusions
+   6.  Security Considerations
+   7.  IANA Considerations
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   [RFC7623] defines how Provider Backbone Bridging (PBB) can be
+   combined with Ethernet Virtual Private Networks (EVPNs) to deploy
+   E-LAN services in very large MPLS networks.  [RFC7623] also describes
+   how Single-Active multihoming and per-I-SID load-balancing can be
+   provided to access devices and aggregation networks.  When Access
+   Ethernet and/or MPLS networks exist, [EVPN-VIRTUAL-ES] describes how
+   virtual Ethernet Segments (ESs) can be associated with a group of
+   Ethernet Virtual Circuits (EVCs) or even pseudowires (PWs).  In order
+   to speed up the network convergence in case of failures on Single-
+   Active multihomed ESs, [RFC7623] defines a Customer MAC flush
+   mechanism that works for different ES B-MAC address allocation
+   models.
+
+   In some cases, the administrative entities that manage the access
+   devices or aggregation networks do not demand multihomed ESs from the
+   PBB-EVPN provider, but simply demand multiple single-homed ESs.
+   Single-homed ESs use null ESIs, whereas multihomed ESs use non-null
+   ESIs.  If using single-homed ESs, the PBB-EVPN network is no longer
+   aware of the redundancy offered by the access administrative entity.
+   Figure 1 shows an example where the PBB-EVPN network provides four
+   different Attachment Circuits (ACs) for I-SID1, with those ACs not
+   being part of any ES or virtual ES.  (Therefore, they are referred to
+   as null virtual Ethernet Segments.)
+
+   <----G.8032----><--PBB-EVPN Network-----><----MPLS---->
+        Access          MPLS                Access
+         Ring                               Network
+   I-SID1      ESI +------+         +------+
+   +----+      null| PE1  |---------| PE3  |
+   |CE1 |----------|B-MAC1|         |B-MAC3| ESI null
+   +----+    active|      |         |      |----+ PW
+     |             +------+         +------+     \active
+     |               |                 |          \  +----+
+     |               |                 |           ==|CE3 |I-SID1
+     |               |                 |          /  +----+
+     |standby  ESI +------+         +------+     / PW
+   +----+      null| PE2  |         | PE4  |----+ standby
+   |CE2 |----------|B-MAC2|         |B-MAC4| ESI null
+   +----+    active|      |---------|      |
+   I-SID1          +------+         +------+
+
+               Figure 1: PBB-EVPN and Non-ES-Based Redundancy
+
+   In the example in Figure 1, CE1, CE2, and CE3 are attached to the
+   same service, identified by I-SID1, in the PBB-EVPN PEs.  CE1 and CE2
+   are connected to the PEs via "Ethernet ring protection switching" as
+   specified in [G.8032], and their ACs to PE1 and PE2 are represented
+   by a port and VLAN identifier.  CE3 is dual-homed to PE3 and PE4
+   through an active/standby PW, and its AC to the PEs is represented by
+   a PW.  Each of the four PEs uses a dedicated Backbone MAC address as
+   a source MAC address (B-MAC1, B-MAC2, B-MAC3, and B-MAC4,
+   respectively) when encapsulating customer frames in PBB packets and
+   forwarding those PBB packets to the remote PEs as per [RFC7623].
+   There are no multihomed ESs defined in the PBB-EVPN network of the
+   example; that is why the four ACs in Figure 1 show the text "ESI
+   null", which means the Ethernet Segment Identifier on those ACs is
+   zero.  Since there are no multihomed ESs defined, the PEs keep their
+   ACs active as long as the physical connectivity is established and
+   the CEs are responsible for managing the redundancy, avoiding loops,
+   and providing per-I-SID load-balancing to the PBB-EVPN network.
+   Examples of CEs managing their own redundancy are described in
+   [G.8032], or [RFC4762] for active/standby PWs.
+
+   For instance, in normal conditions, CE2 will block its link to CE1
+   and CE3 will block its forwarding path to PE4.  In this situation, a
+   failure in one of the redundant ACs will trigger the CEs to start
+   using their redundant paths; however, those failures will not trigger
+   any C-MAC flush procedures in the PEs that implement [RFC7623], since
+   the PEs are not using the PBB-EVPN multihoming procedures.  For
+   example:
+
+   *  If the active PW from CE3 (to PE3) fails and the failure is due to
+      the entire PE3 node failing, then the procedures in [RFC7623]
+      guarantee that all the remote PEs flush all the C-MACs associated
+      with B-MAC3 (the B-MAC of PE3).  In this case, CE3 detects the
+      fault due to the PW going operationally down.
+
+   *  However, if the active PW from CE3 (to PE3) fails (but PE3 is
+      still operationally up), following the procedures in [RFC7623],
+      neither PE3 nor PE4 issue a C-MAC flush message.  Therefore, the
+      remote PEs will continue pointing at PE3's B-MAC to reach CE3's
+      C-MACs, until the C-MACs age out in the I-SID1 forwarding tables.
+      In this case, PE3 may use any of the existing PW notifications so
+      that CE3 switches the active PW to PE4.
+
+   *  The same issue is exposed when the active PW from CE3 switches
+      over from PE3 to PE4 due to a manual operation on CE3; that is,
+      neither PE3 nor PE4 trigger any C-MAC flush notification and the
+      remote PEs continue sending the traffic to PE3 until the C-MACs
+      age out.
+
+   [RFC7623] provides a C-MAC flush solution based on a shared B-MAC
+   update along with the MAC Mobility extended community where the
+   sequence number is incremented.  However, the procedure is only used
+   along with multihomed ESs.  Even if that procedure could be used for
+   null ESs, as in the example of Figure 1, the Customer MAC flush
+   procedure in [RFC7623] would result in unnecessary flushing of
+   unaffected I-SIDs on the remote PEs, and subsequent flooding of
+   unknown unicast traffic in the network.  For instance, in the case
+   that CE3 switches its active PW over to PE4, a potential solution
+   reusing the existing C-MAC flush notifications in [RFC7623] is for
+   PE3 to issue an update for the MAC/IP Advertisement route of B-MAC3
+   with a higher sequence number.  However, this update would cause
+   unnecessary Customer MAC flushing for all the I-SIDs attached to PE3
+   (supposing multiple I-SIDs in PE3) rather than for only I-SID1.
+
+   This document describes an extension of the Customer MAC flush
+   procedures in [RFC7623], so that in the failure example above, PE3
+   can trigger a Customer MAC flush notification that makes PE1, PE2,
+   and PE4 flush all the Customer MACs associated with PE3's B-MAC3 and
+   (only) I-SID1.  In order to do so, this specification introduces the
+   encoding of the I-SID in the MAC/IP Advertisement routes advertised
+   for the B-MACs.  The C-MAC flush procedure explained in this document
+   is referred to as "PBB-EVPN I-SID-based C-MAC flush" and can be used
+   in PBB-EVPN networks with null or non-null (virtual) ESs.
+
+   This specification assumes that the reader is familiar with the
+   procedures in [RFC7623].
+
+1.1.  Abbreviations
+
+   AC:  Attachment Circuit
+
+   B-MAC:  Backbone MAC
+
+   CE:  Customer Edge
+
+   C-MAC:  Customer MAC
+
+   ES:  Ethernet Segment
+
+   ESI:  Ethernet Segment Identifier
+
+   EVI:  EVPN Instance
+
+   EVPN:  Ethernet Virtual Private Network (as in [RFC7432])
+
+   I-SID:  Service Instance Identifier
+
+   MAC:  Media Access Control
+
+   MAC-VRF:  MAC Virtual Routing and Forwarding
+
+   PBB-EVPN:  Provider Backbone Bridging and EVPN (as in [RFC7623])
+
+   PE:  Provider Edge
+
+1.2.  Terminology and Conventions
+
+   Familiarity with the terminology in [RFC7623] is expected.
+
+   B-MAC/0 route:  This is an EVPN MAC/IP Advertisement route that uses
+      a B-MAC in the MAC address field and a zero Ethernet Tag ID.
+
+   B-MAC/I-SID route:  This is an EVPN MAC/IP Advertisement route that
+      uses a B-MAC in the MAC address field and an I-SID in the Ethernet
+      Tag field.  It is used to notify remote PEs about the required
+      C-MAC flush procedure for the C-MACs associated with the
+      advertised B-MAC and I-SID.
+
+   G.8032:  Refers to Ethernet ring protection switching as described in
+      [G.8032].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  Solution Requirements
+
+   The following requirements are followed by the C-MAC flush solution
+   described in this document:
+
+   a.  The solution MUST prevent packet-loss scenarios in case of
+       failures on null ES ACs (Attachment Circuits not associated with
+       an ES; that is, their corresponding ESI is zero) when the access
+       device or access network is responsible for the redundancy.
+
+   b.  This extension described in this document MUST work with Single-
+       Active non-null ESs and virtual ESs, irrespective of the PE B-MAC
+       address assignment (dedicated per-ES B-MAC or shared B-MAC, as in
+       [RFC7623]).
+
+   c.  In case of failure on the egress PE, the solution MUST provide a
+       C-MAC flush notification at the B-MAC and I-SID granularity
+       level.
+
+   d.  The solution MUST provide a reliable C-MAC flush notification in
+       PBB-EVPN networks that use Route Reflectors (RRs).  MAC flushing
+       needs to be provided to all affected I-SIDs in spite of the BGP
+       flush notification messages being aggregated at the RR.
+
+   e.  The solution MUST coexist in [RFC7623] networks where there are
+       PEs that do not support this specification.
+
+   f.  The solution SHOULD be enabled or disabled by an administrative
+       option on a per-PE and per-I-SID basis (as opposed to always
+       being enabled for all the I-SIDs).
+
+3.  EVPN BGP Encoding for I-SID-Based C-MAC Flush
+
+   The solution does not use any new BGP attributes but reuses the MAC
+   Mobility extended community as an indication of C-MAC flush (as in
+   [RFC7623]) and encodes the I-SID in the Ethernet Tag field of the
+   EVPN MAC/IP advertisement route.  As a reference, Figure 2 shows the
+   MAC Mobility extended community and the EVPN MAC/IP advertisement
+   route that are used as specified in [RFC7432] and used in this
+   document as a C-MAC flush notification message.
+
+   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=0x03 |   Flags       |   Reserved=0  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Sequence Number                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+               +---------------------------------------+
+               |  Route Distinguisher                  |
+               +---------------------------------------+
+               |  ESI = 0                              |
+               +---------------------------------------+
+               |  Ethernet Tag ID = I-SID              |
+               +---------------------------------------+
+               |  MAC Address Length = 48              |
+               +---------------------------------------+
+               |  B-MAC Address                        |
+               +---------------------------------------+
+               |  IP Address Length = 0                |
+               +---------------------------------------+
+               |  MPLS Label1                          |
+               +---------------------------------------+
+
+       Figure 2: C-MAC Flush Notification Encoding: B-MAC/I-SID Route
+
+   Where:
+
+   *  The route's route distinguisher and route targets are the ones
+      corresponding to its EVI.  Alternatively to the EVI's Route Target
+      (RT), the route MAY be tagged with an RT auto-derived from the
+      Ethernet Tag (I-SID) instead.  [RFC7623] describes how the EVPN
+      MAC/IP Advertisement routes can be advertised along with the EVI
+      RT or an RT that is derived from the I-SID.
+
+   *  The Ethernet Tag encodes the I-SID.  This indicates to the PE that
+      it must flush the C-MACs for that encoded I-SID, upon reception of
+      the route.
+
+   *  The MAC address field encodes the B-MAC address.  This indicates
+      to the PE that it must flush the C-MACs associated with that
+      encoded B-MAC, upon reception of the route.
+
+   *  The MAC Mobility extended community is used as in [RFC7623], where
+      an increment in the sequence number between two updates for the
+      same B-MAC/I-SID will be interpreted as a C-MAC flush notification
+      for the corresponding B-MAC and I-SID.
+
+   All the other fields are set and used as defined in [RFC7623].  This
+   document will refer to this route as the "B-MAC/I-SID route", as
+   opposed to the EVPN MAC/IP Advertisement route used in [RFC7623] that
+   contains a specific B-MAC and the Ethernet Tag ID set to zero.  This
+   document uses the term "B-MAC/0 route" to represent a B-MAC route
+   advertised with an Ethernet Tag ID = 0.
+
+   Note that this B-MAC/I-SID route will be accepted and reflected by
+   any RR as specified in [RFC7432], since no new attributes or values
+   are used.  A PE receiving the route will process the received B-MAC/
+   I-SID update only in the case of supporting the procedures described
+   in this document.
+
+4.  Solution Description
+
+   Figure 1 will be used in the description of the solution.  CE1, CE2,
+   and CE3 are connected to ACs associated with I-SID1, where no
+   (multihomed) ESs have been enabled, and the ACs and PWs are in active
+   or standby state as per Figure 1.
+
+   Enabling or disabling I-SID-based C-MAC flush SHOULD be an
+   administrative choice on the system that MAY be configured per I-SID
+   (I-Component, Service Instance Component), as opposed to being
+   configured for all I-SIDs.  When enabled on a PE:
+
+   a.  The PE will be able to generate B-MAC/I-SID routes as C-MAC Flush
+       notifications for the remote PEs.
+
+   b.  The PE will be able to process B-MAC/I-SID routes received from
+       remote PEs.
+
+   The PE MUST follow the procedures in [RFC7623] for C-MAC flush.  This
+   specification provides some additional procedures when I-SID-based
+   C-MAC flush is enabled.
+
+   This C-MAC flush specification is described in three sets of
+   procedures:
+
+   *  I-SID-based C-MAC flush activation
+
+   *  C-MAC flush notification generation upon AC failures
+
+   *  C-MAC flush process upon receiving a C-MAC flush notification
+
+4.1.  I-SID-Based C-MAC Flush Activation Procedures
+
+   The following behavior MUST be followed by the PBB-EVPN PEs following
+   this specification.  Figure 1 is used as a reference.
+
+   *  As in [RFC7623], each PE advertises a shared B-MAC in a B-MAC/0
+      route (with B-MAC1, B-MAC2, B-MAC3, and B-MAC4 in the MAC address
+      field, respectively).  This is the B-MAC that each PE will use as
+      B-MAC SA (Source Address) when encapsulating the frames received
+      on any local single-homed AC.  Each PE will import the received
+      B-MAC/0 routes from the remote PEs and will install the B-MACs in
+      its B-component (Backbone Component) MAC-VRF.  For instance, PE1
+      will advertise B-MAC1/0 and will install B-MAC2, B-MAC3, and
+      B-MAC4 in its MAC-VRF.
+
+   *  Assuming I-SID-based C-MAC flush is activated for I-SID1, the PEs
+      will advertise the shared B-MAC with I-SID1 encoded in the
+      Ethernet Tag. That is, PE1 will advertise B-MAC1/1 and will
+      receive B-MAC2/1, B-MAC3/1, and B-MAC4/1.  The receiving PEs MUST
+      use these B-MAC/I-SID routes only for C-MAC flush procedures and
+      they MUST NOT be used to add/withdraw any B-MAC entry in the MAC-
+      VRFs.  As per [RFC7623], only B-MAC/0 routes can be used to add/
+      withdraw B-MACs in the MAC-VRFs.
+
+   *  The above procedure MAY also be used for dedicated B-MACs (B-MACs
+      allocated per ES).
+
+4.2.  C-MAC Flush Generation
+
+   If, for instance, there is a failure on PE1's AC, PE1 will generate
+   an update including B-MAC1/1 along with the MAC Mobility extended
+   community where the Sequence Number has been incremented.  The
+   reception of the B-MAC1/1 with an increment in the sequence number
+   will trigger the C-MAC flush procedures on the receiving PEs.
+
+   *  An AC going operationally down MUST generate a B-MAC/I-SID with a
+      higher Sequence Number.  If the AC going down makes the entire
+      local I-SID go operationally down, the PE will withdraw the B-MAC/
+      I-SID route for the I-SID.
+
+   *  An AC going operationally up SHOULD NOT generate any B-MAC/I-SID
+      update, unless it activates its corresponding I-SID, in which case
+      the PE will advertise the B-MAC/I-SID route.
+
+   *  An AC receiving a G.8032 flush notification or a flush message in
+      any other protocol from the access network MAY propagate it to the
+      remote PEs by generating a B-MAC/I-SID route update with a higher
+      Sequence Number.
+
+4.3.  C-MAC Flush Process upon Receiving a C-MAC Flush Notification
+
+   A PE receiving a C-MAC flush notification will follow these
+   procedures:
+
+   *  A received B-MAC/I-SID route (with a non-zero I-SID) MUST NOT add/
+      remove any B-MAC to/from the MAC-VRF.
+
+   *  An update of a previously received B-MAC/I-SID route with an
+      increment Sequence Number MUST flush all the C-MACs associated
+      with that I-SID and B-MAC.  C-MACs associated with the same I-SID
+      but different B-MAC MUST NOT be flushed.
+
+   *  A received B-MAC/I-SID withdraw (with a non-zero I-SID) MUST flush
+      all the C-MACs associated with that B-MAC and I-SID.
+
+   Note that the C-MAC flush procedures described in [RFC7623] for
+   B-MAC/0 routes are still valid and a PE receiving [RFC7623] C-MAC
+   flush notification messages MUST observe the behavior specified in
+   [RFC7623].
+
+5.  Conclusions
+
+   The I-SID-based C-MAC flush solution described in this document has
+   the following benefits:
+
+   a.  The solution solves packet-loss scenarios in case of failures on
+       null ES ACs, since the C-MAC flush procedures are independent of
+       the ES definition.
+
+   b.  This extension can also be used with Single-Active non-null ESs
+       and virtual ESs, irrespective of the PE B-MAC address assignment
+       (dedicated per-ES B-MAC or shared B-MAC).
+
+   c.  It provides a C-MAC flush notification at B-MAC and I-SID
+       granularity level, therefore flushing a minimum number of C-MACs
+       and reducing the amount of unknown unicast flooding in the
+       network.
+
+   d.  It provides a reliable C-MAC flush notification in PBB-EVPN
+       networks that use RRs.  RRs will propagate the C-MAC flush
+       notifications for all the affected I-SIDs, irrespective of the
+       order in which the notifications make it to the RR.
+
+   e.  The solution can coexist in a network with systems supporting or
+       not supporting this specification.  Non-supporting systems ignore
+       the B-MAC/I-SID routes; however, they still follow the C-MAC
+       flush procedures in [RFC7623].
+
+6.  Security Considerations
+
+   Security considerations described in [RFC7623] apply to this
+   document.
+
+   In addition, this document suggests additional procedures that can be
+   activated on a per I-SID basis and generate additional EVPN MAC/IP
+   Advertisement routes in the network.  The format of these additional
+   EVPN MAC/IP Advertisement routes is backwards compatible with the
+   procedures in [RFC7623] and should not create any issues for
+   receiving PEs that do not follow this specification.  However, the
+   additional routes may consume extra memory and processing resources
+   on the receiving PEs.  Because of that, it is RECOMMENDED to activate
+   this feature only when necessary (when multihomed networks or devices
+   are attached to the PBB-EVPN PEs), and not by default in any PBB-EVPN
+   PE.
+
+7.  IANA Considerations
+
+   This document has no IANA actions.
+
+8.  References
+
+8.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,
+              <https://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, <https://www.rfc-editor.org/info/rfc7432>.
+
+   [RFC7623]  Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
+              Henderickx, "Provider Backbone Bridging Combined with
+              Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
+              September 2015, <https://www.rfc-editor.org/info/rfc7623>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+8.2.  Informative References
+
+   [EVPN-VIRTUAL-ES]
+              Sajassi, A., Brissette, P., Schell, R., Drake, J., and J.
+              Rabadan, "EVPN Virtual Ethernet Segment", Work in
+              Progress, Internet-Draft, draft-ietf-bess-evpn-virtual-
+              eth-segment-15, 28 February 2024,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
+              evpn-virtual-eth-segment-15>.
+
+   [G.8032]   ITU-T, "Ethernet ring protection switching", ITU-T
+              Recommendation G.8032/Y.1344, March 2020,
+              <https://www.itu.int/rec/T-REC-G.8032-202003-I/en>.
+
+   [RFC4762]  Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
+              LAN Service (VPLS) Using Label Distribution Protocol (LDP)
+              Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
+              <https://www.rfc-editor.org/info/rfc4762>.
+
+Acknowledgments
+
+   The authors want to thank Vinod Prabhu, Sriram Venkateswaran, Laxmi
+   Padakanti, and Ranganathan Boovaraghavan for their review and
+   contributions.
+
+Authors' Addresses
+
+   Jorge Rabadan (editor)
+   Nokia
+   520 Almanor Avenue
+   Sunnyvale, CA 94085
+   United States of America
+   Email: jorge.rabadan@nokia.com
+
+
+   Senthil Sathappan
+   Nokia
+   520 Almanor Avenue
+   Sunnyvale, CA 94085
+   United States of America
+   Email: senthil.sathappan@nokia.com
+
+
+   Kiran Nagaraj
+   Nokia
+   520 Almanor Avenue
+   Sunnyvale, CA 94085
+   United States of America
+   Email: kiran.nagaraj@nokia.com
+
+
+   M. Miyake
+   Softbank
+   Email: masahiro.miyake@g.softbank.co.jp
+
+
+   T. Matsuda
+   Softbank
+   Email: taku.matsuda@g.softbank.co.jp