Hi Peter, Take SR-MPLS and RFC8667.
Take RFC7810 Take RFC5120 literally anything which uses inter-area leaking today. Thx, R. On Mon, Jan 3, 2022 at 6:18 PM Peter Psenak <[email protected]> wrote: > Robert, > > On 03/01/2022 18:04, Robert Raszuk wrote: > > 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 ? > > like what? > > thanks, > Peter > > > > > > 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] > > <mailto:[email protected]>> wrote: > > > > Chris, > > > > On 03/01/2022 17:18, Christian Hopps wrote: > > > > > > Peter Psenak <[email protected] <mailto:[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] > > <mailto:[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] <mailto:[email protected]> > > >>> https://www.ietf.org/mailman/listinfo/lsr > > <https://www.ietf.org/mailman/listinfo/lsr> > > >>> > > > > > > > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
