Tony – I am not convinced we are going to converge. Note that my goal/expectation is not that one of us convinces the other as to what is “best”. It is simply to get a clearer understanding regarding our points of disagreement. But I am now less optimistic about that being achievable. Still, a few responses inline.
From: Tony Li <[email protected]> On Behalf Of Tony Li Sent: Monday, November 29, 2021 6:09 PM To: Les Ginsberg (ginsberg) <[email protected]> Cc: Hannes Gredler <[email protected]>; Aijun Wang <[email protected]>; Robert Raszuk <[email protected]>; lsr <[email protected]>; Shraddha Hegde <[email protected]>; Peter Psenak (ppsenak) <[email protected]> Subject: Re: [Lsr] BGP vs PUA/PULSE Les, Summarization is used in the network. But customer identifies a modest number of key nodes where it wants to detect loss of reachability ASAP. Unfortunately, customer is unable to assign addresses which are outside of the summary to these nodes. Customer assigns admin tags to the prefixes of interest and asks the IGP vendor to support advertising reachability to the tagged prefixes in addition to the summary (even though they are covered by summary). Are we still within the IGP set of responsibilities IYO? IMHO, no. You’re intentionally breaking summarization and advertising liveness. You can claim that it’s just reachability, but it’s not. If it were reachability, then you’d be ok with a static prefix assignment. [LES:] Your response mystifies me. I do not know how “static prefix assignment” is relevant. I wasn’t proposing “dynamic prefix assignment”. I was just trying to illustrate that prefixes covered by the summary could be advertised using existing IGP advertisements even when the summary is being advertised. It is still reachability. The determination of when to advertise the prefix and when not to is still based upon whether the ABR has a path to the prefix based on latest SPF calculation. You choose to rename such an advertisement as “liveness” rather than “reachability” for no reason that I can see. It then allows you claim an “architectural violation” – but this to me is a meaningless distraction. I was hoping to get rid of this distraction – but no such luck I see. Now, if the ABR so configured loses reachability to one of the tagged prefixes, what should it do? Clearly, it needs to stop advertising reachability for that prefix. No, it doesn’t. Static summarization is the preferred approach. It’s stable. [LES:] This wasn’t the point of the example. I wasn’t promoting the example as desirable deployment choice. I was only illustrating that it is the change in reachability(sic) that is the event. With current IGP advertisements we would (of course) stop advertising reachability when we do not have a path to a given prefix. The new advertisements propose to advertise the loss of reachability to destinations which are covered by a summary. That has advantages over a withdrawal (the absence of an advertisement). If you want to say that an operator should only have two choices: a)Advertise a summary or b)Advertise all reachable prefixes covered by a summary I understand your POV even if I do not agree with it. But please do not obfuscate things by claiming a reachability advertisement is now something else when it is triggered by the same event i.e., a change in the reachability to a given destination. You may recall back in the ‘90s that we did dynamic advertisement and withdrawl in BGP. That quickly got frowned on because of the resulting churn. No different here. What we propose is that if a customer wants to use summaries, they should feel free to do so. But if they want faster detection of loss of reachability to (some) destinations covered by the summary, there is a new advertisement which provides this which avoids the ambiguities mentioned above. Again, the IGP isn’t acquiring new information – it has always known this information – it just hasn’t had a way to advertise this in the presence of summaries. You’re propagating new information out of the area. And doing so at the wrong time. I would MUCH rather just leak the prefixes when things are working than add stress in failure modes. And, the use of tagging to identify the prefixes which may be advertised using the new mechanism is one way to deal with scale issues. How? If there are 10,000 tagged prefixes, how does that not become 10,000 negative leaks? [LES:] This is one of many possible tools to address scaling issues. (I have previously suggested others) Clearly this is only of benefit if, in a given deployment, the number of prefixes for which loss of reachability notifications is desired is modest and/or if used in conjunction w other tools. Please do not twist my words. Les Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
