Re: [Lsr] Prefix Unreachable Announcement Use Cases

Aijun Wang <wangaijun@tsinghua.org.cn> Sun, 15 November 2020 13:17 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 7E4123A11DD for <lsr@ietfa.amsl.com>; Sun, 15 Nov 2020 05:17:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 u7RfFQ4jAHGA for <lsr@ietfa.amsl.com>; Sun, 15 Nov 2020 05:17:07 -0800 (PST)
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 5145E3A11DB for <lsr@ietf.org>; Sun, 15 Nov 2020 05:17:05 -0800 (PST)
Received: from localhost.localdomain (unknown [106.121.64.254]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 5622747B31; Sun, 15 Nov 2020 21:17:02 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-7B4941E8-2F56-4945-B8CC-302FB67D7E26"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Sun, 15 Nov 2020 21:17:00 +0800
Message-Id: <00A6FE87-C24F-49A8-9539-3236F489B4B4@tsinghua.org.cn>
References: <CAOj+MMHAw50QU_YXHf+_fhBHsXJugJsQDVuza-rcsOupwiF1zA@mail.gmail.com>
Cc: lsr <lsr@ietf.org>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
In-Reply-To: <CAOj+MMHAw50QU_YXHf+_fhBHsXJugJsQDVuza-rcsOupwiF1zA@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (18A373)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZS0xDSBkdQ0hNQklKVkpNS05PT01JSUlOSk9VEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MhQ6Djo5NT8jSgsiTEorAzUv NjlPCwNVSlVKTUtOT09NSUlJQktCVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS01VSklKVU1PVUlOT1lXWQgBWUFCSEhLNwY+
X-HM-Tid: 0a75cc0d42139865kuuu5622747b31
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Kz-4YCxfb0dz_dewCQIeWOxRgpU>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases
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: Sun, 15 Nov 2020 13:17:10 -0000

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 15, 2020, at 18:49, Robert Raszuk <robert@raszuk.net> wrote:
> 
> 
> Hi Aijun,
> 
> As I think what you are proposing overall is useful let me in turn comment on some of your statements ... 
> 
>>> [WAJ] It is common, for example, ISIS level1-2 router will announce the default route to the level 1 area. And, also in the OSPF totally stubby area. 
>>> 
> 
> Well let's just take OSPF and imagine:
> 
>  Area1 --- ABR1 --- Area0 ---ABR2 --- Area2 
> 
> So you are saying that unreachable should be always flooded/leaked domain wide. That's news - I was always thinking of this functionality only in the case when a summary route covering such more specific is present. Default should not count ... at least I am not sure if this is safe or makes sense at this point. 
[WAJ] The situation is the same. If there is any special situation that is not safe, we can analyze it together.

> 
> 
>>> [WAJ] The tunnel soultions described in section 6 is the last resort of the path switch procedure. If we deploy the PUA mechanism, normally the routers within another area will switch automatically to other ABR when it receives the PUA from one ABR.  Only in the critical scenario that described in beginning of section 6, the solution described in section 6.1 or 6.2 will be used.
>>> 
> 
> I think this is where you are starting to confuse people. In my option this solution should have nothing to do with selecting which ABR to use to cross area boundary. 
[WAJ] This situation may occur when both ABR can’t send PUA messages to divert the traffic and it will apply when the PUA mechanism is not in effect. The last resort for the traffic forwarding.
> 
> The cases when one ABR has full remote reachability and the other one partial one in my view are symptoms of a very poorly designed network and to stretch protocol thin to cover for those mistakes with a patch is not a good thing. 
[WAJ] The situation is not exist from the design or from the beginning. It may appear after some links failure, although it is scarce scenario, we should consider it for completeness.

> 
> I would actually trim most use cases leaving just one - to signal remote service node (ex: PE) going down in the presence of summary route being advertised from remote area or pop. 
> 
[WAJ] Yes, this may be the most useful use case, but the PUA mechanism can also apply to other scenarios. We want to make it one general solution.

> Thx,
> R.
>