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

Reply via email to