Hi, Robert:
Summary on ABRs. Please see the description in section-3.3 <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-3.3> of this draft. From: rob...@raszuk.net [mailto:rob...@raszuk.net] Sent: Wednesday, September 9, 2020 3:08 PM To: Aijun Wang <wangai...@tsinghua.org.cn> Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Gyan Mishra <hayabusa...@gmail.com>; Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org>; Huzhibo <huzh...@huawei.com>; Aijun Wang <wang...@chinatelecom.cn>; lsr <lsr@ietf.org>; Acee Lindem (acee) <a...@cisco.com>; Xiaoyaqun <xiaoya...@huawei.com>; Tony Przygienda <tonysi...@gmail.com> Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt 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 <wangai...@tsinghua.org.cn <mailto:wangai...@tsinghua.org.cn> > 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: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> [mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> ] On Behalf Of Robert Raszuk Sent: Monday, September 7, 2020 5:36 PM To: Aijun Wang <wangai...@tsinghua.org.cn <mailto:wangai...@tsinghua.org.cn> > Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com <mailto:ginsb...@cisco.com> >; Gyan Mishra <hayabusa...@gmail.com <mailto:hayabusa...@gmail.com> >; Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org <mailto:40cisco....@dmarc.ietf.org> >; Huzhibo <huzh...@huawei.com <mailto:huzh...@huawei.com> >; Aijun Wang <wang...@chinatelecom.cn <mailto:wang...@chinatelecom.cn> >; lsr <lsr@ietf.org <mailto:lsr@ietf.org> >; Acee Lindem (acee) <a...@cisco.com <mailto:a...@cisco.com> >; Xiaoyaqun <xiaoya...@huawei.com <mailto:xiaoya...@huawei.com> >; Tony Przygienda <tonysi...@gmail.com <mailto:tonysi...@gmail.com> > 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 <wangai...@tsinghua.org.cn <mailto:wangai...@tsinghua.org.cn> > 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: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> [mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> ] On Behalf Of Robert Raszuk Sent: Monday, September 7, 2020 4:54 PM To: Aijun Wang <wangai...@tsinghua.org.cn <mailto:wangai...@tsinghua.org.cn> > Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com <mailto:ginsb...@cisco.com> >; Gyan Mishra <hayabusa...@gmail.com <mailto:hayabusa...@gmail.com> >; Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org <mailto:40cisco....@dmarc.ietf.org> >; Huzhibo <huzh...@huawei.com <mailto:huzh...@huawei.com> >; Aijun Wang <wang...@chinatelecom.cn <mailto:wang...@chinatelecom.cn> >; lsr <lsr@ietf.org <mailto:lsr@ietf.org> >; Acee Lindem (acee) <a...@cisco.com <mailto:a...@cisco.com> >; Xiaoyaqun <xiaoya...@huawei.com <mailto:xiaoya...@huawei.com> >; Tony Przygienda <tonysi...@gmail.com <mailto:tonysi...@gmail.com> > 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
