> 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. 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. >>> 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. Cheers, Adrian _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
