Hi again, > 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.
Per other email. Since I have suggested text I'll make the change. > 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)"? Yeh, that was garbled. > 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'. Ack > 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. Hmmm. Yes. New version when I'm allowed to post it. Cheers, Adrian _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
