Hi, Robert: Aijun Wang China Telecom
> On Jul 31, 2020, at 00:23, Robert Raszuk <rob...@raszuk.net> wrote: > > > Hi, > > Imagine I have two ABRs connecting area 1 to area 0. One is signalling > transition to down for subset of summary and the other does not .. maybe it > is slow ... maybe it does not support this new feature. > > So all routers in the area 0 are receiving a full summary from one ABR and a > summary with hole from the other one. Should that be logical AND or OR ? [WAJ] It should be OR. All routers in the area 0 should prefer to the ABR that not advertising PUA to forward traffic. > > Then on the other side there is area 2. Should the transition to down be > leaked ? [WAJ] The PUA should be leaked. > If so in a nicely stable network we may see instead of few /20 summaries jump > to 1M transitions to down yet summary continues - would that not have a bit > negative effect on the entire network ? Where would ABR remove summary itself > - when all atomic routes subsumed by the summary transition to down ? [WAJ] https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-6 has described the extreme conditions for advertising PUA+Summary, Detail Reachable Prefixes only, or Summary Address with Max metric. Is there any other graceful advertising in these conditions? > > - - - > > I am supportive of the idea to signal unreachable network elements. But I am > not sure if we should do it in IGP and BGP or only in BGP. [WAJ] Such information is for underlay link state and should be flooded via IGP? The ambiguity arises from IGP summary behavior and should be solved by itself? > > Thx, > R. > > >> On Thu, Jul 30, 2020 at 6:08 PM Huzhibo <huzh...@huawei.com> wrote: >> HI acee： >> >> PUA does not advertise reachable or unreachable details, it advertise events >> with prefix from up to down. >> >> >> >> thanks >> >> Zhibo >> >> >> >> >> >> >> >> -------------------------------------------------- >> 胡志波 Hu Zhibo >> Mobile: +86-18618192287 >> Email: huzh...@huawei.com >> >> 发件人：Acee Lindem (acee) <a...@cisco.com> >> 收件人：Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org>;Robert Raszuk >> <rob...@raszuk.net> >> 抄 送：Aijun Wang <wang...@chinatelecom.cn>;Xiaoyaqun >> <xiaoya...@huawei.com>;Huzhibo <huzh...@huawei.com>;Aijun Wang >> <wangai...@tsinghua.org.cn>;lsr <lsr@ietf.org> >> 时 间：2020-07-31 00:04:02 >> 主 题：Re: [Lsr] New Version Notification for >> draft-wang-lsr-prefix-unreachable-annoucement-03.txt >> >> So, how do we define a reachable route - is it any route subsumed by the >> summary LSA that we knew about in the past that becomes unreachable? When >> the PUA is withdrawn, how do we know whether it is because of expiration of >> the interval or the route becoming reachable again? This is a slippery >> slope. >> Thanks, >> Acee >> >> On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak" <lsr-boun...@ietf.org >> on behalf of ppsenak=40cisco....@dmarc.ietf.org> wrote: >> >> On 30/07/2020 16:30, Robert Raszuk wrote: >> > Hey Peter, >> > >> > Not sure how smart you really want to be here but keep in mind that >> BGP >> > say option C may never hear about it all the way to the egress PE in >> > other domain or area ... It is almost always incongruent with IGP. >> > >> > So if the BGP path is installed it will indeed be at risk to resolve >> via >> > less specific when it is still active BGP path and you too quickly >> > remove info about unreachability. >> >> again, if you are smart you can use this info to your advantage, even >> without putting it in the forwarding and leaving the less specific stuff >> intact. >> >> Peter >> >> >> > >> > Thx >> > R. >> > >> > On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak <ppse...@cisco.com >> > <mailto:ppse...@cisco.com>> wrote: >> > >> > On 30/07/2020 16:14, Robert Raszuk wrote: >> > > > 2：For bgp example，when the pe node down，the bgp peer >> > must down >> > > within >> > > > 30 mintus，It will not get it up via cancle advertise pua. >> > > >> > > for the above it is sufficient to advertise the >> > unreachability for few >> > > seconds from each ABR independently. That would be a much >> > more solid >> > > proposal. >> > > >> > > >> > > Not sure about "few seconds" ... IBGP def hold time in number of >> > > implementations is 180 sec :) .. but few minutes will work for >> sure. >> > >> > depends how you use it. >> > >> > If you can use the unreachable info in a smart way, it's >> sufficient if >> > it is present for a very short time interval. >> > >> > thanks, >> > Peter >> > >> > > >> > > 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
