Subject: [Idr] Why BESS was chosen as the home for draft-ietf-bess-bgp-multicast-controller

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 5 Nov 2021 12:58:16 +0000

Hi,

draft-ietf-bess-bgp-multicast-controller is mainly about setting up multicast trees (IP/MPLS/SR) in the underlay, though it can also be used to set up overly multicast state in VRFs (e.g. as a replacement for MVPN, as discussed in Section 2 "Alternative to BGP-MVPN").

In last IETF I mentioned that I would email the list explaining why it was put in the BESS WG instead of IDR (since now there is another IDR draft focusing on BGP signaling for SR-P2MP). I realized I never did that. Hope this this email is not *too* late.

There were three factors that led to this.

1. This controller based signaling was derived from hop-by-hop signaling (draft-ietf-bess-bgp-multicast). That one in turn is based on concepts from BGP-MVPN (RFC6514), which was done in BESS. We thought naturally draft-ietf-bess-bgp-multicast belonged to BESS, so we continued the controller work in BESS.

2. Because of all the MVPN and VPLS/EVPN-BUM work in BESS, BESS probably has more folks familiar with multicast.

3. I had assumed that BESS, as BGP Enabled ServiceS, covered all (not just VPN related) services, while IDR mainly covered BGP "infrastructure". I now understand that is not entirely correct, though BESS charter does say "The working group may also suggest new services to be supported by BGP and these may be added to the working group charter subject to rechartering".

Thanks.
Jeffrey

Juniper Business Use Only