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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> 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
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> 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>>>>
> >
> > > 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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
