John Scudder has entered the following ballot position for draft-ietf-bess-datacenter-gateway-10: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have several points I’d like to discuss, listed below from most general to most specific. 1. There’s surprisingly little in this document that seems to be SR-specific (and what there is, has some problems, see below). Is there some reason you rule out interconnecting domains using other tunneling technologies? I ask this question first because if the answer were to be “oh huh, we don’t need to make this SR-specific after all” some of the other things I’m asking about might go away. 2. There’s no discussion about what trust model you’re assuming. SR brings with it its own assumed trust model, laid out in RFC 8402 as “SR operates within a trusted domain” (whatever *that* means). On the one hand, given you’re tying yourself to SR you presumably are tied to its trust model. On the other hand, there are some tantalizing tidbits that suggest otherwise. I would be happier if there were some explicit description of the trust model you’re presuming. It’s hard to evaluate some aspects of the document without knowing if you’re assuming the RFC 8402 closed domain model, or something else. 3. The use of the term “SR domain” in this document appears inconsistent with its definition in RFC 8402. Here’s that definition, from §2: Segment Routing domain (SR domain): the set of nodes participating in the source-based routing model. These nodes may be connected to the same physical infrastructure (e.g., a Service Provider's network). They may as well be remotely connected to each other (e.g., an enterprise VPN or an overlay). If multiple protocol instances are deployed, the SR domain most commonly includes all of the protocol instances in a network. However, some deployments may wish to subdivide the network into multiple SR domains, each of which includes one or more protocol instances. It is expected that all nodes in an SR domain are managed by the same administrative entity. And notably, later in 8402 §8 we are told that By default, SR operates within a trusted domain. Traffic MUST be filtered at the domain boundaries. Which specifically means, to take the MPLS instantiation of SR (§8.1): SR domain boundary routers MUST filter any external traffic destined to a label associated with a segment within the trusted domain. This includes labels within the SRGB of the trusted domain, labels within the SRLB of the specific boundary router, and labels outside either of these blocks. External traffic is any traffic received from an interface connected to a node outside the domain of trust. More simply put, 8402 says you can’t send an SR packet from outside an SR domain, into that domain. But your document is written in terms of a multiplicity of SR domains, for example this in Section 1: Tunnel Encapsulation attribute. The gateway in the ingress SR domain can now see all possible paths to X in the egress SR domain Maybe a quick fix, assuming you really do subscribe to the RFC 8402 trust model, is to invent, define, and use the term “SR subdomain” and deem all the subdomains to comprise one SR domain, in the sense of RFC 8402 §2 — “They may as well be remotely connected to each other (e.g., an enterprise VPN or an overlay)” seems to describe your situation pretty well. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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? _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
