Hi Roman Thanks for your review and comments.
Please see below. Matthew From: Roman Danyliw via Datatracker <nore...@ietf.org> Date: Wednesday, 25 June 2025 at 12:42 To: The IESG <i...@ietf.org> Cc: bess-cha...@ietf.org <bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org> Subject: Roman Danyliw's No Objection on charter-ietf-bess-01-02: (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. Roman Danyliw has entered the following ballot position for charter-ietf-bess-01-02: 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: ---------------------------------------------------------------------- ** There are two bulleted lists that suggest scope: list-1 per the text after “in particular, the working group will work on the following services” and list-2 per the text after “the following is a list of specific aspects that the WG is expected to work on”. -- can something be in scope per list-1, but not list-2? -- per list-2, is something is only a work item “expected to work on” does this list of work unbounded? MB> The WG covers protocol maintenance and extensions for a set of services that are both widely deployed (some for as long as 20 years or so), and are experiencing growth in new areas such as data centres, and extensions driven by enhancements as well as YANG modelling. We have tried to make the list (2) as complete as possible, but I suppose it is possible that something unforeseen could come up. I believe it is fairly typical for long-standing working groups in the routing area that maintain and extend existing protocol to have a degree of flexibility in the exact list topics that are in scope within the base technology that they are chartered for. ** Per “In particular, the working group will work on the following services: … BGP-enabled IP VPN solutions … for supporting unicast and multicast provider-provisioned L3VPNs”, what is the actual work? Is it extensions on existing “BGP-enabled IP VPN solutions”? Same question for “… BGP-enabled L2VPN”? MB> A set of drafts defining extensions and maintenance of those services. Maybe we should phrase this differently (this was inherited from the old charter) : The following services are in-scope: - BGP-enabled IP VPN Solutions… - BGP-enabled L2VPNs… ** Per “The WG will focus primarily on producing BGP specifications for services in its charter. The WG will work on informational documents only related to operational and deployment aspects of the services for which the WG is also producing the protocols’ specifications”, the second sentence makes a explicit reference document status. What does it imply about the “BGP specifications”, they cannot be information? Experimental? They must be PS? MB> In general BGP specs need to be PS. BGP is used for both services and base routing for the internet and so any protocol extensions need to go through the rigour of the standards track. ** Per the list-2 items, I have some confusing on the framing these bullets when trying to understand the output they produce. For example: -- “(a) BGP signaling related to the discovery of service endpoints” vs. “the exchange of service routes and their provisioning”. The first seems to suggest a BGP extension, what is the second making? Is it not “BGP signaling”? MB> BGP is traditionally a routing protocol but it is being used in IP VPN, BGP L2VPNs as a discovery protocol as well, which is why I think it was called out. The second also uses BGP signaling but the exchange of routes is a basic MP-BGP function so it wasn’t explicitly called out here. -- “(c) Scaling and convergence improvements”, how? What would be the output? Is this a protocol extension to some existing work? 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: MB> For the “scaling and convergence improvements” stuff, we have drafts such as draft-ietf-bess-evpn-fast-reroute and RFCs such as RFC9722 (Fast Recovery for EVPN Designated Forwarder Election). Since maintenance and on going enhancements is part of the charter this is made fairly open. ** Per “e) Definition of YANG data models for device provisioning and operations”: -- Does the WG really have the capacity to take on this YANG module work? I observe that the WG planned to do YANG module work with milestones suggesting completion in 2020: MB> I think so, but it was paused a while back as we have a large backlog of protocol extensions documents now that our queue has moderated, subject to the editors picking it up. Dec 2020 Submit a Yang or SMI datamodel for RFC4364 to IESG as PS draft-ietf-bess-l3vpn-yang Dec 2020 Submit a YANG datamodel for L2VPN to IESG as PS draft-ietf-bess-l2vpn-yang Dec 2020 Submit a YANG datamodel for mVPN to IESG as PS draft-ietf-bess-mvpn-yang Dec 2020 Submit a Yang or SMI datamodel for E-VPN to IESG as PS draft-ietf-bess-evpn-yang However, all four of these documents are expired for multiple years. -- What specific YANG modules is the WG considering? MB> The WG should really be picking up the existing drafts covering YANG models for device config and state for the services we are chartered for. That is essentially what those existing drafts cover. ** Per list items (g) and (h): -- they include the text, documents “… that are already adopted at the time of this charter revision”. Instead, please just explicitly list the documents. I don’t understand which documents this text is referencing. MB> Agreed. -- does the scope suggested by (g) and (h) limited only to the already adopted documents (how I understood the text) OR will future document be coming? MB> Yes. It is intended to “grandfather in” a couple of existing drafts that were adopted by the WG a while ago, and for which substantial work was done. One of these (draft-ietf-bess-bgp-sdwan-usage) was borderline in-charter before, but has been progressed so far and couples into other work in ten routing area. There is consensus to get this done, but we need to be able to defocus future work on this type of draft and finish all the protocol extensions that we have. The other draft related to BGP extensions for multicast services. ** Per “OAM mechanisms related to services within the scope of the WG may be considered, following coordination with the Working Groups responsible for the underlying data plane technologies”, does this make OAM specifications in scope? Should that be in list-2? MB> Yes, it does. I will add that. ** There are no milestones associated with this larger scope. Please add some. Minimally, there are 20 already adopted drafts which have no milestones. Why not? MB> The intent is to define the scope more explicitly rather than to extend the scope. The old charter was very vague and out of date. I agree that the milestones need to be revised and updated in line with the new charter and the current WG drafts. The chairs will work with Gunter on that.
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
