Good point ! That proves that if PE-PE OAM does not follow app to app path it is useless. I would tend to agree.
That in fact even further highlights the benefits of using app to app network quality detection. When app has been exposed with more then one network path. Thx, R. On Mon, Jul 18, 2022 at 6:04 AM Aijun Wang <wangai...@tsinghua.org.cn> wrote: > Hi, Greg: > > > > As indicated in the update draft > https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10 > > > > The motivation behind this draft is for either MPLS LPM FEC binding, > > SRv6 etc. tunnel ,or BGP overlay service that are using LPM > > forwarding plane where the IGP domain has been carved up into OSPF > > areas or IS-IS levels and summarization is utilized. In such > > scenario, a link or node failure can result in a black hole of > > traffic when the summary advertisement that covers the failure > > prefixes still exists. > > > > PUAM can track the unreachability of the important component > > prefixes to ensure traffic is not black hole sink routed for the > > above overlay services. > > > > Then considering only the BFD sessions among PEs are not enough, even we > put aside the BFD sessions overhead on each PE. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* Greg Mirsky <gregimir...@gmail.com> > *Sent:* Monday, July 18, 2022 11:06 AM > *To:* Aijun Wang <wangai...@tsinghua.org.cn> > *Cc:* Robert Raszuk <rob...@raszuk.net>; Christian Hopps < > cho...@chopps.org>; Peter Psenak <ppse...@cisco.com>; lsr <lsr@ietf.org> > *Subject:* Re: [Lsr] UPA/PUA > > > > Hi Aijun, > > I cannot figure out how you draw such a conclusion from my comments to > Robert. You may recall that from very early in the discussion, I was not > enthusiastic, to put it lightly, about either of the solutions. Instead, I > believe that multi-hop BFD should be used to monitor the continuity of a > path PE-PE, not ABR/ASBR-PE as suggested by Robert. I hope I've made my > position clear. > > > > Regards, > > Greg > > > > On Sun, Jul 17, 2022 at 7:04 PM Aijun Wang <wangai...@tsinghua.org.cn> > wrote: > > Then considering both the scalability and possible false negative of BFD > based solution, can we say that the PUA/UPA solution is more preferable? > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* lsr-boun...@ietf.org <lsr-boun...@ietf.org> *On Behalf Of *Greg > Mirsky > *Sent:* Monday, July 18, 2022 8:39 AM > *To:* Robert Raszuk <rob...@raszuk.net> > *Cc:* Christian Hopps <cho...@chopps.org>; Peter Psenak <ppse...@cisco.com>; > lsr <lsr@ietf.org> > *Subject:* Re: [Lsr] UPA > > > > Hi Robert, > > top-posting and then my notes in-line under the GIM>> tag: > > 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. > > GIM>> I assume you refer to BFD single-hop. Then I have a question What do > you mean by "link is up"? If the link is Ethernet, p2p single-hop BFD in > the Down state may not indicate that the link is down but that the remote > peer is operating down. > > > > 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. > > GIM>> Not necessarily, depends on the implementation. I can imagine a > scenario, depending on the Detect Multiplier and Transmission Interval > values, when the BFD multi-hop session going down indicates that the > particular path to the remote PE lost continuity. > > > > And I repeat from the Abstract of RFC 5880: > > This document describes a protocol intended to detect faults in the > > bidirectional path between two forwarding engines, including > > interfaces, data link(s), and to the extent possible the forwarding > > engines themselves, with potentially very low latency. > > I believe that BFD cannot give us a reliable indication of the operational > state of a node that hosts the BFD session, applications, and protocols > hosted on that node. > > > > Regards, > > Greg > > > > > > On Sun, Jul 17, 2022 at 4:49 AM Robert Raszuk <rob...@raszuk.net> wrote: > > 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 > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
