The BGP Enabled ServiceS (bess) WG in the Routing Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list ([email protected]) by 2025-07-06.
BGP Enabled ServiceS (bess) ----------------------------------------------------------------------- Current status: Active WG Chairs: Matthew Bocci <[email protected]> Stephane Litkowski <[email protected]> Zhaohui Zhang <[email protected]> Secretaries: Mankamana Mishra <[email protected]> Assigned Area Director: Gunter Van de Velde <[email protected]> Routing Area Directors: Jim Guichard <[email protected]> Gunter Van de Velde <[email protected]> Ketan Talaulikar <[email protected]> Mailing list: Address: [email protected] To subscribe: https://www.ietf.org/mailman/listinfo/bess Archive: https://mailarchive.ietf.org/arch/browse/bess/ Group page: https://datatracker.ietf.org/group/bess/ Charter: https://datatracker.ietf.org/doc/charter-ietf-bess/ 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 VPN services over a packet switched network (PSN) where the VPN signaling uses BGP. The following services are in-scope: - BGP-enabled IP VPN solutions (based on RFC4364, RFC4659, RFC6513, RFC6514 and RFC9252) for supporting unicast and multicast provider-provisioned L3VPNs. - BGP-enabled L2VPNs (based on RFC4664, RFC7432 and 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 any of these purposes are out of scope of the BESS working group. - 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 specifications for services in its charter. The WG will work on informational documents only 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: a) BGP signaling related to the discovery of service endpoints and their capabilities that are related to the service. b) The exchange of service routes and their provisioning. c) Scaling and convergence improvements. d) Interworking between different services. e) Definition of YANG data models for device provisioning and operations. f) Redundancy, multi-homing, load-balancing, and similar resiliency mechanisms. g) OAM mechanisms related to services within the scope of the WG, following coordination with the WGs responsible for the underlying data plane technologies. h) BGP signaling related to multicast services. This includes BGP components that are also applicable to the underlay PSN and that are detailed in specifications already adopted at the time of this charter revision (i.e. draft-ietf-bess-evpn-mvpn-seamless-interop, draft-ietf-bess-bgp-multicast-controller and draft-ietf-bess-mvpn-evpn-sr-p2mp). i) Specifications for BGP-enabled VPN solutions for SD-WAN environments that are already adopted at the time of this charter revision (i.e. draft-ietf-bess-bgp-sdwan-usage). The WG will not define new data plane or forwarding encapsulations. Instead, it will rely on existing encapsulation mechanisms. These include, but are not limited to, IP-based encapsulations (such as IP-in-IP, VXLAN, GENEVE, and SRv6) and MPLS. The WG is expected to coordinate closely with the IDR WG. Any extensions that impact core BGP protocol behavior, including modifications to the BGP finite state machine, message formats, best-path selection procedures, or the definition of new path attributes, must be cross-posted to the IDR WG for review. While technical discussions may occur on the BESS WG mailing list, work affecting the base BGP protocol remains subject to coordination with the IDR WG. The WG will also liaise with other relevant WGs, including but not limited to MPLS, SPRING, 6MAN, NVO3, MBONED, and BFD, as appropriate. This coordination aims to ensure architectural consistency, alignment of data plane considerations, and interoperability of OAM procedures for BGP-based VPN solutions. Milestones: TBD _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
