I agree with Les on the comments related to BFD. I believe a lot of the false positive and / or negative issues are helped with BFD Strict mode.
Thanks Gyan On Sun, Jul 17, 2022 at 12:57 PM Les Ginsberg (ginsberg) <ginsberg= 40cisco....@dmarc.ietf.org> wrote: > Robert – > > > > I continue to be a bit unclear on the relevance of the points you are > making. > > And I do want to express my agreement with the points Peter and Chris have > made. > > > > In that vein, some top posted comments. > > > > You seem to be suggesting that multi-hop BFD could be more aggressive in > failure detection than single hop BFD in the presence of some link with > slow single hop BFD timers. > > This makes no sense to me. In order to avoid false failure reports, the > multi-hop BFD session has to allow for IGP FRR to occur, which means it > cannot be more aggressive than worst case link protection mechanisms for > the links which may be used to reach the multi-hop destination. > > > > You also seem to be concerned about headless Line Cards continuing to > maintain BFD sessions even after control plane failures. > > But this would affect multi-hop BFD as well as single hop BFD. > > And, I would argue, your issue is really with the vendor who ships such a > product which has a serious functionality gap. > > > > Finally, I am not certain you are saying this – but you seem to be saying > that BFD itself does not tell you whether the BFD client is fully sane. > This I agree with – but again it applies to Multi-hop BFD as well as single > hop BFD. > > > > Thanx. > > > > Les > > > > > > > > *From:* Lsr <lsr-boun...@ietf.org> *On Behalf Of * Robert Raszuk > *Sent:* Sunday, July 17, 2022 4:49 AM > *To:* Christian Hopps <cho...@chopps.org> > *Cc:* Peter Psenak (ppsenak) <ppse...@cisco.com>; lsr <lsr@ietf.org> > *Subject:* Re: [Lsr] UPA > > > > Hi Christian, > > > > > It seems you saying use multi-hop BFD for fast detection b/c you've gone > and configured one of those same hops along the > > > multi-hop path to an incredibly slow link-local BFD rate in comparison > to the BFD multi-hop rate. > > > > Yes. That is exactly the case. What is however missing in your picture is > that UPA is not only about signalling that all links to a node went down. > > > > UPA is also about signalling node down while links are still up - continue > responding to BFD in the line cards. > > > > See what we need here is not a signalling moment when all peers of PE see > all links to it going down. What is really needed is to signal when such PE > can not perform its service function any more. And that BFD to interfaces > will not tell you. > > > > > > > Why would you do that? In fact you're defeating a fundamental scaling > aspect of link-state protocols here. > > > > Since I have no physical alternative to use as backup other then crappy > carrier's backup link. > > > > > > > Now you have N multi-hop BFDs sessions (one per ABR) running over the > link instead of just *1* session running on that link. > > > > As mentioned it is still not the same. BFDs on the link tell me that link > is up and part of the line card responder to BFD is alive. > > > > Multihop BFD sessions will tell me that PE is up or down and that at least > one connection to it is still up. That is subtle but there is an important > difference. > > > > > > > If your (possible multiple sessions of) multi-hop BFD can be sent over > this "slow link" at fast rate X then why not do it just once using a link > local BFD session at the same rate instead? > > > > As described, BFD over a link is not the same as BFD to the node. > > > > > > And to project a bigger picture why I asked this ... > > > > If I would do the fast signalling of PE going down in BGP RRs would likely > have some form of detecting PE liveness anyway. Multihop BFD could be one > such option. So I was thinking > > if the same can be done with IGP detection wise. > > > > Note also that there are folks who do recommend PE to PE full mesh of BFD. > That orders of magnitude more BFD sessions then within an area. > > > > Many thx, > > R. > > > > > > > > > > On Sun, Jul 17, 2022 at 8:48 AM Christian Hopps <cho...@chopps.org> wrote: > > > Robert Raszuk <rob...@raszuk.net> writes: > > > 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. > > First, I don't like any of these unreachable things, and so I don't want > my comment to reflect in any way on them one way or the other. > > On a more fundamental level though, I don't see why Peter's answers are > not sufficient here. In particular, unless I am misunderstanding your > scenario it seems ... unrealistic -- but maybe I've missed something. > > It seems you saying use multi-hop BFD for fast detection b/c you've gone > and configured one of those same hops along the multi-hop path to an > incredibly slow link-local BFD rate in comparison to the BFD multi-hop > rate. Why would you do that? In fact you're defeating a fundamental scaling > aspect of link-state protocols here. Now you have N multi-hop BFDs sessions > (one per ABR) running over the link instead of just *1* session running on > that link. > > If your (possible multiple sessions of) multi-hop BFD can be sent over > this "slow link" at fast rate X then why not do it just once using a link > local BFD session at the same rate instead? > > If you configure the "down-detect" timer to a slow rate, then it'll be > slow detecting the link down. It's sort of tautological, right? > > Thanks, > Chris. > > > > > Cheers, > > R. > > > > > > On Thu, Jul 7, 2022 at 2:43 PM Peter Psenak <ppse...@cisco.com> > > 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 <ppse...@cisco.com > > > <mailto: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> > > > > <mailto: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 > > >> > > > > > <mailto: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>>> > > > > > > <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 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>>>> > > > > > > > <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 <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:// > <https://%0b>> 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:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> 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:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> 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:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> 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:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> 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:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https:// > <https://%0b>> www.ietf.org/id/ > > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https:// > <https://%0b>> 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 > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
