Hi all, I wanted to provide a quick heads-up regarding the ongoing rechartering effort for the BESS working group. The current BESS charter is outdated, it still references groups like PALS, which has since concluded, and contains some ambiguous language that has led to confusion about the group’s intended scope. This has unfortunately resulted in some scope creep, including the adoption of drafts that fall outside what BESS was originally set up to do. A good example is the concept of SD-WAN, which wasn’t on the radar when BESS was formed. This ambiguity has caused issues, as seen in the earlier IESG ballot discussion: https://mailarchive.ietf.org/arch/msg/bess/RdI2h98N8IJC_7mR5j8pPnq7Iuk/ To prevent similar procedural hiccups, one goal of the updated charter is to clarify scope explicitly and, for instance, ensure that drafts like draft-ietf-bess-bgp-sdwan-usage are recognized as in-scope, effectively “grandfathering” them in so they can proceed without being blocked by procedural concerns. To get the rechartering moving, I asked the BESS chairs to draft an updated charter with clearer descriptions of the WG's responsibilities, grounded in its original purpose, the expertise of the participants, and the ongoing need for technology maintenance. This effort is not intended to expand the WG’s scope or to introduce new work items at this time. Of course, if there's later consensus within the WG to expand its scope to cover new topics, and there's sufficient expertise to do so, that can be revisited after this charter update concludes. As for SD-WAN itself: it’s a software-driven architecture for routing and managing WAN traffic, often across multiple transport types like broadband, LTE, and MPLS. It dynamically steers traffic based on real-time conditions and centralized policies, enabling better application performance, agility, and cost control. However, this type of architecture is fundamentally broader than what BESS has traditionally focused on, namely BGP, L2VPN, L3VPN using MPLS, and SRv6-based service delivery. SD-WAN typically involves proprietary components, IPR-heavy implementations, and architectural constructs beyond the scope and expertise of BESS. In my view, BESS isn’t the right venue to standardize or debate SD-WAN as a whole. If there’s interest in pursuing standardization in this space, a more appropriate path would be to first develop a framework, problem statement, and solution space analysis, and then evaluate whether a dedicated WG should be proposed. Thanks, Gunter Van de Velde, Routing AD
From: Chongfeng Xie <chongfeng....@foxmail.com> Sent: Tuesday, May 20, 2025 5:39 AM To: Linda Dunbar <linda.dun...@futurewei.com>; Matthew Bocci (Nokia) <matthew.bo...@nokia.com>; bess <bess@ietf.org> Cc: idr-chairs <idr-cha...@ietf.org>; rtg-ads <rtg-...@ietf.org> Subject: Re: [bess] Re: WG Last Call for Proposed Revision to BESS WG Charter CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi all, I support Linda's request of adding BGP-enabled SD-WAN services to the BESS new charter, so as to better meet the needs SD-WAN development in the future. Best regards Chongfeng From: Linda Dunbar<mailto:linda.dun...@futurewei.com> Date: 2025-05-20 00:36 To: Matthew Bocci (Nokia)<mailto:matthew.bo...@nokia.com>; bess@ietf.org<mailto:bess@ietf.org> CC: idr-chairs<mailto:idr-cha...@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org> Subject: [bess] Re: WG Last Call for Proposed Revision to BESS WG Charter Matthew, Simply stating that BGP-controlled L2VPN and L3VPN services are in scope is not sufficient to cover SD-WAN services. SD-WAN architectures are designed to operate over heterogeneous underlays—including L2VPN, L3VPN, and plain IP networks—and BGP is used not just for reachability, but for endpoint classification, policy signaling, and service segmentation. To reflect this broader applicability and ensure that SD-WAN-specific use cases are clearly in scope, we propose adding the following bullet to the charter: • BGP-enabled SD-WAN services that operate over heterogeneous underlays, including L2VPN, L3VPN, and plain IP networks. This includes signaling mechanisms for endpoint classification, policy distribution, and service segmentation. This addition clarifies the scope and supports ongoing work such as https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/ Thank you, Linda From: Matthew Bocci (Nokia) <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>> Sent: Monday, May 19, 2025 7:08 AM To: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>>; bess@ietf.org<mailto:bess@ietf.org> Cc: idr-chairs <idr-cha...@ietf.org<mailto:idr-cha...@ietf.org>>; rtg-...@ietf.org<mailto:rtg-...@ietf.org> Subject: Re: WG Last Call for Proposed Revision to BESS WG Charter Hi Linda If there are specific BGP protocol extensions that are needed for L3 or L2 VPNs to work in an SDWAN environment, then wouldn’t these be covered by the first two bullets in the proposed charter already? Regarding your draft, I agree that the WG has already agreed to it so perhaps a special inclusion statement (similar to the one we have in bullet (g)) would cover completing the draft. Best regards Matthew From: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> Date: Friday, 16 May 2025 at 01:22 To: Matthew Bocci (Nokia) <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Cc: idr-chairs <idr-cha...@ietf.org<mailto:idr-cha...@ietf.org>>, rtg-...@ietf.org<mailto:rtg-...@ietf.org> <rtg-...@ietf.org<mailto:rtg-...@ietf.org>> Subject: RE: WG Last Call for Proposed Revision to BESS WG Charter CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. BESS Chairs and Participants: BGP-enabled VPN solutions for SD-WAN environments should be included in the BESS charter because they extend existing BGP VPN mechanisms to support policy-driven, application-aware traffic steering across diverse underlay networks. As outlined https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/, BGP has proven to be an effective and scalable control plane protocol for SD-WAN networks—facilitating the discovery of endpoints, signaling of service attributes, and enforcement of segmentation and routing policies. These capabilities align closely with BESS's mission to define and extend BGP-based network services. SD-WAN is now a widely deployed service across enterprise and service provider networks. Yet, there is currently no IETF working group specifically addressing how BGP is used as the control plane for SD-WAN. Including this work within the BESS charter would ensure these extensions are standardized in the appropriate context and informed by operational deployment experience. BGP extensions to support SD-WAN services has already been adopted (e.g., draft-ietf-bess-bgp-sdwan-usage) and should be considered within BESS scope. Suggested changes to the charter: Add a new bullet under the BESS-supported services: · BGP-enabled VPN solutions for SD-WAN environments, including mechanisms for discovery, policy signaling, and service differentiation across underlay networks. Changing the bullet a) under “As part of enhancing and maintaining…” to the following: a. BGP signaling related to the discovery of service endpoints and their capabilities that are related to the service, including endpoint classification and policy signaling in SD-WAN deployments. Thank you , Linda Dunbar From: Matthew Bocci (Nokia) <matthew.bocci=40nokia....@dmarc.ietf.org<mailto:matthew.bocci=40nokia....@dmarc.ietf.org>> Sent: Monday, May 12, 2025 1:41 AM To: bess@ietf.org<mailto:bess@ietf.org> Cc: idr-chairs <idr-cha...@ietf.org<mailto:idr-cha...@ietf.org>>; rtg-...@ietf.org<mailto:rtg-...@ietf.org> Subject: [bess] WG Last Call for Proposed Revision to BESS WG Charter 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
