WG, As we discussed at the last IETF, the chairs and routing ADs have been working on updating the BESS charter.
Much of the existing charter text dates from the time the WG was formed out of L2VPN and L3VPN working groups. It does not clearly reflect the current work items that are in-scope for the WG and is a little vague on the boundaries with other working groups, particularly IDR. The proposed updated charter, included below, is intended to bring this up to date and to mor clearly define which services and technologies are in-charter, and thus to provide clearer guidance on what work items lie within the scope of BESS. The intent is also to provide clearer guidance on where BGP work should be done. Please review the new text below and provide any comments to the BESS WG list by Friday 30th May 2025. Thanks, Matthew, Jeffrey, and Stephane === BGP is established as a protocol for provisioning and operating Layer-3 (routed) Virtual Private Networks (L3VPNs) and Layer-2 Virtual Private Networks (L2VPNs). The BGP Enabled Services (BESS) working group is responsible for defining, specifying, and extending network services over a packet switched network (PSN) where the VPN signaling uses BGP. In particular, the working group will work on the following services: * BGP-enabled IP VPN solutions (based on RFC4364<https://datatracker.ietf.org/doc/rfc4364/>, RFC4659<https://datatracker.ietf.org/doc/rfc4659/>, RFC6513, RFC6514 and RFC9252<https://datatracker.ietf.org/doc/rfc9252/>) for supporting unicast and multicast provider-provisioned L3VPNs. * BGP-enabled L2VPNs (based on RFC 4664<https://datatracker.ietf.org/doc/rfc4664/>, RFC7432<https://www.rfc-editor.org/rfc/rfc7432.html> and RFC9252<https://datatracker.ietf.org/doc/rfc9252/>). Only types of L2VPN that utilize BGP for discovery, signaling, or for some other purposes related to the VPN are in scope. L2VPN solutions that do not utilize BGP for signaling are out of scope of the BESS working group. Any contention in placement of the work will be resolved by the chairs and responsible Area Directors. * BGP-enabled VPN solutions for use in data center networking. This work includes consideration of VPN scaling issues and mechanisms applicable to such environments. * Extensions to BGP-enabled VPN solutions to enable interworking between BGP L3VPNs and BGP L2VPNs. 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, and they will not be adopted in the working group until such rechartering. The WG will focus primarily on producing BGP protocol specifications for services in its charter. The WG will work on informational documents only where they are related to operational and deployment aspects of the services for which the WG is also producing the protocols specifications. As part of enhancing and maintaining the services that the WG has specified, the following is a list of specific aspects that the WG is expected to work on: 1. BGP signaling related to the discovery of service endpoints and their capabilities that are related to the service. 2. The exchange of service routes and their provisioning. 3. Scaling and convergence improvements. 4. Interworking between different services. 5. Definition of YANG models for provisioning and operations. 6. Redundancy, multi-homing, load-balancing, and similar resiliency mechanisms. 7. BGP signaling related to multicast services. This includes BGP components that are also applicable to the underlay PSN and are already adopted at the time of this charter revision. The WG will not define new data plane or forwarding plane encapsulations and instead leverage existing ones such as IP (e.g., IP-in-IP, VXLAN, GENEVE, SRv6) and MPLS. OAM mechanisms related to services that are in the WG’s scope may be taken up after coordination with the WGs responsible for the relevant data planes. The WG is expected to collaborate closely with the IDR WG. Any extensions that are related to core BGP protocol such as changes to the BGP finite state machine, messaging, best-path calculation, or allocation of new attributes would need to be cross-posted to the IDR WG for review while the actual discussions may happen on the BESS WG mailing list. The WG is also expected to collaborate with other WGs such as MPLS and SPRING for specific work items, as appropriate.
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
