EVPN BUM Using BIER
draft-ietf-bier-evpn-14

Network Working Group                                 Y. Rekhter, Editor
Request for Comments: 1266        T.J. Watson Research Center, IBM Corp.
                                                            October 1991

                    Experience with the BGP Protocol

1. Status of this Memo.

   This memo provides information for the Internet community.  It does
   not specify an Internet standard. Distribution of this memo is
   unlimited.

2. Introduction.

   The purpose of this memo is to document how the requirements for
   advancing a routing protocol to Draft Standard have been satisfied by
   Border Gateway Protocol (BGP). This report documents experience with
   BGP.  This is the second of two reports on the BGP protocol.  As
   required by the Internet Activities Board (IAB) and the Internet
   Engineering Steering Group (IESG), the first report will present a
   performance analysis of the BGP protocol.

   The remaining sections of this memo document how BGP satisfies
   General Requirements specified in Section 3.0, as well as
   Requirements for Draft Standard specified in Section 5.0 of the
   "Internet Routing Protocol Standardization Criteria" document [1].

   This report is based on the work of Dennis Ferguson (University of
   Toronto), Susan Hares (MERIT/NSFNET), and Jessica Yu (MERIT/NSFNET).
   Details of their work were presented at the Twentieth IETF meeting
   (March 11-15, 1991, St. Louis) and are available from the IETF
   Proceedings.

   Please send comments to iwg@rice.edu.

3. Acknowledgements.

   The BGP protocol has been developed by the IWG/BGP Working Group of
   the Internet Engineering Task Force. We would like to express our
   deepest thanks to Guy Almes (Rice University) who was the previous
   chairman of the IWG Working Group.  We also like to explicitly thank
   Bob Hinden (BBN) for the review of this document as well as his
   constructive and valuable comments.

BGP Working Group                                               [Page 1]
RFC 1266            Experience with the BGP Protocol        October 1991

4. Documentation.

   BGP is an inter-autonomous system routing protocol designed for the
   TCP/IP internets.  Version 1 of the BGP protocol was published in RFC
   1105. Since then BGP Versions 2 and 3 have been developed. Version 2
   was documented in RFC 1163. Version 3 is documented in [3]. The
   changes between versions 1, 2 and 3 are explained in Appendix 3 of
   [3].  Most of the functionality that was present in the Version 1 is
   present in the Version 2 and 3.  Changes between Version 1 and
   Version 2 affect mostly the format of the BGP messages.  Changes
   between Version 2 and Version 3 are quite minor.

   BGP Version 2 removed from the protocol the concept of "up", "down",
   and "horizontal" relations between autonomous systems that were
   present in the Version 1.  BGP Version 2 introduced the concept of
   path attributes.  In addition, BGP Version 2 clarified parts of the
   protocol that were "underspecified".  BGP Version 3 lifted some of
   the restrictions on the use of the NEXT_HOP path attribute, and added
   the BGP Identifier field to the BGP OPEN message. It also clarifies
   the procedure for distributing BGP routes between the BGP speakers
   within an autonomous system.  Possible applications of BGP in the
   Internet are documented in [2].

   The BGP protocol was developed by the IWG/BGP Working Group of the
   Internet Engineering Task Force. This Working Group has a mailing
   list, iwg@rice.edu, where discussions of protocol features and
   operation are held. The IWG/BGP Working Group meets regularly during
   the quarterly Internet Engineering Task Force conferences. Reports of
   these meetings are published in the IETF's Proceedings.

5. MIB

   A BGP Management Information Base has been published [4].  The MIB
   was written by Steve Willis (swillis@wellfleet.com) and John Burruss
   (jburruss@wellfleet.com).

   Apart from a few system variables, the BGP MIB is broken into two
   tables: the BGP Peer Table and the BGP Received Path Attribute Table.
   The Peer Table reflects information about BGP peer connections, such
   as their state and current activity. The Received Path Attribute
   Table contains all attributes received from all peers before local
   routing policy has been applied. The actual attributes used in
   determining a route are a subset of the received attribute table.

   The BGP MIB is quite small. It contains total of 27 objects.

BGP Working Group                                               [Page 2]
RFC 1266            Experience with the BGP Protocol        October 1991

6. Security architecture.

   BGP provides flexible and extendible mechanism for authentication and
   security. The mechanism allows to support schemes with various degree
   of complexity. All BGP sessions are authenticated based on the BGP
   Identifier of a peer. In addition, all BGP sessions are authenticated
   based on the autonomous system number advertised by a peer. As part
   of the BGP authentication mechanism, the protocol allows to carry
   encrypted digital signature in every BGP message. All authentication
   failures result in sending the NOTIFICATION messages and immediate
   termination of the BGP connection.

   Since BGP runs over TCP and IP, BGP's authentication scheme may be
   augmented by any authentication or security mechanism provided by
   either TCP or IP.

7. Implementations.

   There are multiple interoperable implementations of BGP currently
   available. This section gives a brief overview of the three
   completely independent implementations that are currently used in the
   operational Internet. They are:

      - cisco. This implementation was wholly developed by cisco.
        It runs on the proprietary operating system used by the
        cisco routers. Consult Kirk Lougheed (lougheed@cisco.com)
        for more details.

      - "gated". This implementation was developed wholly by Jeff
        Honig (jch@risci.cit.cornell.edu) and Dennis Ferguson
        (dennis@CAnet.CA).  It runs on a variety of operating systems
        (4.3 BSD, AIX, etc...).  It is the only available public domain
        code for BGP. Consult Jeff Honig or Dennis Ferguson for more
        details.

      - NSFNET. This implementation was developed wholly by Yakov
        Rekhter (yakov@watson.ibm.com). It runs on the T1 NSFNET
        Backbone and T3 NSFNET Backbone. Consult Yakov Rekhter for
        more details.

   To facilitate efficient BGP implementations, and avoid commonly made
   mistakes, the implementation experience with BGP in "gated" was
   documented as part of RFC 1164.  Implementors are strongly encouraged
   to follow the implementation suggestions outlined in that document.

   Experience with implementing BGP showed that the protocol is
   relatively simple to implement. On the average BGP implementation
   takes about 1 man/month effort.

BGP Working Group                                               [Page 3]
RFC 1266            Experience with the BGP Protocol        October 1991Zhang, et al.              Expires 5 July 2024                  [Page 9]
Internet-Draft                  bier-evpn                   January 2024

       Note that in both cases, SMET routes may be used in lieu of Leaf
       A-D routes, as a PE may omit the Leaf A-D route in response to an
       S-PMSI A-D route with LIR or LIR-pF bit set, if an SMET route
       with the corresponding Tag, Source, and Group fields is already
       originated [I-D.ietf-bess-evpn-bum-procedure-updates].  In
       particular, in the second case above, even though the SMET route
       does not have a PTA attached, it is still considered a Leaf A-D
       route in response to a wildcard S-PMSI A-D route with the LIR-pF
       bit set.

   4.  Otherwise, the route matched for transmission and leaf tracking
       routes are determined as in rule 1.

   If no route is matched for transmission, the packet is not forwarded
   onto a P-tunnel.  If the tunnel that the ingress determines to use
   based on the route matched for transmission (and considering
   interworking with PEs that do not support certain tunnel types per
   procedures in [RFC9251]) requires leaf tracking (e.g.  Ingress
   Replication, RSVP-TE P2MP tunnel, or BIER) but there are no leaf
   tracking routes, the packet will not be forwarded onto a P-tunnel
   either.

   The following text assumes that BIER is the determined tunnel type.
   The ingress PE pushes an upstream-assigned ESI label per [RFC7432] if
   the following conditions are all met:

   *  The packet is received on a multihomed ES.

   *  It's EVPN-MPLS.

   *  ESI label procedure is used for split-horizon.

   The MPLS label from the PTA of the route matched for transmission is
   then pushed onto the packet's label stack for EVPN-MPLS.  For EVPN-
   VXLAN/NVGRE/GENEVE, a VXLAN/NVGRE/GENEVE header is prepended to the
   packet with the VNI/VSID set to the value in the PTA's label field,
   and then an IP/UDP header is prepended if needed (e.g. for PHP
   purpose).

   Then the packet is encapsulated in a BIER header and forwarded,
   according to the procedures of [RFC8279] and [RFC8296].  See
   especially Section 4, "Imposing and Processing the BIER
   Encapsulation", of [RFC8296].  The "Proto" field in the BIER header
   is set to 2 in the case of EVPN-MPLS, or a value to be assigned in
   the case of EVPN-VXLAN/NVGRE/GENEVE (Section 5) when an IP header is
   not used, or 4/6 if an IP header is used for EVPN-VXLAN/NVGRE/GENEVE.

Zhang, et al.              Expires 5 July 2024                 [Page 10]
Internet-Draft                  bier-evpn                   January 2024

   To create the proper BIER header for a given packet, the BFIR must
   know all the BFERs that need to receive that packet.  This is
   determined from the set of leaf tracking routes.

4.1.2.  At a BFIR that is a P-tunnel Segmentation Point

   In this case, the encapsulation for the upstream segment of the
   P-tunnel includes (among other things) a label that identifies the
   x-PMSI or IMET A-D route that is the match for reception on the
   upstream segment.  The segmentation point re-advertised the route
   into one or more downstream regions.  Each instance of the re-
   advertised route for a downstream region has a PTA that specifies the
   tunnel for that region.  For any particular downstream region, the
   route matched for transmission is the re-advertised route and the
   leaf tracking routes are determined as follows if needed for the
   tunnel type:

   *  If the route matched for transmission is an x-PMSI route, it must
      have the LIR flag set in its PTA and the leaf tracking routes are
      all the matching Leaf A-D and SMET routes received in the
      downstream region.

   *  If the route matched for transmission is an IMET route, the leaf
      tracking routes are all the IMET routes for the same BD received
      in the downstream region.

   If the downstream region uses BIER, the packet is forwarded as
   follows: the upstream segmentation's encapsulation is removed and the
   above-mentioned label is swapped to the upstream-assigned label in
   the PTA of the route matched for transmission, and then a BIER header
   is imposed as in Section 4.1.1.

4.2.  Disposition

   The same procedures in section 4.2 of [RFC8556] are followed for
   EVPN-MPLS, except some EVPN specifics discussed in the following two
   sub-sections in this document.

   For EVPN-VXLAN/NVGRE/GENEVE, the only difference is that the payload
   is VXLAN/NVGRE/GENEVE (with or without an IP header) and the VNI/VSID
   field in the VXLAN/NVGRE/GENEVE header is used to determine the
   corresponding broadcast domain.

Zhang, et al.              Expires 5 July 2024                 [Page 11]
Internet-Draft                  bier-evpn                   January 2024

4.2.1.  At a BFER that is an Egress PE

   Once the corresponding broadcast domain is determined from the
   upstream-assigned label or VNI/VSID, EVPN forwarding procedures per
   [RFC7432] or [RFC8365] are followed.  In the case of EVPN-MPLS, if
   there is an inner label in the label stack following the BIER header,
   that inner label is considered the upstream-assigned ESI label for
   split horizon purpose.

4.2.2.  At a BFER that is a P-tunnel Segmentation Point

   This is only applicable to EVPN-MPLS.  The same procedures in
   Section 4.2.2 of [RFC8556] are followed, subject to multihoming
   procedures specified in [I-D.ietf-bess-evpn-bum-procedure-updates].

5.  IANA Considerations

   This document requests three assignments in "BIER Next Protocol
   Identifiers" registry, with the following three recommended values:

   *  7: Payload is VXLAN encapsulated (no IP/UDP header)

   *  8: Payload is NVGRE encapsulated (no IP header)

   *  9: Payload is GENEVE encapsulated (no IP/UDP header)

   This document requests assignments of an IPv4 and an IPv6 multicast
   address for the case discussed in Section 2.1.  Preferably this is
   assigned from the Local Network Control Block (224.0.0/24) for IPv4
   and Link-Local Scope Multicast Addresses for IPv6.  The description
   is "NVO BUM Traffic".

6.  Security Considerations

   This document is about using BIER as provider tunnels for EVPN.  It
   is very similar to using BIER as MVPN provider tunnel, and does not
   introduce additional security implications beyond what have been
   discussed in EVPN base protocol specification [RFC7432] and MVPN
   using BIER [RFC8556].

7.  Acknowledgements

   The authors thank Eric Rosen for his review and suggestions.
   Additionally, much of the text is borrowed verbatim from [RFC8556].

8.  References

8.1.  Normative References

Zhang, et al.              Expires 5 July 2024                 [Page 12]
Internet-Draft                  bier-evpn                   January 2024

   [I-D.ietf-bess-evpn-bum-procedure-updates]
              Zhang, Z. J., Lin, W., Rabadan, J., Patel, K., and A.
              Sajassi, "Updates on EVPN BUM Procedures", Work in
              Progress, Internet-Draft, draft-ietf-bess-evpn-bum-
              procedure-updates-14, 18 November 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              evpn-bum-procedure-updates-14>.

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

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

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

   [RFC6625]  Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
              Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
              RFC 6625, DOI 10.17487/RFC6625, May 2012,
              <https://www.rfc-editor.org/info/rfc6625>.

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

   [RFC7900]  Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y.,
              and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs",
              RFC 7900, DOI 10.17487/RFC7900, June 2016,
              <https://www.rfc-editor.org/info/rfc7900>.

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

   [RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
              Explicit Replication (BIER)", RFC 8279,
              DOI 10.17487/RFC8279, November 2017,
              <https://www.rfc-editor.org/info/rfc8279>.

Zhang, et al.              Expires 5 July 2024                 [Page 13]
Internet-Draft                  bier-evpn                   January 2024

   [RFC8296]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
              for Bit Index Explicit Replication (BIER) in MPLS and Non-
              MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
              2018, <https://www.rfc-editor.org/info/rfc8296>.

   [RFC8365]  Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
              Uttaro, J., and W. Henderickx, "A Network Virtualization
              Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
              DOI 10.17487/RFC8365, March 2018,
              <https://www.rfc-editor.org/info/rfc8365>.

   [RFC8534]  Dolganow, A., Kotalwar, J., Rosen, E., Ed., and Z. Zhang,
              "Explicit Tracking with Wildcard Routes in Multicast VPN",
              RFC 8534, DOI 10.17487/RFC8534, February 2019,
              <https://www.rfc-editor.org/info/rfc8534>.

   [RFC8556]  Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S.,
              and A. Dolganow, "Multicast VPN Using Bit Index Explicit
              Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
              2019, <https://www.rfc-editor.org/info/rfc8556>.

   [RFC8926]  Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
              "Geneve: Generic Network Virtualization Encapsulation",
              RFC 8926, DOI 10.17487/RFC8926, November 2020,
              <https://www.rfc-editor.org/info/rfc8926>.

   [RFC9251]  Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J.,
              and W. Lin, "Internet Group Management Protocol (IGMP) and
              Multicast Listener Discovery (MLD) Proxies for Ethernet
              VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022,
              <https://www.rfc-editor.org/info/rfc9251>.

8.2.  Informative References

   [I-D.ietf-bier-php]
              Zhang, Z. J., "BIER Penultimate Hop Popping", Work in
              Progress, Internet-Draft, draft-ietf-bier-php-10, 9 March
              2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
              bier-php-10>.

   [I-D.zzhang-bess-mvpn-evpn-cmcast-enhancements]
              Zhang, Z. J., Kebler, R., Lin, W., and E. C. Rosen, "MVPN/
              EVPN C-Multicast Routes Enhancements", Work in Progress,
              Internet-Draft, draft-zzhang-bess-mvpn-evpn-cmcast-
              enhancements-03, 1 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-zzhang-bess-
              mvpn-evpn-cmcast-enhancements-03>.

Zhang, et al.              Expires 5 July 2024                 [Page 14]
Internet-Draft                  bier-evpn                   January 2024

   [RFC4875]  Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
              Yasukawa, Ed., "Extensions to Resource Reservation
              Protocol - Traffic Engineering (RSVP-TE) for Point-to-
              Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
              DOI 10.17487/RFC4875, May 2007,
              <https://www.rfc-editor.org/info/rfc4875>.

   [RFC6388]  Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
              Thomas, "Label Distribution Protocol Extensions for Point-
              to-Multipoint and Multipoint-to-Multipoint Label Switched
              Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
              <https://www.rfc-editor.org/info/rfc6388>.

   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
              L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
              eXtensible Local Area Network (VXLAN): A Framework for
              Overlaying Virtualized Layer 2 Networks over Layer 3
              Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
              <https://www.rfc-editor.org/info/rfc7348>.

   [RFC7637]  Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
              Virtualization Using Generic Routing Encapsulation",
              RFC 7637, DOI 10.17487/RFC7637, September 2015,
              <https://www.rfc-editor.org/info/rfc7637>.

Authors' Addresses

   Zhaohui Zhang
   Juniper Networks
   Email: zzhang@juniper.net

   Antoni Przygienda
   Juniper Networks
   Email: prz@juniper.net

   Ali Sajassi
   Cisco Systems
   Email: sajassi@cisco.com

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

Zhang, et al.              Expires 5 July 2024                 [Page 15]