Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Aijun Wang <wangaijun@tsinghua.org.cn> Tue, 09 March 2021 04:06 UTC

Return-Path: <wangaijun@tsinghua.org.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 682B93A0E22; Mon, 8 Mar 2021 20:06:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 s159Cc4Tm9IQ; Mon, 8 Mar 2021 20:06:38 -0800 (PST)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D903F3A0E1C; Mon, 8 Mar 2021 20:06:37 -0800 (PST)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 0F2C61C0178; Tue, 9 Mar 2021 12:06:35 +0800 (CST)
From: "Aijun Wang" <wangaijun@tsinghua.org.cn>
To: "'Tony Li'" <tony.li@tony.li>, "'Aijun Wang'" <wangaj3@chinatelecom.cn>
Cc: "'lsr'" <lsr@ietf.org>, "'draft-wang-lsr-prefix-unreachable-annoucement'" <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>, "'Acee Lindem \(acee\)'" <acee@cisco.com>, "'Gyan Mishra'" <hayabusagsm@gmail.com>
References: <22FDE3EA-B5D1-4E4D-B698-1D79173E8637@tony.li> <6E0281D2-7755-499A-B084-CA8472949683@chinatelecom.cn> <D6B0D95F-68AD-4A18-B98C-69835E8B149B@tony.li>
In-Reply-To: <D6B0D95F-68AD-4A18-B98C-69835E8B149B@tony.li>
Date: Tue, 9 Mar 2021 12:06:34 +0800
Message-ID: <018801d71499$9890feb0$c9b2fc10$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQLxZrWFi6EiIeKD/IAcznzpxeLHfwGUGnU/AflsCmCoKfds4A==
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZHUhKTUtJSkhCTxodVkpNSk5JTUlMQk5ISEtVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0JITVVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Ni46DCo4FD8IEw4qOEMCFyMW MwIwChZVSlVKTUpOSU1JTEJOTUJCVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQU9ISUM3Bg++
X-HM-Tid: 0a78152a45f7d993kuws0f2c61c0178
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/F0sA5ylnDQPNBMan3hgLD8ZCzQo>
Subject: Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05
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: Tue, 09 Mar 2021 04:06:40 -0000

Hi, Tony:

-----Original Message-----
From: lsr-bounces@ietf.org <lsr-bounces@ietf.org> On Behalf Of Tony Li
Sent: Tuesday, March 9, 2021 11:12 AM
To: Aijun Wang <wangaj3@chinatelecom.cn>
Cc: lsr <lsr@ietf.org>rg>; draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>rg>; Acee Lindem (acee) <acee@cisco.com>om>; Aijun Wang <wangaijun@tsinghua.org.cn>cn>; Gyan Mishra <hayabusagsm@gmail.com>
Subject: Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Hi Aijun,

> [WAJ] We just want to avoid such silent discard behavior, especially for the scenario that there is BGP session run on such failure prefix. 

Stuffing things in the IGP seems like a poor way of determining that there’s a BGP failure.  Wouldn’t BFD be a more appropriate way of determining the loss of connectivity?  Or aggressive BGP keepalive timers?
[WAJ] For BFD, you need to configure between each pair of them to track the connectivity.  For BGP keeplive times, the duration is too long.

> The other side of BGP peer can quickly remove the BGP session when it receives such PUA message which tell it the other peer is down now. Other BGP peer protection procedures can then take effects on.
> The immediate notification of the failure prefix can certainly accelerate the switchover of BGP control plane and also the service traffic that such BGP session carries.


The IGP is a very poor way of delivering service liveness information.
[WAJ] why? 


>>> For scenarios 2, because the specified prefixes can be accessed via another ABR, then we can let this ABR to advertise the details prefixes information for the specified address, which behavior is similar with RIFT, as also mentioned in the presentation materials.
>> 
>> 
>> Agreed.
> 
> [WAJ] Even for this scenario, the advertisement of the detail prefixes is trigger also via the PUA message from other ABR.


That seems 100% unnecessary as the longer prefix will attract the traffic in the way that you want.
[WAJ] If the ABR advertises such detail prefix, it will certainly attract the traffic. But here the PUA message is just to trigger the ABR to advertise such detail prefix, or else, such ABR will still advertise the summary address.

Tony

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr