Peter, > We want network to be summarized all times
Please - can you answer my question which was already stated at least twice ? How can you summarize PE addresses if outside of reachability they advertise and leak across areas lots of other important information in an opaque to the IGP meaning ? What other transport those opaque gen-art /gen-app information will take once you summarize the reachability and stop inter-area leaking ? Many thx, R. On Mon, Jan 3, 2022 at 5:56 PM Peter Psenak <[email protected]> wrote: > Chris, > > On 03/01/2022 17:18, Christian Hopps wrote: > > > > 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) <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 .... > > > typically you want to summarize all prefixes inside the area when > advertising outside the area. And you want to know about some of these > prefixes when they are lost to help convergence. > > > > > >> 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. > > In 99,99% of cases there will be only single pulse generated when one PE > goes down. That itself is a very rare event itself. > > We can easily limit the number of pulses generated on ABR to a single > digit number to cover the unlikely case of many PEs in area becoming > unreachable at the same time. > > > > > > If a failing network can handle the extra state, then a functioning > stable network of course can too. > > no, that's not what we claim. We want network to be summarized all times > and generate limited number of pulses at any given time to help the > network converge fast in case where single (or very few) PEs in an area > go down. > > thanks, > Peter > > > > > > > Thanks, > > Chris. > > > >> > >> thanks, > >> Peter > >> > >> > >>> One 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 > >>> > > > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
