On Thu, Jul 22, 2021 at 07:12:50PM +0100, Adrian Farrel wrote: > > Picking up (belatedly) where I left off in my initial reply... > > Thanks, Ben. > > >>> Section 5 > >>> > >>> for a prefix X, then each GW computes an SR TE path through that site > >>> to X from each of the currently active GWs, and places each in an > >>> MPLS label stack sub-TLV [RFC9012] in the SR Tunnel TLV for that GW. > >>> > >>> I don't think I understand why each (egress) GW has to (re)compute > >>> the path through the site to X for each of the GWs at the site -- can't > >>> it just take the sub-TLV it got from the peer and re-propagate it? > >> > >> Oh, it doesn't have to recompute it *if* it is present (i.e. if it got it > >> from > >> the peer). But that part of the path might not be present (that is, the > >> sub-TLV might not be present) because: > >> a. the ingress might not have visibility into the egress site beyond > >> simple > >> reachability > >> b. the ingress might not care > >> c. the ingress might want to let the egress site make subtle reactive > >> choices according to local conditions > >> IMHO it would be unusual for the tail end of the path to be specified in > >> this way. > > > > (Disclaimer: this is not an important topic and I'm happy to drop it for > > expediency if desired.) I am not sure that my point came across as > > intended. The text here seems to be about what the egress GW does when it > > advertises the "union of all tunnel encapsulation information" route > > externally. My understanding/expectation was that each egress GW would be > > able to just take the bits it got from auto-discovery (internal) routes and > > squish them together. As you note, the ingress may not care or need the > > details of the path within the egress site from GW to prefix X, and so I > > don't understand why the advertising egress GW would go to the trouble of > > computing a route from the other GWs in its site to prefix X. If such a > > route was needed, the other GW in the site would be better placed to > > compute such a route and include it in the auto-discovery route anyway. > > I think you may have misunderstood Section 5.
It seems like I did, yes. Sorry about that. > Firstly, the case you are looking at is behind a cascaded "if". > But also, it doesn't say that each GW computes paths from each other gateway > to the destination. It only says that each GW computes a path from itself to > the destination. Each GW then encodes that path as MPLS SID stack, puts it in > an MPLS label stack sub-TLV inside the SR tunnel TLV. And, of course, that > means that when a GW advertises the reachability on behalf of the other GWs > to the site, it will pick up those routes and advertise them as well. (This, of course, matches up with the behavior I expected.) > >>> Section 6 > >>> > >>> [The topic of which sites are allowed to send in the site's native > >>> encapsulation seems > >>> related to questions of what an "SR Domain" is and what boundary security > >>> it has. I > >>> think that the other ADs are basically covering this topic, though, so am > >>> not sure there > >>> is much more to say here.] > >>> > >>> If the GWs for a given site are configured to allow remote GWs to > >>> send them a packet in that site's native encapsulation, then each GW > >>> will also include multiple instances of a Tunnel TLV for that native > >>> encapsulation in externally advertised routes: one for each GW and > >>> each containing a Tunnel Egress Endpoint sub-TLV with that GW's > >>> address. [...] > >>> > >>> Does this implicitly require that all the GWs of the site have the same > >>> configuration > >>> for whether or not to allow native encapsulation from remote GWs? How > >>> would > >>> things degrade if a mixed configuration did happen to occur? > >> > >> This applies GW by GW since the tunnels lead to a GW, and the path has > >> selected the tunnels. So, the sender knows. > >> > >> If a gateway is configured to not allow native encapsulation, then it will > >> receive packets in some other encapsulation that it does understand, > >> and it will convert them to the site's native encapsulation. > >> > >> Note that the GW is part of the site, so it really (really) needs to > >> understand the native encapsulation in the site! > >> > >> Note also that (of course?) a GW that receives packets in an > >> encapsulation it doesn't understand (and hasn't advertised that it > >> understands) will drop the packets (just like any other data plane > >> node will discard packets with an unknown encapsulation). > >> > >> Well, there is a case where a GW advertises that it understands > >> an encapsulation, but actually doesn't understand it. That is at > >> best a bug, and at worst a purchasing error. > > > > Okay. So if there is an issue here at all (not entirely clear) it's just > > an editorial one about "the GWs for a given site" vs "any GWs for a given > > site", and "each GW" vs "each such GW" (or similar). > > I'm pretty sure that the text is clear enough here. > I suppose it is the site that is configured, and all gateways act the same > way. > So we could have > If a site is configured to allow remote GWs send packets to the site in > the site's native encapsulation, then each GW to the site will also > include multiple instances of a Tunnel TLV for that native encapsulation > in externally advertised routes: one for each GW and each containing a > Tunnel Egress Endpoint sub-TLV with that GW's address. [...] > > I'll make that change if you think it is important. I don't think it's important to make the change, though I do think the change is an improvement. Thanks, Ben _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
