Hi, Intra area ?
If we are flooding host routes I have never seen a case where intra area those are not flooded. Where would you summarise ? On a node within area ? Very unreal scenario IMHO. Thx R. On Wed, Sep 9, 2020, 03:22 Aijun Wang <[email protected]> wrote: > Hi, Robert: > > > > PUA covers both the intra-area and inter-area scenarios. > > For inter-area scenario, it covers the situation that the next-hop is > reachable via one ABR but unreachable via another ABR. > > For such situation, BGP nexthop tracking, route withdraw or aggregate > withdraw will not work. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of > *Robert > Raszuk > *Sent:* Monday, September 7, 2020 5:36 PM > *To:* Aijun Wang <[email protected]> > *Cc:* Les Ginsberg (ginsberg) <[email protected]>; Gyan Mishra < > [email protected]>; Peter Psenak <[email protected]>; > Huzhibo <[email protected]>; Aijun Wang <[email protected]>; lsr < > [email protected]>; Acee Lindem (acee) <[email protected]>; Xiaoyaqun < > [email protected]>; Tony Przygienda <[email protected]> > *Subject:* Re: [Lsr] New Version Notification for > draft-wang-lsr-prefix-unreachable-annoucement-03.txt > > > > Hi Aijun, > > > > > the BGP next-hop is reachable > > > > Nope you missed the crux of the message. > > > > The next hop will be unreachable in the *source area/level. *That would > be where the BGP service route withdraw or aggregate withdraw would > originate at. Same as PUA. > > > > Best, > > Robert. > > > > > > On Mon, Sep 7, 2020 at 11:31 AM Aijun Wang <[email protected]> > wrote: > > Hi, Robert: > > For BGP next-hop tracking, it will help when the BGP next-hop is > unreachable. But in our situation, the BGP next-hop is reachable, but > should pass another ABR. > > Then, in such situation, the mechanism of BGP next-hop tracking will not > take effect? > > And thanks for your draft information, maybe we can refer to it later J > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of > *Robert > Raszuk > *Sent:* Monday, September 7, 2020 4:54 PM > *To:* Aijun Wang <[email protected]> > *Cc:* Les Ginsberg (ginsberg) <[email protected]>; Gyan Mishra < > [email protected]>; Peter Psenak <[email protected]>; > Huzhibo <[email protected]>; Aijun Wang <[email protected]>; lsr < > [email protected]>; Acee Lindem (acee) <[email protected]>; Xiaoyaqun < > [email protected]>; Tony Przygienda <[email protected]> > *Subject:* Re: [Lsr] New Version Notification for > draft-wang-lsr-prefix-unreachable-annoucement-03.txt > > > > Hi Aijun, > > *[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for > the hold of PUA information on the nodes) among the area.* > > *If one node connect to the network after the disappearance of the PUA > destination, there will be no services can be established/run on these > failure node/link prefix. * > > *It**’s the same as the beginning, as not all of the prefixes can be > reachable within the summary address.* > > > > From my pov the only advantage of negative routes in IGP would be to very > quickly invalidate service routes (within the IGP domain) typically carried > by BGP. > > > > When this is accomplished the PUA can indeed time out with no harm. > > > > Said this - now considering tools like next hop tracking which can trigger > withdraw or aggregated withdraw(*) proposal in src area I am really > curious how much (if anything) we would be gaining here. > > > > (*) The original proposal for this was written over 15 years ago: > https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00 We could > extend it with next hop which would be the same as IGP PUA prefix. > > > > Kind regards, > Robert > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
