Hi Matthew, Thanks for the follow-up and clarifications. All looks good.
Cheers, Med De : Matthew Bocci (Nokia) <matthew.bo...@nokia.com> Envoyé : mardi 24 juin 2025 10:48 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; The IESG <i...@ietf.org> Cc : bess-cha...@ietf.org; bess@ietf.org Objet : Re: Mohamed Boucadair's No Objection on charter-ietf-bess-01-00: (with COMMENT) Hi Med Thanks for your review and comments on the BESS charter. Please see below, prefixed by MB>. Regards Matthew From: Mohamed Boucadair via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> Date: Sunday, 22 June 2025 at 13:00 To: The IESG <i...@ietf.org<mailto:i...@ietf.org>> Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Subject: Mohamed Boucadair's No Objection on charter-ietf-bess-01-00: (with COMMENT) 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. Mohamed Boucadair has entered the following ballot position for charter-ietf-bess-01-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-bess/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for updating the charter. Please find some comments below. Comments marked as (*) are important to avoid overlapping with other groups. The last point is about a gentle request for consideration :-) # VPN as the only supported service CURRENT: 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: This text implicitly assumes that VPN is the only supported service as implied by "VPN signaling uses BGP" part. I think I would prefer having an explicit statement here. MB> Agreed that this could be tightened up. Maybe?: OLD: 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. NEW: The BGP Enabled Services (BESS) working group is responsible for defining, specifying, and extending VPN services over a packet switched network (PSN) where the VPN signaling uses BGP. # Business as usual There are several statements that I think can be simply removed as this is about business as usual: (1) Any contention in placement of the work will be resolved by the chairs and responsible Area Directors. MB> I think this is a hangover from the early days of the WG when it was created out of L2VPN and L3VPN. I agree it can be removed. (2) 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. MB> I think this is tied to the previous part of the sentence "The working group may also suggest new services to be supported by BGP...". We had a few issues in the past where we had drafts that made use of BGP for service signalling and weren't pure provider provisioned L2 or L3 VPNs, but made use of BESS building blocks. We wanted to make it clear how these or other services that don't fit into the existing set would be treated. I agree this is really business as usual, but I am not sure it does any harm to be clear. # On data models (*) CURRENT: e) Definition of YANG models for provisioning and operations ## VPN-related service and network data models (L2SM, L3SM, L2NM, L3SM, draft-ietf-opsawg-ac-lxsm-lxnm-glue, ietf-network-vpn-pm, etc.) are products of other WGs, not BESS. The plan for their maintenance is to hand those over to ONIONS. I suggest that we indicate that the work in BESS will be specifically on device models. MB> Agreed, although that device model includes both config and state for the BGP signaling needed. ## Many expired I-Ds on YANG The WG adopted several drafts in the past (e.g., draft-ietf-bess-l3vpn-yang, draft-ietf-bess-mvpn-yang, draft-ietf-bess-l2vpn-yang, draft-ietf-bess-evpn-yang) but all these were expired. Does the WG plan to revive some of this work? Any plan how to make this part better :-)? MB> These got parked because they were not being actively progressed and the WG was extremely busy with EVPN extensions. It wasn't just an issue of the draft editors as we also needed sufficient review of the drafts from the rest of the WG. I believe we should keep these in charter, but perhaps it is too early to complete all of them until the extensions to the base protocol (at least for the EVPN work) has matured. ## Be consistent with 8407bis OLD: e) Definition of YANG models ... NEW: e) Definition of YANG data models ... MB> Agreed # nit: "P" of BGP stands for "protocol" OLD: the core BGP protocol, NEW: the core BGP specification, MB> Agreed # Add MBONED to this list for multicast-related matters (*) CURRENT: The WG will also liaise with other relevant WGs, including but not limited to MPLS, SPRING, 6man, NVO3, and BFD, as appropriate. Btw, please use a consistent form to list WGs: s/6man/6MAN. MB> Agreed # Lastly, an OPS matter The WG produced many documents on EVPN that I find very useful. However, it is not always that easy to digest them. I wonder whether the WG considered developing some deployment recommendations or simply an architecture overview with the various EVPN specifications and how they fit together? MB> I agree this would be worthwhile but given the large queue of current documents that the WG is processing it is probably something we should consider for a future charter revision, if we have volunteers to do the work. Cheers, Med ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
