Peter Psenak <[email protected]> writes:
On 03/01/2022 16:21, Christian Hopps wrote:On Nov 29, 2021, at 7:39 PM, Les Ginsberg (ginsberg) <[email protected]> wrote: Tony – Let me try one example – see if it helps. 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.I think this does in fact capture the problem trying to be solved here, nicely.not really. In fact assigning addresses to the nodes in a way that they are part of the summary is the right thing to do.
No, not if you want more detailed information about specific reachability it's not. And ....
The problem we are trying to solve is to use the summarization but without the loss of the fast notification of the node down event.
You want more specific information about reachability, but you just want to do it when the network is stressed and undergoing change. So the "works now" way of not summarizing these important prefixes has the state in the network when it's working, so you know adding and removing it is something the network is already capable of handling. New signaling that *only* is created when things start failing, tests the infrastructure at exactly the wrong time. If a failing network can handle the extra state, then a functioning stable network of course can too. Thanks, Chris.
thanks, PeterOne solution very simple solution that works today is: - Tell the customer they can't do this, but they *can* modify their addressing (this is literally what they do for a living) so that they don't have this problem. Do we *really* want modify our IGPs (a BIG ask) with some pretty questionable changes, just to save the operators the trouble of doing their job correctly? Maybe the answer here is this isn't a good idea, and we should move on... Thanks, Chris. [as wg member] _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
signature.asc
Description: PGP signature
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
