Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Aijun Wang <wangaj3@chinatelecom.cn> Wed, 09 September 2020 07:40 UTC

Return-Path: <wangaj3@chinatelecom.cn>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871533A0C33 for <lsr@ietfa.amsl.com>; Wed, 9 Sep 2020 00:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uD5-WXXWRhoh for <lsr@ietfa.amsl.com>; Wed, 9 Sep 2020 00:40:34 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.219]) by ietfa.amsl.com (Postfix) with ESMTP id C63573A0BC1 for <lsr@ietf.org>; Wed, 9 Sep 2020 00:40:33 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.92:13635.509059025
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-219.142.69.75?logid-7b5bf2a5c15a47b0af1098b989f0402b (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with SMTP id C6B5C2800C6; Wed, 9 Sep 2020 15:40:11 +0800 (CST)
X-189-SAVE-TO-SEND: 66040164@chinatelecom.cn
Received: from ([172.18.0.92]) by App0021 with ESMTP id 7b5bf2a5c15a47b0af1098b989f0402b for acee@cisco.com; Wed Sep 9 15:40:30 2020
X-Transaction-ID: 7b5bf2a5c15a47b0af1098b989f0402b
X-filter-score: filter<0>
X-Real-From: wangaj3@chinatelecom.cn
X-Receive-IP: 172.18.0.92
X-MEDUSA-Status: 0
Sender: wangaj3@chinatelecom.cn
From: Aijun Wang <wangaj3@chinatelecom.cn>
To: robert@raszuk.net, 'Aijun Wang' <wangaijun@tsinghua.org.cn>
Cc: "'Les Ginsberg (ginsberg)'" <ginsberg@cisco.com>, 'Gyan Mishra' <hayabusagsm@gmail.com>, 'Peter Psenak' <ppsenak=40cisco.com@dmarc.ietf.org>, 'Huzhibo' <huzhibo@huawei.com>, 'lsr' <lsr@ietf.org>, "'Acee Lindem (acee)'" <acee@cisco.com>, 'Xiaoyaqun' <xiaoyaqun@huawei.com>, 'Tony Przygienda' <tonysietf@gmail.com>
References: <CAOj+MMGgpcnRMnPxQqcZofgJNH67QYUQOxWsTU5Xp-Km0D2DDg@mail.gmail.com> <A202F6E1-AD83-46E8-A1D2-E156FB35DF57@chinatelecom.cn> <CAOj+MMHd1WZNCWr6KihxzDf=G53A8FBUBbqHpZGNwvF4hsuzMA@mail.gmail.com> <059e01d66ad7$ffda2e50$ff8e8af0$@tsinghua.org.cn> <CABNhwV2oXBBNKOdUA59sLF+b5srWHi3KF2Q6H1Tg-dK+gA9Lgw@mail.gmail.com> <013301d679f6$92da3ce0$b88eb6a0$@tsinghua.org.cn> <CA+wi2hM1H6Vr5U_1fTVkPi5aQLrFTeRhD5Q8Be2T+wf0e1h+QA@mail.gmail.com> <BY5PR11MB4337214640926A190A8D620FC12D0@BY5PR11MB4337.namprd11.prod.outlook.com> <8838525B-EB2D-4B40-956A-1F0D5EA56D32@cisco.com> <CABNhwV26_doVEPTexHUhgAJNjdAF1JwCAHxf4H1+QzKCGLyP9g@mail.gmail.com> <00dd01d684c9$2d1ff3d0$875fdb70$@tsinghua.org.cn> <CAOj+MMHVv2DS0=F0YKso7r=DQ=s2-mMhmrYTraXt51D-+5p9bQ@mail.gmail.com> <011301d684f9$b22dafb0$16890f10$@tsinghua.org.cn> <CAOj+MMGn02kqGqdcsP4JhAqY5L3kr2C3xhAybsJuRvpAQeSkUg@mail.gmail.com> <00b301d68647$bbdf4560$339dd020$@tsinghua.org.cn> <CAOj+MMHhtLqeqxoiqnPLZ17ZK5c95YtXtXChsNu2US8Gks6RqQ@mail.gmail.com>
In-Reply-To: <CAOj+MMHhtLqeqxoiqnPLZ17ZK5c95YtXtXChsNu2US8Gks6RqQ@mail.gmail.com>
Date: Wed, 09 Sep 2020 15:40:10 +0800
Message-ID: <010401d6867c$7de75e70$79b61b50$@chinatelecom.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0105_01D686BF.8C0E47F0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKwsgRl8uq4ZZAYYiwm8gqgwsmPuwLfhjxOAXwBCl8B/jVB7AHXWAwnAU+85ywCK6kboAKkbAgoAYwlr7oClVsLogGF6cZPAjiYMKQCyT0wiQGablTLAvZNU0ECRvV+Q6atBYIw
Content-Language: zh-cn
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Q09RBfIb885zrmDbu3STbhR9UFI>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2020 07:40:40 -0000

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: robert@raszuk.net [mailto:robert@raszuk.net] 
Sent: Wednesday, September 9, 2020 3:08 PM
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Gyan Mishra <hayabusagsm@gmail.com>; Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>; Huzhibo <huzhibo@huawei.com>; Aijun Wang <wangaj3@chinatelecom.cn>; lsr <lsr@ietf.org>; Acee Lindem (acee) <acee@cisco.com>; Xiaoyaqun <xiaoyaqun@huawei.com>; Tony Przygienda <tonysietf@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 <wangaijun@tsinghua.org.cn <mailto:wangaijun@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-bounces@ietf.org <mailto:lsr-bounces@ietf.org>  [mailto:lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org> ] On Behalf Of Robert Raszuk
Sent: Monday, September 7, 2020 5:36 PM
To: Aijun Wang <wangaijun@tsinghua.org.cn <mailto:wangaijun@tsinghua.org.cn> >
Cc: Les Ginsberg (ginsberg) <ginsberg@cisco.com <mailto:ginsberg@cisco.com> >; Gyan Mishra <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com> >; Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org <mailto:40cisco.com@dmarc.ietf.org> >; Huzhibo <huzhibo@huawei.com <mailto:huzhibo@huawei.com> >; Aijun Wang <wangaj3@chinatelecom.cn <mailto:wangaj3@chinatelecom.cn> >; lsr <lsr@ietf.org <mailto:lsr@ietf.org> >; Acee Lindem (acee) <acee@cisco.com <mailto:acee@cisco.com> >; Xiaoyaqun <xiaoyaqun@huawei.com <mailto:xiaoyaqun@huawei.com> >; Tony Przygienda <tonysietf@gmail.com <mailto:tonysietf@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 <wangaijun@tsinghua.org.cn <mailto:wangaijun@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-bounces@ietf.org <mailto:lsr-bounces@ietf.org>  [mailto:lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org> ] On Behalf Of Robert Raszuk
Sent: Monday, September 7, 2020 4:54 PM
To: Aijun Wang <wangaijun@tsinghua.org.cn <mailto:wangaijun@tsinghua.org.cn> >
Cc: Les Ginsberg (ginsberg) <ginsberg@cisco.com <mailto:ginsberg@cisco.com> >; Gyan Mishra <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com> >; Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org <mailto:40cisco.com@dmarc.ietf.org> >; Huzhibo <huzhibo@huawei.com <mailto:huzhibo@huawei.com> >; Aijun Wang <wangaj3@chinatelecom.cn <mailto:wangaj3@chinatelecom.cn> >; lsr <lsr@ietf.org <mailto:lsr@ietf.org> >; Acee Lindem (acee) <acee@cisco.com <mailto:acee@cisco.com> >; Xiaoyaqun <xiaoyaqun@huawei.com <mailto:xiaoyaqun@huawei.com> >; Tony Przygienda <tonysietf@gmail.com <mailto:tonysietf@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