Because you do not want to destabilize link state protocol. Even in the area.
You do not want to compute SPF immediately at each link flap. But you do want to signal to remote guys a hint (remember UPA is a hint not a solid state) that paths coming with this next hop should be discouraged. I think you and Les may be thinking of UPA as solid state PE unreachable "pulse". For me however signalling issues (even if transient) about local PE liveness is more important and has a value. Many thx, R. PS. In fact that mutlihop session between ABRs and local PEs could be smart and fail when there are some issues with data and control plane on the box outside of BFD path and BFD components. Obviously outside of OSPF or ISIS as well. In other words link state get's signalled to ABRs that some less specifics have fever and those ABRs in turn issue a UPA or SPA (suspicious) messages to remote guys. I am not seeing it as local area trigger must be IGP native even if further flooding would be. On Sun, Jul 17, 2022 at 11:18 PM Christian Hopps <[email protected]> wrote: > > I feel like this is so obvious that I must still be misunderstanding you. > > Why is it ok for N * multi-hop sessions to run over this crappy-link at > millisecond rates, but *not* ok for a single link local session to do the > same? > > Thanks, > Chris. > > Robert Raszuk <[email protected]> writes: > > > Hi Les, > > > > > >> 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. > > > > > > Not quite. > > > > Your and Chris comment is correct when both links connecting such PE > > would be having the same metric and would be equal class citizens as > > far as IGP connectivity to PE. > > > > This is however not the case I am presenting. > > > > To illustrate further: > > > > Good link PE-P has BFD timbers 10 ms x 3 = 30 ms > > Bad link has timers 2 s x 3 = 6 sec detection. > > > > Good link is always preferred IGP wise. > > > > So when bad link fails and good link is ok - no false positive is > > triggered. > > > > When good link fails multihop session must be just slower then this > > link so it's timers would be 20 ms x 3 = 60 ms. > > > > When bad link remains the only one active multihop will detect the PE > > down 100 times faster ! > > > >> But this would affect multi-hop BFD as well as single hop BFD. > > > > Not if multihop BFD is going to RP/RE. Perhaps some vendors can > > handle it on LCs. > > > >> And, I would argue, your issue is really with the vendor who ships > > such a product which > >> has a serious functionality gap. > > > > I would not be that fast. PEs today are compute nodes and I am yet to > > see distributed BFD supported on the NICs. > > > > Many thx ! > > Robert > > > > > > > > On Sun, Jul 17, 2022 at 6:57 PM Les Ginsberg (ginsberg) < > > [email protected]> 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 <[email protected]> On Behalf Of Robert Raszuk > > Sent: Sunday, July 17, 2022 4:49 AM > > To: Christian Hopps <[email protected]> > > Cc: Peter Psenak (ppsenak) <[email protected]>; lsr <[email protected] > > > > > 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 < > > [email protected]> wrote: > > > > > > Robert Raszuk <[email protected]> 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 < > > [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 > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
