[bess] Benjamin Kaduk's No Objection on draft-ietf-bess-datacenter-gateway-12: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

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.