On Jan 5, 2022, at 03:56, Greg Mirsky <[email protected]
<mailto:[email protected]>> wrote:
Hi Peter,
thank you for your response. I'm looking forward to the new
version of the draft. It will be interesting to learn the criteria
that enable an ABR to reliably identify the scenarios you've
suggested are outside the scope of the PULSE draft and should be
handled differently.
Regards,
Greg
On Tue, Jan 4, 2022 at 10:08 AM Peter Psenak <[email protected]
<mailto:[email protected]>> wrote:
Hi Greg,
On 04/01/2022 18:13, Greg Mirsky wrote:
> Hi Peter,
> I'm probably missing something in the current PULSE but I
cannot find
> the mechanism that limits the number of the pulses. Do you
envision that
> being like a throttling mechanism? But delaying the
propagation of
> notification for some events might cause more instability in
a network.
no. It's a limit not a delay. If too many edge nodes loose
connectivity
to the ABR in its area, it's a result of the severe event like
area
partition or loss of area connectivity from ABR. These are not
types of
events that we are trying to address with pulses.
The limit is not described in the published version of the draft.
We are working on the updated version that will include the
description
of it.
thanks,
Peter
>
> Regards,
> Greg
>
> On Tue, Jan 4, 2022 at 1:52 AM Peter Psenak
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>
> Hi Greg,
>
> On 03/01/2022 23:17, Greg Mirsky wrote:
> > Happy New Year to All!
> >
> > Hi Peter,
> > Top-pasting:
> > 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.
> >
> > I think that it is possible for the summarizing ABR
to get
> disconnected
> > from the IGP area in such a way that the
summarization is still
> valid.
> > If such a case is valid, would the ABR generate PULSE
for each
> > disconnected PE?
>
> obviously not. That's why I mentioned the number of
pulses will be
> limited on every ABR.
>
> thanks,
> Peter
>
> >
> > Regards,
> > Greg
> >
> > On Mon, Jan 3, 2022 at 8:56 AM Peter Psenak
> > <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[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]>>
> <mailto:[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]>>
> > <mailto:[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]>>
<mailto:[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>>
> > <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] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
<mailto:[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>>
> > <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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
<https://www.ietf.org/mailman/listinfo/lsr>
