Potentially inspiration can be found from recent successful WG recharterings (i.e. SPRING and BIER)
A text that was used in the recent BIER rechartering: https://datatracker.ietf.org/wg/bier/about/ “ Additionally, the WG will coordinate with related working groups, including MPLS, LSR, BABEL, BESS, IDR, PIM, MBONED, PCE, and TEAS, to ensure alignment and interoperability in areas such as OAM, routing extensions, multicast membership management, and architecture for BIER-TE forwarding. These collaborations will support the advancement of BIER as a scalable and efficient solution for multicast forwarding. ” The spring WG has when recently rechartered the following construct: https://datatracker.ietf.org/wg/spring/about/ “ The SPRING WG will coordinate and collaborate with other WGs as needed. Specific expected interactions include (but may not be limited to): * mpls on the MPLS dataplane and OAM extensions, * 6man on the IPv6 dataplane for SR and associated OAM extensions * lsr on OSPF and IS-IS extensions to flood SPRING-related information * idr for BGP extensions * bess for VPN control plane * pce on extensions to communicate with an external entity to compute and program SPRING paths * teas on generic traffic engineering architecture * sfc on service chaining applications * rtgwg on fast-reroute technologies “ G/ From: Matthew Bocci (Nokia) <matthew.bo...@nokia.com> Sent: Wednesday, May 21, 2025 1:27 PM To: slitkows.i...@gmail.com; 'Greg Mirsky' <gregimir...@gmail.com> Cc: bess@ietf.org; 'idr-chairs' <idr-cha...@ietf.org>; rtg-...@ietf.org Subject: Re: [bess] Re: WG Last Call for Proposed Revision to BESS WG Charter Maybe it would help to rephrase this sentence to emphasise that this is just a few examples: The WG is also expected to collaborate with other WGs on specific work items as appropriate, for example MPLS and SPRING. Matthew From: slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com> <slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>> Date: Wednesday, 21 May 2025 at 08:48 To: 'Greg Mirsky' <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, Matthew Bocci (Nokia) <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, '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: [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 Greg, This list is not limiting but just highlighting the most common one. From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> Sent: Wednesday, May 21, 2025 12:59 AM To: Matthew Bocci (Nokia) <matthew.bocci=40nokia....@dmarc.ietf.org<mailto:matthew.bocci=40nokia....@dmarc.ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org>; idr-chairs <idr-cha...@ietf.org<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 Hi, Matthew et al., I have a question about the last sentence in the revised charter: The WG is also expected to collaborate with other WGs such as MPLS and SPRING for specific work items, as appropriate. Since IP is one of the data planes enabling BGP-controlled VPNs, would it be helpful to add 6man WG to the list? (Of course, the list is not exhaustive , and 6man might already be there implicitly.) Regards, Greg On Mon, May 12, 2025 at 1:41 AM Matthew Bocci (Nokia) <matthew.bocci=40nokia....@dmarc.ietf.org<mailto:40nokia....@dmarc.ietf.org>> wrote: 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<mailto:bess@ietf.org> To unsubscribe send an email to bess-le...@ietf.org<mailto:bess-le...@ietf.org>
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
