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. I am asking how you detect that transition on a far away ABR. 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> 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> > > > 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
