Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-datacenter-gateway-11: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

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