Having re-read Section 3 carefully (and skimmed the rest) I still think what the document says (as opposed to what’s in the authors’ heads?) is the first description I give below. Let me know if you want me to walk through my reasoning in detail with reference to the document.
—John On May 14, 2021, at 4:12 PM, John Scudder <j...@juniper.net> wrote: Hi Adrian, Thanks for your reply. Pressed for time at the moment but one partial response: On May 14, 2021, at 1:04 PM, Adrian Farrel <adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote: 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. Ah, perhaps I have badly misunderstood the way this works. I had thought it went something like this: - GW1 knows it can reach GW2 because of GW2’s auto discovery route - GW1 knows the set S of internal prefixes it can reach - GW1 advertises each prefix from S with both GW1 and GW2 in the tunnel attribute In the description above, there’s no notion of GW2 telling GW1 what internal prefixes GW2 can reach, or GW1 caring. Now I suppose you are telling me that it goes: - GW1 knows it can reach GW2 because of GW2’s auto discovery route - GW1 knows the full set of prefixes GW2 can reach. _How does it know this?_ - GW1 constructs each advertisement listing only the correct set of gateways in the tunnel attribute The key question is the one I’ve highlighted: how does GW1 come to know GW2’s internally-reachable prefixes? I didn’t notice any of this in the spec. Maybe it was just my sloppy reading, I’ll look again. Further, if GW1 can no longer receive advertisements from GW2 then it will stop advertising on behalf of GW2. Yes, that’s understood, but I was positing a case where just because GW1 can reach GW2 stably, and just because GW1 can reach X stably, it does not imply GW2 can reach X. —John
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
