[bess] Re: WG Last Call for Proposed Revision to BESS WG Charter

[Matthew Bocci (Nokia)]

Thanks for the feedback.

How about the following?:

“The WG is also expected to coordinate with related WGs on specific work items 
as appropriate, for example MPLS, SPRING, 6man, NVO3 and BFD to ensure 
alignment and interoperability in areas such as the data plane, OAM and 
architecture for BGP VPNs. “

I added BFD since we have a current work item on EVPN BFD, and I added NVO3 
because of the use/signaling for GENEVE and the use of VXLAN. Routing 
extensions are already covered by the sentence on working with IDR.

Best regards

Matthew

From: Gunter van de Velde (Nokia) 
Date: Wednesday, 21 May 2025 at 12:34
To: Matthew Bocci (Nokia) , slitkows.i...@gmail.com 
, 'Greg Mirsky' 
Cc: bess@ietf.org , 'idr-chairs' , 
rtg-...@ietf.org 
Subject: RE: [bess] Re: WG Last Call for Proposed Revision to BESS WG Charter
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) 
Sent: Wednesday, May 21, 2025 1:27 PM
To: slitkows.i...@gmail.com; 'Greg Mirsky' 
Cc: bess@ietf.org; 'idr-chairs' ; 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> 
mailto:slitkows.i...@gmail.com>>
Date: Wednesday, 21 May 2025 at 08:48
To: 'Greg Mirsky' mailto:gregimir...@gmail.com>>, 
Matthew Bocci (Nokia) mailto:matthew.bo...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
'idr-chairs' mailto:idr-cha...@ietf.org>>, 
rtg-...@ietf.org<mailto: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 mailto:gregimir...@gmail.com>>
Sent: Wednesday, May 21, 2025 12:59 AM
To: Matthew Bocci (Nokia) 
mailto:matthew.bocci=40nokia@dmarc.ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; 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

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) 
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

[bess] Re: WG Last Call for Proposed Revision to BESS WG Charter

[Gunter van de Velde (Nokia)]

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) 
Sent: Wednesday, May 21, 2025 1:27 PM
To: slitkows.i...@gmail.com; 'Greg Mirsky' 
Cc: bess@ietf.org; 'idr-chairs' ; 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> 
mailto:slitkows.i...@gmail.com>>
Date: Wednesday, 21 May 2025 at 08:48
To: 'Greg Mirsky' mailto:gregimir...@gmail.com>>, 
Matthew Bocci (Nokia) mailto:matthew.bo...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> mailto:bess@ietf.org>>, 
'idr-chairs' mailto:idr-cha...@ietf.org>>, 
rtg-...@ietf.org<mailto: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 mailto:gregimir...@gmail.com>>
Sent: Wednesday, May 21, 2025 12:59 AM
To: Matthew Bocci (Nokia) 
mailto:matthew.bocci=40nokia@dmarc.ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org>; 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

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) 
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.o

[bess] Re: WG Last Call for Proposed Revision to BESS WG Charter

[Matthew Bocci (Nokia)]

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 
Date: Wednesday, 21 May 2025 at 08:48
To: 'Greg Mirsky' , Matthew Bocci (Nokia) 

Cc: bess@ietf.org , 'idr-chairs' , 
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 
Sent: Wednesday, May 21, 2025 12:59 AM
To: Matthew Bocci (Nokia) 
Cc: bess@ietf.org; idr-chairs ; 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) 
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 re

[bess] Re: WG Last Call for Proposed Revision to BESS WG Charter

[slitkows.ietf]

Hi Greg,

 

This list is not limiting but just highlighting the most common one.

 

From: Greg Mirsky  
Sent: Wednesday, May 21, 2025 12:59 AM
To: Matthew Bocci (Nokia) 
Cc: bess@ietf.org; idr-chairs ; 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) 
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  
<https://datatracker.ietf.org/doc/rfc4364/> RFC4364,  
<https://datatracker.ietf.org/doc/rfc4659/> RFC4659, RFC6513, RFC6514 and  
<https://datatracker.ietf.org/doc/rfc9252/> RFC9252) for supporting unicast and 
multicast provider-provisioned L3VPNs.
*   BGP-enabled L2VPNs (based on  
<https://datatracker.ietf.org/doc/rfc4664/> RFC 4664,  
<https://www.rfc-editor.org/rfc/rfc7432.html> RFC7432 and  
<https://datatracker.ietf.org/doc/rfc9252/> 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:

 

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 models for provisioning and operations.
f.  Redundancy, multi-homing, load-balancing, and similar resiliency 
mechanisms.
g.  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 collabora

[bess] Re: WG Last Call for Proposed Revision to BESS WG Charter

[Greg Mirsky]

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)  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
>, 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:
>
>
>
>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

[bess] Re: WG Last Call for Proposed Revision to BESS WG Charter

[Gunter van de Velde (Nokia)]

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 
Sent: Tuesday, May 20, 2025 5:39 AM
To: Linda Dunbar ; Matthew Bocci (Nokia) 
; bess 
Cc: idr-chairs ; rtg-ads 
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) 
mailto:matthew.bo...@nokia.com>>
Sent: Monday, May 19, 2025 7:08 AM
To: Linda Dunbar 
mailto:linda.dun...@futurewei.com>>; 
bess@ietf.org<mailto:bess@ietf.org>
Cc: idr-chairs 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 

[bess] Re: WG Last Call for Proposed Revision to BESS WG Charter

[Chongfeng Xie]

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)  
Sent: Monday, May 19, 2025 7:08 AM
To: Linda Dunbar ; bess@ietf.org
Cc: idr-chairs ; 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 
Date: Friday, 16 May 2025 at 01:22
To: Matthew Bocci (Nokia) , bess@ietf.org 

Cc: idr-chairs , 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)  
Sent: Monday, May 12, 2025 1:41 AM
To: bess@ietf.org
Cc: idr-chairs ; 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 shoul

[bess] Re: WG Last Call for Proposed Revision to BESS WG Charter

[Linda Dunbar]

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) 
Sent: Monday, May 19, 2025 7:08 AM
To: Linda Dunbar ; bess@ietf.org
Cc: idr-chairs ; 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 
mailto:linda.dun...@futurewei.com>>
Date: Friday, 16 May 2025 at 01:22
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: 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) 
mailto:matthew.bocci=40nokia@dmarc.ietf.org>>
Sent: Monday, May 12, 2025 1:41 AM
To: bess@ietf.org
Cc: idr-chairs mailto: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 

[bess] Re: WG Last Call for Proposed Revision to BESS WG Charter

[Matthew Bocci (Nokia)]

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 
Date: Friday, 16 May 2025 at 01:22
To: Matthew Bocci (Nokia) , bess@ietf.org 

Cc: idr-chairs , 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) 
Sent: Monday, May 12, 2025 1:41 AM
To: bess@ietf.org
Cc: idr-chairs ; 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 iss

[bess] Re: WG Last Call for Proposed Revision to BESS WG Charter

[Linda Dunbar]

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:

  1.  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) 
Sent: Monday, May 12, 2025 1:41 AM
To: bess@ietf.org
Cc: idr-chairs ; 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 spec

[bess] Re: WG Last Call for Proposed Revision to BESS WG Charter

[Matthew Bocci (Nokia)]

Hi Loa

Yes, I agree that is contradictory. The second sentence morphed out of 
something similar in the current charter that pointed to PALS for LDP signaling 
for L2VPNs.

How about the following rewording of the paragraph?:

> 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.

Thanks
Matthew

From: Loa Andersson 
Date: Monday, 12 May 2025 at 11:04
To: Matthew Bocci (Nokia) , bess@ietf.org 

Cc: idr-chairs , rtg-...@ietf.org 
Subject: Re: [bess] 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.



All,

I admit that English grammar is not my strong side, but it seems to me
that there is some type of contradiction, in the following two sentences
from the second bullet of the proposed charter.


Den 12/05/2025 kl. 16:40, skrev Matthew Bocci (Nokia):
> 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.

To me the first sendtence:

Only types of L2VPN that utilize BGP for discovery, signaling, or for
some other purposes related to the VPN are in scope.

Means that a L2VPN might use one of the three (discovery, signaling or
"other", are within scope, i.e. the L2VPN might use BGP for example for
discovery, but not signaling and "other", but still be in scope.

However the next sentence says:

L2VPN solutions that do not utilize BGP for signaling are out of scope
of the BESS working group.

To me this means that a L2VPN that uses BGP for discovery or "other" are
out of scope if it does not use BGP for signaling.

/Loa

--
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
l...@pi.nu
loa.pi@gmail.com
___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org

[bess] Re: WG Last Call for Proposed Revision to BESS WG Charter

[Loa Andersson]

All,

I admit that English grammar is not my strong side, but it seems to me 
that there is some type of contradiction, in the following two sentences 
from the second bullet of the proposed charter.



Den 12/05/2025 kl. 16:40, skrev Matthew Bocci (Nokia):
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.


To me the first sendtence:

Only types of L2VPN that utilize BGP for discovery, signaling, or for
some other purposes related to the VPN are in scope.

Means that a L2VPN might use one of the three (discovery, signaling or 
"other", are within scope, i.e. the L2VPN might use BGP for example for

discovery, but not signaling and "other", but still be in scope.

However the next sentence says:

L2VPN solutions that do not utilize BGP for signaling are out of scope 
of the BESS working group.


To me this means that a L2VPN that uses BGP for discovery or "other" are 
out of scope if it does not use BGP for signaling.


/Loa

--
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
l...@pi.nu
loa.pi@gmail.com

___
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org