Because you do not want to destabilize link state protocol. Even in
the area.
You do not want to compute SPF immediately at each link flap.
But you do want to signal to remote guys a hint (remember UPA is a
hint not a solid state) that paths coming with this next hop should
be discouraged.
I think you and Les may be thinking of UPA as solid state PE
unreachable "pulse". For me however signalling issues (even if
transient) about local PE liveness is more important and has a
value.
Many thx,
R.
PS. In fact that mutlihop session between ABRs and local PEs could be
smart and fail when there are some issues with data and control plane
on the box outside of BFD path and BFD components. Obviously outside
of OSPF or ISIS as well. In other words link state get's signalled to
ABRs that some less specifics have fever and those ABRs in turn issue
a UPA or SPA (suspicious) messages to remote guys.
I am not seeing it as local area trigger must be IGP native even if
further flooding would be.
On Sun, Jul 17, 2022 at 11:18 PM Christian Hopps <cho...@chopps.org>
wrote:
I feel like this is so obvious that I must still be
misunderstanding you.
Why is it ok for N * multi-hop sessions to run over this
crappy-link at millisecond rates, but *not* ok for a single link
local session to do the same?
Thanks,
Chris.
Robert Raszuk <rob...@raszuk.net> writes:
> Hi Les,
>
>
>> You seem to be suggesting that multi-hop BFD could be more
> aggressive in failure detection than single hop BFD in
>
>> the presence of some link with slow single hop BFD timers.
>
>> This makes no sense to me. In order to avoid false failure
reports,
> the multi-hop BFD session has to allow for IGP FRR > to occur,
which
> means it cannot be more aggressive than worst case link
protection
> mechanisms for the links which
>
>> may be used to reach the multi-hop destination.
>
>
> Not quite.
>
> Your and Chris comment is correct when both links connecting
such PE
> would be having the same metric and would be equal class
citizens as
> far as IGP connectivity to PE.
>
> This is however not the case I am presenting.
>
> To illustrate further:
>
> Good link PE-P has BFD timbers 10 ms x 3 = 30 ms
> Bad link has timers 2 s x 3 = 6 sec detection.
>
> Good link is always preferred IGP wise.
>
> So when bad link fails and good link is ok - no false positive
is
> triggered.
>
> When good link fails multihop session must be just slower then
this
> link so it's timers would be 20 ms x 3 = 60 ms.
>
> When bad link remains the only one active multihop will detect
the PE
> down 100 times faster !
>
>> But this would affect multi-hop BFD as well as single hop BFD.
>
> Not if multihop BFD is going to RP/RE. Perhaps some vendors can
> handle it on LCs.
>
>> And, I would argue, your issue is really with the vendor who
ships
> such a product which
>> has a serious functionality gap.
>
> I would not be that fast. PEs today are compute nodes and I am
yet to
> see distributed BFD supported on the NICs.
>
> Many thx !
> Robert
>
>
>
> On Sun, Jul 17, 2022 at 6:57 PM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
>
> Robert –
>
>
>
> I continue to be a bit unclear on the relevance of the
points you
> are making.
>
> And I do want to express my agreement with the points Peter
and
> Chris have made.
>
>
>
> In that vein, some top posted comments.
>
>
>
> You seem to be suggesting that multi-hop BFD could be more
> aggressive in failure detection than single hop BFD in the
> presence of some link with slow single hop BFD timers.
>
> This makes no sense to me. In order to avoid false failure
> reports, the multi-hop BFD session has to allow for IGP FRR
to
> occur, which means it cannot be more aggressive than worst
case
> link protection mechanisms for the links which may be used
to
> reach the multi-hop destination.
>
>
>
> You also seem to be concerned about headless Line Cards
> continuing to maintain BFD sessions even after control
plane
> failures.
>
> But this would affect multi-hop BFD as well as single hop
BFD.
>
> And, I would argue, your issue is really with the vendor
who
> ships such a product which has a serious functionality gap.
>
>
>
> Finally, I am not certain you are saying this – but you
seem to
> be saying that BFD itself does not tell you whether the BFD
> client is fully sane. This I agree with – but again it
applies to
> Multi-hop BFD as well as single hop BFD.
>
>
>
> Thanx.
>
>
>
> Les
>
>
>
>
>
>
>
> From: Lsr <lsr-boun...@ietf.org> On Behalf Of Robert Raszuk
> Sent: Sunday, July 17, 2022 4:49 AM
> To: Christian Hopps <cho...@chopps.org>
> Cc: Peter Psenak (ppsenak) <ppse...@cisco.com>; lsr <
lsr@ietf.org
> >
> Subject: Re: [Lsr] UPA
>
>
>
> Hi Christian,
>
>
>
> > It seems you saying use multi-hop BFD for fast detection
b/c
> you've gone and configured one of those same hops along
the
>
> > multi-hop path to an incredibly slow link-local BFD rate
in
> comparison to the BFD multi-hop rate.
>
>
>
> Yes. That is exactly the case. What is however missing in
your
> picture is that UPA is not only about signalling that all
links
> to a node went down.
>
>
>
> UPA is also about signalling node down while links are
still up -
> continue responding to BFD in the line cards.
>
>
>
> See what we need here is not a signalling moment when all
peers
> of PE see all links to it going down. What is really needed
is to
> signal when such PE can not perform its service function
any
> more. And that BFD to interfaces will not tell you.
>
>
>
>
>
> > Why would you do that? In fact you're defeating a
fundamental
> scaling aspect of link-state protocols here.
>
>
>
> Since I have no physical alternative to use as backup other
then
> crappy carrier's backup link.
>
>
>
>
>
> > Now you have N multi-hop BFDs sessions (one per ABR)
running
> over the link instead of just *1* session running on that
link.
>
>
>
> As mentioned it is still not the same. BFDs on the link
tell me
> that link is up and part of the line card responder to BFD
is
> alive.
>
>
>
> Multihop BFD sessions will tell me that PE is up or down
and that
> at least one connection to it is still up. That is subtle
but
> there is an important difference.
>
>
>
>
>
> > If your (possible multiple sessions of) multi-hop BFD can
be
> sent over this "slow link" at fast rate X then why not do
it just
> once using a link local BFD session at the same rate
instead?
>
>
>
> As described, BFD over a link is not the same as BFD to the
> node.
>
>
>
>
>
> And to project a bigger picture why I asked this ...
>
>
>
> If I would do the fast signalling of PE going down in BGP
RRs
> would likely have some form of detecting PE liveness
anyway.
> Multihop BFD could be one such option. So I was thinking
>
> if the same can be done with IGP detection wise.
>
>
>
> Note also that there are folks who do recommend PE to PE
full
> mesh of BFD. That orders of magnitude more BFD sessions
then
> within an area.
>
>
>
> Many thx,
>
> R.
>
>
>
>
>
>
>
>
>
> On Sun, Jul 17, 2022 at 8:48 AM Christian Hopps <
> cho...@chopps.org> wrote:
>
>
> Robert Raszuk <rob...@raszuk.net> writes:
>
> > Peter,
> >
> > In the scenario described there is really nothing to
be
> tuned as you
> > are limited by the quality of local telco carriers.
> >
> > Apparently you are not willing to consider it. Thank
you.
>
> First, I don't like any of these unreachable things,
and so I
> don't want my comment to reflect in any way on them one
way
> or the other.
>
> On a more fundamental level though, I don't see why
Peter's
> answers are not sufficient here. In particular, unless
I am
> misunderstanding your scenario it seems ... unrealistic
--
> but maybe I've missed something.
>
> It seems you saying use multi-hop BFD for fast
detection b/c
> you've gone and configured one of those same hops along
the
> multi-hop path to an incredibly slow link-local BFD
rate in
> comparison to the BFD multi-hop rate. Why would you do
that?
> In fact you're defeating a fundamental scaling aspect
of
> link-state protocols here. Now you have N multi-hop
BFDs
> sessions (one per ABR) running over the link instead of
just
> *1* session running on that link.
>
> If your (possible multiple sessions of) multi-hop BFD
can be
> sent over this "slow link" at fast rate X then why not
do it
> just once using a link local BFD session at the same
rate
> instead?
>
> If you configure the "down-detect" timer to a slow
rate, then
> it'll be slow detecting the link down. It's sort of
> tautological, right?
>
> Thanks,
> Chris.
>
> >
> > Cheers,
> > R.
> >
> >
> > On Thu, Jul 7, 2022 at 2:43 PM Peter Psenak <
> ppse...@cisco.com>
> > wrote:
> >
> > Robert,
> >
> > people know how to tune IGPs for faster
convergence.
> They may or
> > may do,
> > it's their decision based on their requirements.
BFD is
> a
> > standard
> > mechanism used by IGPs for fast detection of the
> adjacency loss.
> > I see
> > no reason to require anything more or special for
the
> UPA.
> >
> > thanks,
> > Peter
> >
> > On 07/07/2022 14:28, Robert Raszuk wrote:
> > > Peter,
> > >
> > > I think you are still not clear on some
deployment
> scenarios.
> > >
> > > So allow me to restate ...
> > >
> > > It is pretty often (if not always) a valid
> requirement to
> > redundantly
> > > connect your PEs over different physical paths
to the
> P nodes
> > in the area.
> > >
> > > For simplicity let's assume there are two links
(it
> could be
> > more then
> > > two which only makes the situation worse from
> perspective of
> > UPA).
> > >
> > > One link belongs to telko A and is clean and
solid
> BFD runs on
> > it and
> > > can detect link/peer down in 10s or 100s of
> milliseconds. The
> > other link
> > > is pretty bad (yet is used as backup as there
is no
> physical
> > > alternative) and BFD timers on it are set to 2
sec
> probing x 3
> > = 6 sec
> > > detection of link/peer down.
> > >
> > > I think we all agree (including Aijun) that you
MUST
> not
> > advertise UPA
> > > before you receive all flooding from all
adjacent to
> failed PE
> > nodes -
> > > that in the above case may take 6 sec.
> > >
> > > So I was asking if you see it feasible to run
> multihop BFD from
> > ABRs to
> > > PEs to detect node down much faster then long
BFD
> timers would
> > otherwise
> > > permit you to achieve.
> > >
> > > And it can be just say milliseconds slower then
> fastest BFD
> > timers so
> > > effectively you get much faster detection then
> slowest BFD on
> > links
> > > would expose.
> > >
> > > That's the real life scenario which I am trying
to
> map to UPA
> > (or in
> > > fact also DROID) mechanism.
> > >
> > > Many thx,
> > > Robert
> > >
> > >
> > > On Thu, Jul 7, 2022 at 2:03 PM Peter Psenak <
> ppse...@cisco.com
> > > <mailto:ppse...@cisco.com>> wrote:
> > >
> > > On 07/07/2022 12:26, Robert Raszuk wrote:
> > > > That's true.
> > > >
> > > > I am pointing out that this in some
networks
> may be much
> > slower then
> > > > invalidating the next hops from BGP
route
> reflectors by
> > running
> > > *local*
> > > > multihop BFD sessions to subject PEs
(all
> within an
> > area).
> > > >
> > > > So I have a question ... Let's forget
about
> BGP and RRs
> > and just
> > > stay
> > > > focused on IGP:
> > > >
> > > > Would it be feasible to trigger UPA on
ABRs by
> running
> > multihop BFD
> > > > sessions between ABRs and local area PEs
and
> not wait
> > for PE-P
> > > detection
> > > > of link down as well as flooding to
carry the
> > information to ABRs ?
> > >
> > > I would think running BFD on each
individual link
> in the
> > local area
> > > would be a much better solution. And people
> already often
> > do that.
> > >
> > > thanks,
> > > Peter
> > >
> > > >
> > > > Thx,
> > > > R.
> > > >
> > > >
> > > > On Thu, Jul 7, 2022 at 12:18 PM Peter
Psenak <
> > ppse...@cisco.com
> > > <mailto:ppse...@cisco.com>
> > > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com>>>
> > wrote:
> > > >
> > > > Robert,
> > > >
> > > > BGP PIC depends on the IGP
convergence. We
> are not
> > changing
> > > any of that
> > > > by UPA.
> > > >
> > > > thanks,
> > > > Peter
> > > >
> > > >
> > > > On 07/07/2022 12:02, Robert Raszuk
wrote:
> > > > > Peter,
> > > > >
> > > > > All I am saying is that this may
be
> pretty slow
> > if even
> > > directly
> > > > > attached P routers must way say 6
> seconds (3 x 2
> > sec BFD)
> > > to declare
> > > > > peer down.
> > > > >
> > > > > And that is in contrast to
running BFD
> from say
> > BGP RR to
> > > all PEs
> > > > in an
> > > > > area.
> > > > >
> > > > > The fundamental point is that in
the
> case of PUA
> > you MUST wait
> > > > for all P
> > > > > routers to tell you that PE in
fact
> went down.
> > While in
> > > case of
> > > > > invalidating service routes the
first
> trigger is
> > good enough.
> > > > >
> > > > > To me this is
significant architectural
> > difference.
> > > > >
> > > > > Many thx,
> > > > > R.
> > > > >
> > > > >
> > > > > On Thu, Jul 7, 2022 at 11:54 AM
Peter
> Psenak
> > > <ppse...@cisco.com <mailto:
ppse...@cisco.com>
> > > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com
> > >>
> > > > > <mailto:ppse...@cisco.com
<mailto:
> > ppse...@cisco.com>
> > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com>>>>
> > wrote:
> > > > >
> > > > > On 07/07/2022 11:38, Robert
Raszuk
> wrote:
> > > > > >
> > > > > > > there is no such thing.
> > > > > >
> > > > > > By far away ABR I mean ABR
far
> away from
> > failing PE
> > > > connecting local
> > > > > > are to the area 0. There
can be
> number of
> > P routers in
> > > > between.
> > > > >
> > > > > ABR has the full visibility
of the
> local area
> > and
> > > knows when any
> > > > > node or
> > > > > prefix becomes unreachable.
It is
> determined
> > by the SPF
> > > > computation and
> > > > > prefix processing that is
triggered
> as a
> > result of the
> > > change
> > > > in the
> > > > > local area.
> > > > >
> > > > > thanks,
> > > > > Peter
> > > > >
> > > > > >
> > > > > > Let me provide you with an
> illustration:
> > > > > >
> > > > > > PE can be in Honolulu. ABR
in
> Huston. All
> > in one
> > > area. For me
> > > > > this ABR
> > > > > > is far away from PE.
> > > > > >
> > > > > > On Thu, Jul 7, 2022 at
11:35 AM
> Peter
> > Psenak
> > > > <ppse...@cisco.com <mailto:
> ppse...@cisco.com>
> > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com>>
> > > > > <mailto:ppse...@cisco.com
<mailto:
> > ppse...@cisco.com>
> > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com>>>
> > > > > > <mailto:ppse...@cisco.com
> > > <mailto:ppse...@cisco.com> <mailto:
> ppse...@cisco.com
> > > <mailto:ppse...@cisco.com>>
> > > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com>
> > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com>>>>>
> > wrote:
> > > > > >
> > > > > > Robert,
> > > > > >
> > > > > > On 07/07/2022 11:25,
Robert
> Raszuk
> > wrote:
> > > > > > > Hi Peter,
> > > > > > >
> > > > > > > > Section 4:
> > > > > > > >
> > > > > > > > "The intent of
UPA is
> to provide
> > an event
> > > driven
> > > > signal
> > > > > of the
> > > > > > > > transition of a
> destination
> > from
> > > reachable to
> > > > > unreachable."
> > > > > > >
> > > > > > > That is too vague.
> > > > > >
> > > > > > it's all that is
needed.
> > > > > >
> > > > > > >
> > > > > > > I am asking how you
> detect that
> > transition on a
> > > > far away ABR.
> > > > > >
> > > > > > there is no such
thing. The
> detection
> > is done
> > > based on
> > > > the prefix
> > > > > > transition from
reachable to
> > unreachabile in a
> > > local
> > > > area by
> > > > > local
> > > > > > ABRs.
> > > > > > Remote ABRs just
propagate
> the UPA.
> > > > > >
> > > > > > thanks,
> > > > > > Peter
> > > > > >
> > > > > > >
> > > > > > > For example, are
you
> tracking
> > flooding on
> > > all links to
> > > > > subject PE
> > > > > > from
> > > > > > > all its
neighbours and
> only when
> > all of them
> > > remove
> > > > that
> > > > > link from
> > > > > > > topology you signal
PUA ?
> > > > > > >
> > > > > > > If so practically
such
> trigger may
> > be pretty
> > > slow and
> > > > > > inconsistent as in
> > > > > > > real networks as
links
> over which
> > PEs are
> > > connected are
> > > > > often of a
> > > > > > > very different
quality,
> coming from
> > different
> > > > carriers and may
> > > > > > have for
> > > > > > > stability varying
BFD
> timers. So
> > here you
> > > would have to
> > > > > wait for the
> > > > > > > slowest link to be
> detected on the
> > > neighbouring P
> > > > router
> > > > > as down.
> > > > > > >
> > > > > > > Thx,
> > > > > > > R.
> > > > > > >
> > > > > > > On Thu, Jul 7, 2022
at
> 10:16 AM
> > Peter Psenak
> > > > > <ppse...@cisco.com <mailto:
> ppse...@cisco.com>
> > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com>>
> > > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com>
> > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com>>>
> > > > > > <mailto:
ppse...@cisco.com
> > > <mailto:ppse...@cisco.com> <mailto:
> ppse...@cisco.com
> > > <mailto:ppse...@cisco.com>>
> > > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com>
> > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com>>>>
> > > > > > > <mailto:
ppse...@cisco.com
> > > <mailto:ppse...@cisco.com>
> > > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com
> > >>
> > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com>
> > > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com
> > >>>
> > > > > <mailto:ppse...@cisco.com
<mailto:
> > ppse...@cisco.com>
> > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com>>
> > > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com>
> > > <mailto:ppse...@cisco.com <mailto:
> ppse...@cisco.com>>>>>>
> > wrote:
> > > > > > >
> > > > > > > Robert,
> > > > > > >
> > > > > > > On 06/07/2022
15:07,
> Robert
> > Raszuk wrote:
> > > > > > > > Hi Peter,
> > > > > > > >
> > > > > > > > Can you
please
> point me in
> > the draft
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > https://www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt
> > > <https://www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>
> > > >
> > > <https://www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>
> > > > >
> > > >
> > > <https://www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>
> > > > > >
> > > > >
> > > >
> > > <https://www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > <https://www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>
> <https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
>
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>>>
> > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > <https://www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>
> <https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > <https://www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>
> <https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <
> https://
> > www.ietf.org/id/
> >
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <
> https://
> > www.ietf.org/id/
> >
>
draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>>>>
> > > > > > >
> > > > > > > > to some
section
> which
> > specifies based
> > > on exactly
> > > > > what network
> > > > > > > flooding
> > > > > > > > changes UPA
will
> be
> > generated by ABRs ?
> > > > > > >
> > > > > > > Section 4:
> > > > > > >
> > > > > > > "The intent of
UPA is
> to
> > provide an
> > > event driven
> > > > > signal of the
> > > > > > > transition
of a
> destination
> > from
> > > reachable to
> > > > > unreachable."
> > > > > > > >
> > > > > > > > I think such
text
> is not an
> > > implementation
> > > > detail,
> > > > > but it is
> > > > > > > critical
> > > > > > > > for mix
vendor
> > interoperability.
> > > > > > > >
> > > > > > > > Can UPA also
be
> generated by
> > P node(s) ?
> > > > > > >
> > > > > > > only if they
are ABRs
> or ASBRs.
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Specifically
I was
> looking
> > to find some
> > > > information on
> > > > > > how do you
> > > > > > > >
> achieve assurance that UPA
> > really
> > > needs to
> > > > be generated
> > > > > > when using
> > > > > > > > various
vendor's
> nodes with
> > very
> > > different
> > > > flooding
> > > > > behaviours
> > > > > > > and when
> > > > > > > > subjects PEs
may
> have a
> > number of
> > > different
> > > > links
> > > > > each with
> > > > > > > different
> > > > > > > > node/link
down
> detection
> > timer ?
> > > > > > >
> > > > > > > sorry, I don't
> understand the
> > above.
> > > > > > >
> > > > > > > thanks,
> > > > > > > Peter
> > > > > > >
> > > > > > > >
> > > > > > > > Many thx,
> > > > > > > > R.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> >
> > _______________________________________________
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
