Benjamin Kaduk has entered the following ballot position for draft-ietf-bess-datacenter-gateway-12: 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/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The -12 does address the discuss point that I raised, thank you! In re-reading the draft so as to clear my discuss position, one thing that occurred to me is that a reader might wonder what mechanisms are in place to prevent an attacker outside of a site from spoofing an auto-discovery route with a given site's site identifier. (The security considerations already dutifully considers the case of a node in the site that is not a gateway being able to falsify an auto-discovery route.) As far as I can tell this is not an issue because nodes in the site will not accept auto-discovery routes that initiate from outside the site, based on configured knowledge of whether a given BGP peering is internal or external. The document already makes some allusions to this by specifying that the actual tunnel encapsulation with the union of all GWs' data is only included in "every route advertised externally to that site", implying that the auto-discovery routes are on the non-external (i.e., internal) advertisements. It might (or might not) be worth being more explicit about auto-discovery only occuring internally within a site, to clarify this mechanism of action. NITS Section 1 Data centers (DCs) are critical components of the infrastructure used by network operators to provide services to their customers. DCs (sites) are interconnected by a backbone network, which consists of any number of private networks and/or the Internet, by gateway routers (GWs). [...] This currently looks like "interconnected by <X> (...), by <Y>" which doesn't seem right. Maybe end the sentence after "and/or the Internet" and finish with "Each DC is connected to the backbone by one or more gateway routers (GWs)"? The solution described in this document is agnostic as to whether the transit ASes do or do not have SR capabilities. the solution uses SR to stitch together path segments between GWs and through the ASBRs. Start the sentence with a majuscule 'T'. technique will experience scaling issues. This all means that the Add-Paths approach is limited to sites connected over a single AS. I'd consider "effectively limited"; we know that some groups/individuals have a high capacity for hitting themselves in the way that recursive Add-Path would entail. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
