The BGP Enabled ServiceS (bess) WG in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs.
BGP Enabled ServiceS (bess) ----------------------------------------------------------------------- Current status: Active WG Chairs: Matthew Bocci <matthew.bo...@nokia.com> Stephane Litkowski <slitkows.i...@gmail.com> Zhaohui Zhang <zzh...@juniper.net> Secretaries: Mankamana Mishra <manka...@cisco.com> Assigned Area Director: Gunter Van de Velde <gunter.van_de_ve...@nokia.com> Routing Area Directors: Jim Guichard <james.n.guich...@futurewei.com> Gunter Van de Velde <gunter.van_de_ve...@nokia.com> Ketan Talaulikar <ketant.i...@gmail.com> Mailing list: Address: bess@ietf.org 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 (WG) 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 WG. - 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 WG may also suggest new services to be supported by BGP and these may be added to the WG charter subject to rechartering, and they will not be adopted in the WG until such rechartering. The WG will primarily focus on the development of standards track specifications for BGP-based services in its charter. In addition, the WG may produce Informational documents, limited to operational and deployment considerations related to services for which the WG is also developing protocol 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) Informational documents that describe operational practices, deployment considerations, and implementation experiences related to services for which the WG is also developing standard track protocol specifications. i) 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-bgp-multicast-controller and draft-ietf-bess-bgp-multicast). j) 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: Dec 2025 - Submit BGP Usage for SD-WAN Overlay Networks to IESG as Informational Dec 2025 - Submit VPLS multihoming to IESG as PS Dec 2025 - Submit Weighted Multipath for EVPN to IESG as PS Mar 2026 - Submit specifications for BGP components that are applicable to both overlay BESS service and underlay PSN as PS Mar 2026 - Submit update to EVPN base spec (RFC7432bis) to IESG as PS Mar 2026 - Submit E-VPN OAM to IESG as PS Mar 2026 - Submit EVPN multi-homing for L2 gateway protocols to IESG as PS Dec 2026 - Submit EVPN Fast Reroute to IESG as PS Dec 2026 - Submit a Yang device data model for RFC4364 to IESG as PS Dec 2026 - Submit a YANG device data model for L2VPN to IESG as PS Dec 2026 - Submit a YANG device data model for mVPN to IESG as PS Dec 2026 - Submit a Yang device data model for E-VPN to IESG as PS _______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
