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

Huzhibo <huzhibo@huawei.com> Thu, 30 July 2020 16:33 UTC

Return-Path: <huzhibo@huawei.com>
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 3CBBB3A03F6 for <lsr@ietfa.amsl.com>; Thu, 30 Jul 2020 09:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.332
X-Spam-Level:
X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 LT1IWX09fLDp for <lsr@ietfa.amsl.com>; Thu, 30 Jul 2020 09:33:46 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E64163A03FC for <lsr@ietf.org>; Thu, 30 Jul 2020 09:33:45 -0700 (PDT)
Received: from lhreml707-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 24FE1245BE12005C3EB7 for <lsr@ietf.org>; Thu, 30 Jul 2020 17:33:44 +0100 (IST)
Received: from lhreml707-chm.china.huawei.com (10.201.108.56) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Thu, 30 Jul 2020 17:33:38 +0100
Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Thu, 30 Jul 2020 17:33:38 +0100
Received: from DGGEMM509-MBX.china.huawei.com ([169.254.9.142]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0487.000; Fri, 31 Jul 2020 00:33:28 +0800
From: Huzhibo <huzhibo@huawei.com>
To: Robert Raszuk <robert@raszuk.net>
CC: "Acee Lindem (acee)" <acee@cisco.com>, Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>, Aijun Wang <wangaj3@chinatelecom.cn>, Xiaoyaqun <xiaoyaqun@huawei.com>, Aijun Wang <wangaijun@tsinghua.org.cn>, lsr <lsr@ietf.org>
Thread-Topic: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt
Thread-Index: AQHWY7N0b8U7rxAxrkKccN2nDUzbRKkaHimAgAU5wgCAACgfAIAABGUAgAAH84CAAAOxAIAAhoWA//9/OgCAAAhgAIAAC7UAgAAB8ACAAAKVgIAAAQUAgAAZAYCAAIpFYYAABDAG
Date: Thu, 30 Jul 2020 16:33:27 +0000
Message-ID: 0CADCF57-53FF-4C2F-863F-ED2AE1F17811
References: <b85c277f-07d2-f40d-071d-295512ea7c73@cisco.com> <B1061E81-F9B6-4647-B5D6-B97D67C4AD8E@chinatelecom.cn> <fc0369b2-6f76-48f1-2c0e-e218e6db5e7b@cisco.com> <06CF729DA0D6854E8C1E5121AC3330DFAF71770C@dggemm509-mbx.china.huawei.com> <43f707e5-4409-670f-0983-0c672da53ecb@cisco.com> <96779843-a40d-e83b-8d24-baeb6c8648ea@cisco.com> <CAOj+MME7ADcnxe-m0JJ-EpWCzczhC6O8QY5xrxDQRA0w3aRGjQ@mail.gmail.com> <2a6844df-59ed-ca91-c306-d2288c44a1dc@cisco.com> <CAOj+MMFGJeNXsGgeram4uVaO5aDvQUTRbWL9N91NbQHvgP7M+A@mail.gmail.com> <9fa84c34-e3f5-42bd-2b6b-20a114acf3b3@cisco.com> <BFB12E8C-8B18-4658-BC2F-4065CCB5C492@cisco.com> <5f22f096.1c69fb81.2dcdc.73beSMTPIN_ADDED_BROKEN@mx.google.com>, <CAOj+MMGgpcnRMnPxQqcZofgJNH67QYUQOxWsTU5Xp-Km0D2DDg@mail.gmail.com>
In-Reply-To: <CAOj+MMGgpcnRMnPxQqcZofgJNH67QYUQOxWsTU5Xp-Km0D2DDg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_0CADCF5753FF4C2F863FED2AE1F17811_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/J-TTiaN5f_245QG0fjkGiiyXmZk>
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: Thu, 30 Jul 2020 16:33:50 -0000

hi:

if abr1 advertise pua but abr2 not,other node will think the prefix is reachable via abr2. and will not advertise pua to other area.

I am not idea how bgp can work?keepalive expire?bfd?maybe bfd can work.local policy verification?some usecase maybe yes.


--------------------------------------------------
胡志波 Hu Zhibo
Mobile: +86-18618192287<tel:+86-18618192287>
Email: huzhibo@huawei.com<mailto:huzhibo@huawei.com>

发件人:Robert Raszuk <robert@raszuk.net>
收件人:Huzhibo <huzhibo@huawei.com>
抄 送:Acee Lindem (acee) <acee@cisco.com>;Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>;Aijun Wang <wangaj3@chinatelecom.cn>;Xiaoyaqun <xiaoyaqun@huawei.com>;Aijun Wang <wangaijun@tsinghua.org.cn>;lsr <lsr@ietf.org>
时 间:2020-07-31 00:18:27
主 题:Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

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 ?

Then on the other side there is area 2. Should the transition to down 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 ?

- - -

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.

Thx,
R.


On Thu, Jul 30, 2020 at 6:08 PM Huzhibo <huzhibo@huawei.com<mailto:huzhibo@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<tel:+86-18618192287>
Email: huzhibo@huawei.com<mailto:huzhibo@huawei.com>

发件人:Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>>
收件人:Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>>;Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
抄 送:Aijun Wang <wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>>;Xiaoyaqun <xiaoyaqun@huawei.com<mailto:xiaoyaqun@huawei.com>>;Huzhibo <huzhibo@huawei.com<mailto:huzhibo@huawei.com>>;Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>;lsr <lsr@ietf.org<mailto: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-bounces@ietf.org<mailto:lsr-bounces@ietf.org> on behalf of ppsenak=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@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 <ppsenak@cisco.com<mailto:ppsenak@cisco.com>
    > <mailto:ppsenak@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<mailto:Lsr@ietf.org>
    https://www.ietf.org/mailman/listinfo/lsr