Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing
draft-ietf-bess-datacenter-gateway-13

[[ comments ]]

[ section 8 ]

* My understanding is that this will allow a packet from "Ingress" with an
  SRH that includes SRv6 SIDs associated with either GW1 or GW2 in "Egress".

  RFC 8754 (sections 5.1 and 7) discusses the necessity to filter SRH packets
  at the SR domain ingress point.  If my understanding above is correct, I
  think it could be more clear that deliberately not filtering SRH at the
  domain boundaries is a choice being made here which, further, may have
  consequences of the sort described in RFC 5095.

  But maybe I've misunderstood.

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?

Thanks for the nice work on that shepherd writeup.

Why is the SHOULD in Section 8 only a SHOULD?  Why might I legitimately not do what it says?

Thank you to Daniel Migault for the SECDIR review.

Thanks for addressing my DISCUSS by adding new language about the need to secure the traffic via encrypted tunnels when traversing untrusted networks.

I support John's DISCUSS position.

I am changing my previous DISCUSS to a No Objection; I was planning on Abstain, but after yet more thought I think No Objection is the best position.

Background: 
When thinking about this document I still feel disquiet (actually "heebie-jeebies" is probably a better description!), but it's not actually **this** document which is causing me concern, it is rather RFC8402 (and the fact that this facilitates /propagates its use).  I still feel like stamping my feet and throwing all of my toys out the cot, but my grump cannot realistically be pointed at this draft.


I'd also like to recognize that Adrian Farrel did a great job on talking me down from my ledge. I was filled with righteous indignation, and his helpful and friendly tone helped me understand and process my thoughts; this directly led to my willingness to change. Thank you everyone.

Thank you for the work put into this document.

I support John Scudder's first DISCUSS point.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

Thanks for Matthew Bocci for his shepherd's write-up (including the WG consensus).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 3 --
How will the GW identifiers be unique across all interconnected SR domains ? Section 9 is rather hand waving.

-- Section 10 --
Is there any reason why the doc shepherd is not acknowledged ?

== NITS ==

-- Section 1 --
s/against connection of device failure/against connection or device failure/ ?

I find the use of "ingress" in "source (ingress)" confusing, should the reader assume that it is "source (SR-domain ingress)" ?

The concept of an "SR domain identifier" is not part of rfc8402; it is casually introduced in §3: "A route target ([RFC4360]) is attached to each GW's auto-discovery route and has its value set to the SR domain identifier."  This is a significant change to the SR architecture.

In line with the general use of the mechanism in this document (from John's DISCUSS), I believe it is unnecessary to add anything new to the SR architecture.  Instead, the term could be changed to simply "local domain identifier" (or something like that).

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.

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 8, nit:
> e BGP feature that allows the advertisement of multiple paths in BGP (known a
>                               ^^^^^^^^^^^^^^^^
The usual collocation for "advertisement" is "for", not "of". Did you mean
"advertisement for"?

Section 1, paragraph 10, nit:
> oute advertised by a GW identifies all of the GWs to the same SR domain (see
>                                    ^^^^^^^^^^
Consider using "all the".

Section 3, paragraph 12, nit:
> ulation attribute included in the BGP best route; i.e., the Tunnel Encapsula
>                                   ^^^^^^^^^^^
A determiner is probably missing here: "BGP the best".

Section 4, paragraph 1, nit:
> State and Egress Peer Engineering When a remote GW receives a route to a pre
>                                   ^^^^
"When" at the beginning of a sentence usually requires a 2nd clause. Maybe a
comma, question or exclamation mark is missing, or the sentence is incomplete
and should be joined with the following sentence.

Section 8, paragraph 6, nit:
> he AS that hosts the domain) can see all of the gateways to a site. For examp
>                                      ^^^^^^^^^^
Consider using "all the".

Section 8, paragraph 8, nit:
> in black-holing of traffic. All of the issues in the list above could cause
>                             ^^^^^^^^^^
Consider using "all the".

Section 11.2, paragraph 9, nit:
> hen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911,
>                           ^^^^^^^^^^^^^^^^
The usual collocation for "Advertisement" is "for", not "of". Did you mean
"advertisement for"?

Document still references draft-ietf-idr-tunnel-encaps, but that has been
published as RFC9012.

Document still references draft-ietf-idr-bgp-ls-segment-routing-ext-16, but -18
is the latest available revision.

Hi,

Thanks for this document.

The draft has a manageability considerations section - thanks - but I would like to check whether assignment of the SR domain identifier would expect to be configured via YANG?  If so, is there a YANG data model in the works that will cover this functionality?  Having an informational reference to the data model may be helpful to readers.

Regards,
Rob