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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>
> <mailto:[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]>>
> > <mailto:[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]>>>
> > > <mailto:[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>>>>
> > >
> > > >
> > >
> >
>
<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
