Ben, Thanks for your thorough review and discussion.
Yours Irrespectively, John Juniper Business Use Only > -----Original Message----- > From: BESS <bess-boun...@ietf.org> On Behalf Of Benjamin Kaduk via > Datatracker > Sent: Wednesday, July 21, 2021 1:22 PM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-bess-datacenter-gate...@ietf.org; matthew.bo...@nokia.com; > bess-cha...@ietf.org; bess@ietf.org > Subject: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-datacenter- > gateway-12: (with COMMENT) > > [External Email. Be cautious of content] > > > 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss- > criteria.html__;!!NEt6yMaO-gk!WM0wrcZUeK_Mcc3YdAxJJsDiUT_G1M-lAz- > 8g0fltDGASgWWcsQJ-toZT_lgRJk$ > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess- > datacenter-gateway/__;!!NEt6yMaO- > gk!WM0wrcZUeK_Mcc3YdAxJJsDiUT_G1M-lAz-8g0fltDGASgWWcsQJ- > toZ_kua3SE$ > > > > ---------------------------------------------------------------------- > 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bess__;!!N > Et6yMaO-gk!WM0wrcZUeK_Mcc3YdAxJJsDiUT_G1M-lAz-8g0fltDGASgWWcsQJ- > toZF8-VjNc$ _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
