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> 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>> 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>>> 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
> >>>
> >      >
> >      >      > 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

Reply via email to