Jim Guichard has entered the following ballot position for draft-ietf-bess-bgp-sdwan-usage-15: 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.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Several nits & comments for the authors to consider: ## Section 1: - Some traffic can be forwarded by edge nodes, based on their application identifiers instead of destination IP addresses, by placing the traffic onto specific overlay paths based on the application-specific policies. * Do the authors have a reference for this - does this imply DPI requirements or some other method to determine the application carried within the packets? What specifically is an 'application identifier'? ## Section 3.1.1 * Please expand on MPLS-VPN on the first usage with reference - RFC8388 does not document MPLS-VPN as a well-known term. ## Section 3.1.1: For IP-based client interfaces, L3VPN service requirements are applicable. * What are these 'L3VPN service requirements'? is there a reference so that the reader can understand what these requirements are? ## Section 3.1.3 * The figure has no reference - it should be 'Figure 1' - Please correct this. ## Section 3.2 * Expand 'SA' to 'Security Association (SA)' on first usage. ## Section 3.4 * Please provide references for 'MPLS-in-IP/GRE-in-IPsec'. ## Section 5.1 Dynamic Smart VPN (DSVPN)/Dynamic Multipoint VPN (DMVPN) protocol has been found to work reasonably well. * Neither DSVPN nor DMVPN are protocols - suggest removing 'protocol' from the above text. Also, you should provide a reference for both of these for readers who are not familiar with these solutions. ## Section 5.2 When using two separate BGP UPDATE messages, which is described by Section 4 and 8 of [RFC9012], UPDATE U1 has its Nexthop to the node loopback address and is recursively resolved to the IPsec SA tunnel detailed attributes advertised by the UPDATE U2 for the Node Loopback address. * Section 4 of RFC9012 simply describes the Encapsulation Extended Community so I am not sure how that is relevant to the above paragraph. Section 8 describes recursive next-hop resolution which seems to be what you are describing here so is probably the only reference that you need. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
