[bess] John Scudder's No Objection on draft-ietf-bess-datacenter-gateway-11: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-bess-datacenter-gateway-11: 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:
----------------------------------------------------------------------

Thanks for addressing my Discuss.

1. Abstract

   This document defines a mechanism using the BGP Tunnel Encapsulation
   attribute to allow each gateway router to advertise the routes to the
   prefixes in the Segment Routing domains to which it provides access,
   and also to advertise on behalf of each other gateway to the same
   Segment Routing domain.

The last clause has no object. To advertise WHAT? Possibly (?) it could be
rewritten “... provides access, including advertising them on behalf of...”

2. Section 1

   against connection of device failure.

“Of” -> “or”

3. Section 3

   o  A route target ([RFC4360]) is attached to each GW's auto-discovery
      route and has its value set to the SR domain identifier.

Insert “(defined below)” after “auto-discovery route”, please?

   The auto-discovery route that each GW advertises consists of the
   following:

The use of the definite article implies that each GW can advertise one, and
only one, auto-discovery route. Is this true?

4. Section 5

   When a packet destined for prefix X is sent on an SR TE path to a GW
   for the SR domain containing X (that is, the packet is sent in the
   Ingress Domain on an SR TE path that describes the path including
   within the Egress Domain), it needs to carry the receiving GW's label

I can’t understand the parenthetical, in particular “the path including within
the Egress Domain”.

Also, do you really mean “label”, or do you mean “SID”? I don’t think you
scoped this to only SR-MPLS, did you? Although reading on within §5 you talk
about the “label stack”, so it does appear you’re MPLS specific — probably this
should be said up front, in that case? The title should really be “… for
SR-MPLS Enabled Domain Interconnection”?

5. Section 6

   If the GWs for a given SR domain are configured to allow remote GWs
   to send them a packet in that SR domain's native encapsulation, then

This is forbidden by RFC 8402, see my discuss comment #3. Maybe this is just an
easy terminology fix, or maybe not.

6. Section 8

   All of the issues in the list above could cause disruption to domain
   interconnection, but are not new protocol vulnerabilities so much as
   new exposures of information that SHOULD be protected against using
   existing protocol mechanisms.  Furthermore, it is a general

What are the existing BGP protocol mechanisms that could be used to protect
against exposure of information? BGP itself doesn’t have any confidentiality
features nor do most of its common transports. Maybe you mean something
different, but if so that’s not clear to me.

   system.  It should be noted that BGP peerings are not discovered, but
   always arise from explicit configuration.

This is true at present, but IDR has work in progress on autodiscovery. (Same
comment applies with respect to Section 9.)

7. Section 9.1

   consideration.  When using the mechanisms defined in this document,
   the operator should consider carefully the effects of filtering
   routes.  In some cases this may be desirable, and in others it could
   limit the effectiveness of the procedures.

I believe the only use of route targets in this document is for the
autodiscovery routes.  If RTC were in use, through its normal operation the
gateways would exchange autodiscovery routes exactly as this specification
needs them to. So your cryptic warning above leaves me wondering, what are the
cases in which RTC impedes the function of the specification?

8. General

The autodiscovery mechanism is clear as far as it goes, but I think not all
failure modes are addressed. In particular, if there’s partial connectivity
within a domain, I think long-term black holing can ensue. Consider this case:
GW1 and GW2 are gateways in domain A. GW3 is a gateway in domain B. GW1 and GW2
discover one another and advertise one another’s encapsulation information
accordingly, when advertising a route to prefix X. However, there’s a problem
within GW1 and GW2’s domain, such that GW1 can reach X, but GW2 can’t. Even
though GW2 may know it can’t reach X, and indeed GW2 isn’t advertising X, GW1
is still advertising GW2 as a viable gateway to reach X, and GW3 may well route
traffic for X via GW2.

Admittedly, having partial connectivity within a domain as I’ve described is a
broken situation to begin with, but stuff happens, and your spec would make
matters worse. It might be worth acknowledging this issue somewhere in the
document?