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 Date: 2025-05-20 00:36 To: Matthew Bocci (Nokia); bess@ietf.org CC: idr-chairs; 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> Sent: Monday, May 19, 2025 7:08 AM To: Linda Dunbar <linda.dun...@futurewei.com>; bess@ietf.org Cc: idr-chairs <idr-cha...@ietf.org>; 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> Date: Friday, 16 May 2025 at 01:22 To: Matthew Bocci (Nokia) <matthew.bo...@nokia.com>, bess@ietf.org <bess@ietf.org> Cc: idr-chairs <idr-cha...@ietf.org>, rtg-...@ietf.org <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> Sent: Monday, May 12, 2025 1:41 AM To: bess@ietf.org Cc: idr-chairs <idr-cha...@ietf.org>; 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, RFC4659, RFC6513, RFC6514 and RFC9252) for supporting unicast and multicast provider-provisioned L3VPNs. BGP-enabled L2VPNs (based on RFC 4664, 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 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: BGP signaling related to the discovery of service endpoints and their capabilities that are related to the service. The exchange of service routes and their provisioning. Scaling and convergence improvements. Interworking between different services. Definition of YANG models for provisioning and operations. Redundancy, multi-homing, load-balancing, and similar resiliency mechanisms. 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
