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

[Adrian Farrel <[e-mail]>]

> 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