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

Aijun Wang <wangaijun@tsinghua.org.cn> Wed, 05 August 2020 03:25 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 4A55A3A078C for <lsr@ietfa.amsl.com>; Tue, 4 Aug 2020 20:25:15 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 o4x0skZey8Uc for <lsr@ietfa.amsl.com>; Tue, 4 Aug 2020 20:25:08 -0700 (PDT)
Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B403A0746 for <lsr@ietf.org>; Tue, 4 Aug 2020 20:25:07 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 20FA446D16; Wed, 5 Aug 2020 11:25:03 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: 'Robert Raszuk' <robert@raszuk.net>, 'Aijun Wang' <wangaj3@chinatelecom.cn>
Cc: '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>
References: <CAOj+MMGgpcnRMnPxQqcZofgJNH67QYUQOxWsTU5Xp-Km0D2DDg@mail.gmail.com> <A202F6E1-AD83-46E8-A1D2-E156FB35DF57@chinatelecom.cn> <CAOj+MMHd1WZNCWr6KihxzDf=G53A8FBUBbqHpZGNwvF4hsuzMA@mail.gmail.com>
In-Reply-To: <CAOj+MMHd1WZNCWr6KihxzDf=G53A8FBUBbqHpZGNwvF4hsuzMA@mail.gmail.com>
Date: Wed, 05 Aug 2020 11:24:59 +0800
Message-ID: <059e01d66ad7$ffda2e50$ff8e8af0$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_059F_01D66B1B.0E00A2A0"
X-Mailer: Microsoft Outlook 16.0
Content-Language: zh-cn
Thread-Index: AQKwsgRl8uq4ZZAYYiwm8gqgwsmPuwLfhjxOAXwBCl+nUWjEEA==
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZQ0sYHkhKQxhCGEsaVkpOQk1OQkxCS0hOT0xVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVKS0tZBg++
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6ODY6HDo6Iz8tLVY6NC8vECg# DSFPFClVSlVKTkJNTkJMQktPS0xIVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpNQkhCNwY+
X-HM-Tid: 0a73bca6a0369865kuuu20fa446d16
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/625uJtZXmGqsWMF_SPHf9AiOlK4>
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, 05 Aug 2020 03:25:15 -0000

Hi, Robert:

 

From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Friday, July 31, 2020 6:21 PM
To: Aijun Wang <wangaj3@chinatelecom.cn>
Cc: Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>; Huzhibo <huzhibo@huawei.com>; Aijun Wang <wangaijun@tsinghua.org.cn>; lsr <lsr@ietf.org>; Acee Lindem (acee) <acee@cisco.com>; Xiaoyaqun <xiaoyaqun@huawei.com>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

 

[WAJ] Such information is for underlay link state and should be flooded via IGP? The ambiguity arises from IGP summary behavior and should be solved by itself?

 

Well if we look at this problem from a distance while on surface it seems like an IGP issue (not to mention some which use BGP as IGP :) IMO it is only hurting when you have some service overlay on top utilizing the IGP. 

[WAJ] There are situations that the PUA mechanism apply when no service overlay running over IGP.  Scenarios described in  <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-3> draft-wang-lsr-prefix-unreachable-annoucement-03#section-3 are not tightly coupled with the overlay service.

 

So typically today if I am running any service with BGP I do count on BGP to remove routes which are no longer reachable. IGP just tells me how to get to the next hop, which direction to go and not if the endpoint (service CPE or PE connected to given CE) is up or down. 

 

So today smart BGP implementations in good network design can use RD based withdraws to very fast (milliseconds) remove the affected service routes. When I said should we do it in BGP I meant to ask WG if this is good enough to quickly remove service routes. If not maybe we should send such affected next hop in BGP to even faster invalidate all routes with such next hop as failing PE. 

 

Bottom line if you think the problem is IGP then I think Acee's comments apply. 

[WAJ] Which comment is not addressed yet?

 

Last - See today you are bringing the case to signal transition to DOWN ... but for some people and applications it may be not enough. In fact UP/DOWN they can get via BGP. But if you have two ABRs and one will due to topology changes in its area suddenly will be forced to reach atomic destination covered by summary over much higher metric path that for applications running above may be much more severe case and not acceptable one too. 

[WAJ] Or else, the application traffic will be broken.

 

And BGP will not remove service routes nor modify best path in any way as summary is masking the real metric to some next hops. So while in the network you may have alternate better native transit paths with a lot of free capacity if you only switch to a different bgp next hop (not talking about any TE at all) you are stuck offering much worse service to your customers. 

[WAJ] if there are other links to reach the affected prefix via the ABR, then this ABR will not send the PUA information.

 

Those cases are starting to be solved by performance routing both at the service itself or at BGP nh levels. Should IGP assist here ... I am not sure.

[WAJ] when node become down, it can only depend on other nodes within the same IGP to send such unreachability information. IGP can certainly help here J

 

 

Many thx,

R.