Hi Robert,
On 03/01/2022 19:33, Robert Raszuk wrote:
Hi Peter,
Take SR-MPLS and RFC8667.
for MPLS summarization is practically not possible, we have been through
that.
Take RFC7810
TE metric is only advertised for links, not for prefixes.
Take RFC5120
I do not see any relevance to MTR. The summarization applies to any MT
in a same way as to MT-0.
literally anything which uses inter-area leaking today.
prefixes that are leaked between areas can be summarized. We are not
changing any of that.
thanks,
Peter
Thx,
R.
On Mon, Jan 3, 2022 at 6:18 PM Peter Psenak <[email protected]
<mailto:[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]>
> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>
> Chris,
>
> On 03/01/2022 17:18, Christian Hopps wrote:
> >
> > Peter Psenak <[email protected] <mailto:[email protected]>
<mailto:[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]>
> <mailto:[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]> <mailto:[email protected]
<mailto:[email protected]>>
> >>> https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
> <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
