Hi John, Thanks for the careful review.
> 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. I'm sorry this isn't clear, but the use of other tunnelling technologies is very much in scope. As the Introduction says: The various ASes that provide connectivity between the Ingress and Egress Domains could each be constructed differently and use different technologies such as IP, MPLS with global table routing native BGP to the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN. SR is used to identify the tunnels and provide end-to-end SR paths because the ingress and egress domains are SR domains, and the objective is to provide an end-to-end SR path. So we are not "making this SR aware" so much as enabling "SR-over-foo" using SIDs to identify the path segments that are tunnels. I don't know how to make this clearer except maybe using some red paint. We would write... The various ASes that provide connectivity between the Ingress and Egress Domains could each be constructed differently and use different technologies such as IP, MPLS with global table routing native BGP to the edge, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN. That is, the Ingress and Egress SR Domains can be connected by tunnels across a variety of technologies. This document describes how SR identifiers (SIDs) are use to identify the paths between the Ingress and Egress and the techniques in this document apply to routes of all AFI/SAFIs. > 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. I believe that the term "SR domain" in 8402 is basically defined as "a set of nodes that support SR". The description in (the ever-so-skimpy section 8 of 8402) says: By default, SR operates within a trusted domain. Traffic MUST be filtered at the domain boundaries. What does "by default" mean in that context? I think there are two things to think about: 1. Forwarding plane trust model. Can packets get into the SR system? The answer to that remains, "No, because traffic MUST be filtered at the domain boundaries." This requires that the domain boundary is the interface between an SR-capable node, and a non-SR node. In this document all GWs and ASBRs are part of the SR domain connected by tunnels across the transit ASes (although the nodes in the transit ASes are not part of that domain). I dare say that draft-farrel-spring-sr-domain-interconnect explains this better through examples, but the chairs of SPRING told us that that draft had no chance of progressing. 2. Control plane trust model. What is the trust model in the BGP system? I'm pretty sure that Section 8 of our draft is adequate for this discussion,. > 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. We completely agree with the 8402 meta-definition of SR domain (and I used it to answer your previous point). The confusion appears to arise purely from the terms "ingress SR domain" and "egress SR domain" which is our bad choice of words. "Site" would be a better word and I will scrub the document to use that. "Subdomain" seems to exacerbate the already-dubious word "domain." > 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...” Yeah, OK. > 2. Section 1 > > against connection of device failure. > > “Of” -> “or” Ack > 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? OK > 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? Indeed, just one (with potentially multiple tunnel encaps). We can make that explicit unless you can find a reason why advertising more than one would be beneficial. > 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”. "describes the whole path including those parts that are within the Egress Site" > 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”? Ouch! Yes, that slipped through. It's SIDs all the way down. > 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. Yes, this is the "When is a domain not a domain?" question. The answer is either "When it's a jar" or "We mean 'site'." > 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. I don't think we intended (or said) "BGP protocol mechanisms." But other protocol mechanisms *do* exist to protect BGP exchanges between peers. TLS or TCP-AO spring to mind. The point here, is that it is not the job of this document to solve BGP security issues. > 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.) Weeeeeeell, I think that that IDR work will need to provide adequate security. > 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? That is really what we intended you to wonder about. I suppose we are saying, "We are worried it might have an effect, but we can't put our finger on it." > 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? Agree with you that "stuff happens." I think that what you have described is a window not a permanent situation. When GW2 knows it can't reach X any more, it will stop advertising X, and GW1 will receive that and will update what it advertises on behalf of GW2. Further, if GW1 can no longer receive advertisements from GW2 then it will stop advertising on behalf of GW2. Cheers, Adrian _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
