Gunter, Thank you very much! Will go through all the ballot comments, address them, and solicit feedback from the BESS WG.
Linda From: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com> Sent: Tuesday, December 10, 2024 4:06 AM To: Linda Dunbar <linda.dun...@futurewei.com>; bess@ietf.org Subject: RE: Revision of draft-ietf-bess-bgp-sdwan-usage and response to Gunter's comments Hi Linda, Thanks for the heads-up and for the responses. The document was returned to the working group for further processing after the IESG ballot. You can find both the blocking and non-blocking items identified by the IESG here: https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/ballot/. These should be reviewed and addressed in the next round of draft updates when the document further evolves. Also, due to a Datatracker bug, when the expired document was returned to the working group, it was automatically marked as "dead." I've asked the Secretariat to correct this status back to "I-D Exists." (This incorrect status currently affects visibility, as the draft won't appear where it normally should.) Be well, G/ From: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> Sent: Monday, December 9, 2024 9:40 PM To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com<mailto:gunter.van_de_ve...@nokia.com>>; bess@ietf.org<mailto:bess@ietf.org> Subject: Revision of draft-ietf-bess-bgp-sdwan-usage and response to Gunter's comments 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. Gunter, We have revised the draft-ietf-bess-bgp-sdwan-usage to address your comments & feedback: https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/ Initially, we intended to merge the content from the draft-ietf-bess-bgp-sdwan-usage to the https://datatracker.ietf.org/doc/draft-ietf-idr-sdwan-edge-discovery/ . However, based on the early Directorate reviews of draft-ietf-idr-sdwan-edge-discovery, it was recommended to maintain separate documents for the use cases and requirements, as well as an overview of the pros and cons of using BGP to control SD-WAN. This document is particularly valuable given the limited prior work on SD-WAN within the IETF. Here are the responses to your comments: Comment 1: WGLC and Document Purpose "The draft has undergone substantial updates, and the technologies it discusses have evolved substantially during this process. As a first step, it would be prudent to establish consensus on the proposed changes through a new Working Group Last Call (WGLC). This will ensure that the document is thoroughly reviewed and represents the rough consensus and that it has the full support of the Working Group as the BESS solution for the specified problem space." Response: We agree that conducting a new WGLC is an important step to validate the substantial updates and ensure rough consensus. The updated draft incorporates feedback received and reflects the evolution of SD-WAN technologies. The proposed use of BGP as the control plane and IPsec as the data plane aligns with the stated objectives and demonstrates practical applicability for managing SD-WAN overlay networks. The WGLC will provide an opportunity to confirm the Working Group's support for this solution as the BESS-endorsed approach. ________________________________________ Comment 2: Ambiguous Purpose "Another question to raise during WGLC is about the recurring issue noted during IESG review about the ambiguous purpose of the document. The draft broadly suggests the possibility of utilizing BGP for the control plane and IPsec for the data plane. The necessity of an RFC to establish this practice is questionable." Response: The purpose of the document is to define a standardized approach to using BGP for the control plane in SD-WAN overlay networks, enabling scalability, flexibility, and interoperability. While the BGP for control and IPsec for data plane is not new, this document formalizes their application in SD-WAN scenarios, addressing challenges such as constrained propagation, peer authentication, and hybrid underlay integration. This standardization ensures consistent implementation and reduces the risk of fragmentation in deployments. ________________________________________ Comment 3: Clarification on "Revising" RFCs "The following is stated: 'This draft is revising the obsoleted RFC for IPsec L3VPN to use the Tunnel Encapsulation (RFC9012).' It is unclear to me what 'revising' means in the context of RFCs." Response: The use of "revising" refers to updating the mechanisms described in the obsoleted RFC for IPsec L3VPN to align with the newer capabilities of Tunnel Encapsulation as defined in RFC9012. This draft builds upon prior work by adapting it to current standards and practices, ensuring it remains relevant to modern SD-WAN deployments. ________________________________________ Comment 4: Scope of BESS WG "The rationale for considering draft-ietf-bess-bgp-sdwan-usage within the scope of the BESS charter is unclear. BESS is not mandated to define, specify, or expand upon every possible network service using any conceivable forwarding plane merely because BGP serves as the control plane." Response: The draft focuses on enabling L3 VPN services over hybrid underlay paths, aligning with the BESS charter, which states: 1. "The BGP Enabled Services (BESS) working group is responsible for defining, specifying, and extending network services based on BGP." 2. "Mechanisms to support BGP-enabled services in the presence of multi-homing of Customer Edge (CE) devices to multiple Provider Edge (PE) devices to provide load-balancing and resilience." By proposing mechanisms for managing SD-WAN overlays using BGP, the draft remains within the scope of defining and extending network services based on BGP. ________________________________________ Comment 5: Ambiguity of the Charter Scope "If the draft discusses topics beyond this specified list, they should be considered outside the scope of the BESS Working Group. While there may be topics closely related to those on the list, as you've identified, addressing these would require a rechartering of the BESS Working Group." Response: The draft is firmly within the current scope of the BESS Working Group, as it does not introduce new services outside the charter but optimizes existing BGP-based solutions for SD-WAN overlays. Any further expansion beyond this focus would indeed necessitate rechartering, but this draft remains aligned with the Working Group's core competencies. ________________________________________ Proposed Actions 1. Conduct a new Working Group Last Call (WGLC) to validate updates and secure consensus. 2. Clarify the document's purpose and its alignment with the BESS charter during the WGLC. 3. Ensure explicit wording in the draft to reflect its intent, emphasizing standardization and practical application in SD-WAN scenarios. These updates have been integrated into the revision. Thank you, Linda From: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com<mailto:gunter.van_de_ve...@nokia.com>> Sent: Wednesday, May 1, 2024 9:39 AM To: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org<mailto:draft-ietf-bess-bgp-sdwan-us...@ietf.org>; bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; 'rtg-...@ietf.org' <rtg-...@ietf.org<mailto:rtg-...@ietf.org>> Subject: RE: Can we have a call to chat if the revision resolved AD's DISCUSS comments? Re: return decision for draft-ietf-bess-bgp-sdwan-usage to allow additional WG time Hi Linda, Thank you for the update. The draft has undergone substantial updates, and the technologies it discusses has evolved substancial during this process. As a first step, it would be prudent to establish consensus on the proposed changes through a new Working Group Last Call (WGLC). This will ensure that the document is thoroughly reviewed and represents the rough consensus, and that it has the full support of the Working Group as the BESS solution for the specified problem space. Another question to raise during WGLC is about the recurring issue noted during IESG review about the ambiguous purpose of the document. The draft-ietf-bess-bgp-sdwan-usage broadly suggests the possibility of utilizing BGP for the control plane and IPSec for the data plane. The necessity of an RFC to establish this practice is questionable. The following is stated: "This draft is revising the obsoleted RFC for IPsec L3VPN to use the Tunnel Encapsulation (RFC9012)" It is unclear to me what "revising" means in the context of RFCs? RFCs can undergo various status changes as they evolve or become outdated. Here are the main actions that can happen with an RFC: * Updated: An RFC can be updated by a subsequent RFC. This means that new information or modifications have been added to the original document to reflect current technology or standards. * Obsoleted: An RFC becomes obsoleted when a newer RFC replaces it. The new RFC provides either revised information or entirely new standards that supersede those in the older RFC. * Historic: An RFC can be moved to "Historic" status when it is deemed to no longer be relevant for current use. This status is used for documents that were once useful or applicable but are no longer considered suitable for any current practical application. * Errata: After an RFC is published, errors may be found within the document. Errata are filed to document these errors and their corrections. This does not change the RFC itself, but provides official recognition of the error and its recommended correction. * Standardization: RFCs can also go through different levels of standardization, such as "Proposed Standard," "Draft Standard," and "Internet Standard." This categorization indicates the level of maturity and stability of the protocol or specification described in the RFC. These status changes help manage the lifecycle of Internet standards and ensure that they remain up-to-date and relevant to the current technological environment. I am not aware of what is revising of RFCs. Discussion about the BESS WG scope: The rationale for considering draft-ietf-bess-bgp-sdwan-usage within the scope of the BESS charter is unclear. BESS is not mandated to define, specify, or expand upon every possible network service using any conceivable forwarding plane merely because BGP serves as the control plane. [Linda] The draft is about enabling L3 VPN services over hybrid underlay paths/links. The proposed work should be within the BESS charter based on the following bullets of the BESS charter: "The BGP Enabled Services (BESS) working group is responsible for defining, specifying, and extending network services based on BGP." "The working group may work on: Mechanisms to support BGP-enabled services in the presence of multi-homing of Customer Edge (CE) devices to multiple Provider Edge (PE) devices to provide load-balancing and resilience." This statement was taken out of context. John made an earlier comment about this: https://mailarchive.ietf.org/arch/msg/bess/RdI2h98N8IJC_7mR5j8pPnq7Iuk/ In the charter the text below is also found: ""The BGP Enabled Services (BESS) working group is responsible for defining, specifying, and extending network services based on BGP. In particular, the working group will work on the following services: ...." In summary, the list outlines the services covered under BESS's charter. If the draft discusses topics beyond this specified list, they should be considered outside the scope of the BESS Working Group. While there may be topics closely related to those on the list, as you've identified, addressing these would require a rechartering of the BESS Working Group. "The working group may work on: *Mechanisms to support BGP-enabled services in the presence of multi- homing of Customer Edge (CE) devices to multiple Provider Edge (PE) devices to provide load-balancing and resilience. *Auto-discovery of sites that participate in the BGP-enabled service., beyond the list for which BESS is responsible, is ..etc etc..." I'll work with the BESS chairs to update the BESS charter to add more explicit focus upon BESS core competences. G/ From: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> Sent: Tuesday, April 30, 2024 7:09 AM To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com<mailto:gunter.van_de_ve...@nokia.com>> Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org<mailto:draft-ietf-bess-bgp-sdwan-us...@ietf.org>; bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> Subject: Can we have a call to chat if the revision resolved AD's DISCUSS comments? Re: return decision for draft-ietf-bess-bgp-sdwan-usage to allow additional WG time 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. Gunter, The revised document (draft-ietf-bess-bgp-sdwan-usage-23) should have fixed the technical issues pointed by John Scudder. Please see our resolutions to John on the technical issues he raised (mainly about removing the obsolete tunnel type "IPsec", removing the RFC4684 Constrained Route Distribution to address the SD-WAN security model, and the Security Consideration update). As for the questions to the BESS WG community, please see below for our response. Can we have a phone chat with you to discuss if there are other pending issues and what we can do to move the draft forward? Thank you, Linda -----Original Message----- From: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com<mailto:gunter.van_de_ve...@nokia.com>> Sent: Thursday, April 18, 2024 6:41 AM To: draft-ietf-bess-bgp-sdwan-us...@ietf.org<mailto:draft-ietf-bess-bgp-sdwan-us...@ietf.org> Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; 'rtg-...@ietf.org' <rtg-...@ietf.org<mailto:rtg-...@ietf.org>>; 'BESS' <bess@ietf.org<mailto:bess@ietf.org>> Subject: return decision for draft-ietf-bess-bgp-sdwan-usage to allow additional WG time Hi Authors, All, Please review the information regarding the return decision for draft-ietf-bess-bgp-sdwan-usage. There are unresolved foundational technical issues that require significant attention and a consensus within the working group. Consequently, allowing additional time for this draft within the Working Group will be beneficial. This approach will ensure the document is thoroughly vetted and refined before further IETF processing. Questions to the BESS WG community: ================================ * A recurring issue noted during the IESG review concerns the ambiguous purpose of the document. The draft-ietf-bess-bgp-sdwan-usage broadly suggests the possibility of utilizing BGP for the control plane and IPSec for the data plane. The necessity of an RFC to establish this practice is questionable. * The rationale for considering draft-ietf-bess-bgp-sdwan-usage within the scope of the BESS charter is unclear. BESS is not mandated to define, specify, or expand upon every possible network service using any conceivable forwarding plane merely because BGP serves as the control plane. [Linda] The draft is about enabling L3 VPN services over hybrid underlay paths/links. The proposed work should be within the BESS charter based on the following bullets of the BESS charter: "The BGP Enabled Services (BESS) working group is responsible for defining, specifying, and extending network services based on BGP." "The working group may work on: Mechanisms to support BGP-enabled services in the presence of multi-homing of Customer Edge (CE) devices to multiple Provider Edge (PE) devices to provide load-balancing and resilience." This draft is revising the obsoleted RFC for IPsec L3VPN to use the Tunnel Encapsulation (RFC9012) About draft-ietf-bess-bgp-sdwan-usage technology: ========================================== * RFC5566, which is obsolete, is currently utilized as a foundational component within draft-ietf-bess-bgp-sdwan-usage. It is advisable that newly proposed RFCs should avoid incorporating obsolete technologies. [Linda] The latest revision (-23) has removed the "IPsec" Tunnel Type. Instead, the revision-23 is using the SDWAN-Hybrid (=25) of the IANA assigned tunnel type (proposed by draft-ietf-idr-sdwan-edge-discovery) * There appears to be a misuse of the Encapsulation Extended Community, as detailed in https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fidr%2FumBB5yfoC3mFMpIWIT2K8159Gos%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C77b549716fa04cca002108dc5fad23ef%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638490444441412343%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=lg8g5ZLBfBH88yiDsmozfkMvlMnG4MAwrA7gHHgXrt0%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/idr/umBB5yfoC3mFMpIWIT2K8159Gos/> . [Linda] Revision -23 should have fixed this issue. * The "Encapsulation Extended Community: TYPE = IPsec" does not exist, according to the IANA registry of BGP tunnel encapsulation types. see https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fbgp-tunnel-encapsulation%2Fbgp-tunnel-encapsulation.xhtml%23tunnel-types&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C77b549716fa04cca002108dc5fad23ef%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638490444441422772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=qwjteHie5GE97KmZRsCjTOe1J6L%2BGhQphU5YvkroRfA%3D&reserved=0<https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml#tunnel-types> [Linda] Revision -23 should have fixed this issue. * Newly proposed RFCs should not assume the existence of unestablished code-points as if they were established; if a new tunnel type for IPsec Tunnel underlay paths is required, it must be formally defined prior to implementation. [Linda] There is no unestablished code-points used in Revision -23. * RFC 9012 includes mechanisms for selecting or preferring NLRIs using the Color Extended Community, which might interact with the draft-ietf-bess-bgp-sdwan-usage's TYPE = IPsec proposal. [Linda] Revision -23 should have fixed this issue. * The term "Policy" is used variably throughout several sections, possibly leading to confusion about its application to different objectives. Clarity could be improved by specifying the types of policy being discussed. [Linda] Revision -23 should have fixed this issue. * Section 3.1.5 mentions that "Route-Reflectors... has the policy governing communication among peers", suggesting existing knowledge of route destinations, thereby questioning the necessity of RFC 4684. [Linda] Revision -23 should have fixed this issue, removed the reference RFC4684. * The security architecture concerning BGP-based structures and tunnel signaling should be more thoroughly explored, particularly in Section 8, rather than being briefly mentioned in Section 3.1.5. * Section 8 requires enhancements to adequately address the issues raised in Roman's discuss items. [Linda] Section 8 has been updated in revision-23. * The text in Sections 6.2.2, 6.3.2, and 8 mentions the need for "additional anti-DDoS mechanisms." This requires further specification of the expected mechanisms [Linda] This is referring to VPN PE's WAN ports may not have Anti-DDoS enabled. But for PEs in SD-WAN network with WAN facing the Internet, Anti-DDoS feature needs to be enabled. Linda
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
