Peter, I think you are still not clear on some deployment scenarios.
So allow me to restate ... It is pretty often (if not always) a valid requirement to redundantly connect your PEs over different physical paths to the P nodes in the area. For simplicity let's assume there are two links (it could be more then two which only makes the situation worse from perspective of UPA). One link belongs to telko A and is clean and solid BFD runs on it and can detect link/peer down in 10s or 100s of milliseconds. The other link is pretty bad (yet is used as backup as there is no physical alternative) and BFD timers on it are set to 2 sec probing x 3 = 6 sec detection of link/peer down. I think we all agree (including Aijun) that you MUST not advertise UPA before you receive all flooding from all adjacent to failed PE nodes - that in the above case may take 6 sec. So I was asking if you see it feasible to run multihop BFD from ABRs to PEs to detect node down much faster then long BFD timers would otherwise permit you to achieve. And it can be just say milliseconds slower then fastest BFD timers so effectively you get much faster detection then slowest BFD on links would expose. That's the real life scenario which I am trying to map to UPA (or in fact also DROID) mechanism. Many thx, Robert On Thu, Jul 7, 2022 at 2:03 PM Peter Psenak <ppse...@cisco.com> wrote: > 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 <ppse...@cisco.com > > <mailto:ppse...@cisco.com>> 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 <ppse...@cisco.com > > <mailto:ppse...@cisco.com> > > > <mailto:ppse...@cisco.com <mailto: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> > > > <mailto:ppse...@cisco.com <mailto:ppse...@cisco.com>> > > > > <mailto:ppse...@cisco.com <mailto:ppse...@cisco.com> > > <mailto: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>> > > > > <mailto:ppse...@cisco.com <mailto:ppse...@cisco.com> > > <mailto:ppse...@cisco.com <mailto:ppse...@cisco.com>>> > > > > > <mailto:ppse...@cisco.com > > <mailto:ppse...@cisco.com> <mailto:ppse...@cisco.com > > <mailto:ppse...@cisco.com>> > > > <mailto: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 > >>> > > > > > > > > > > > > > > < > 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
