Peter, In the scenario described there is really nothing to be tuned as you are limited by the quality of local telco carriers.
Apparently you are not willing to consider it. Thank you. Cheers, R. On Thu, Jul 7, 2022 at 2:43 PM Peter Psenak <[email protected]> wrote: > Robert, > > people know how to tune IGPs for faster convergence. They may or may do, > it's their decision based on their requirements. BFD is a standard > mechanism used by IGPs for fast detection of the adjacency loss. I see > no reason to require anything more or special for the UPA. > > thanks, > Peter > > On 07/07/2022 14:28, Robert Raszuk wrote: > > 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 <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]> > > > <mailto:[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]>> > > > > <mailto:[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]>>> > > > > > <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 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]>>>> > > > > > > <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] <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 > >>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > < > 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
