Re: [Lsr] Prefix Unreachable Announcement Use Cases

Aijun Wang <wangaijun@tsinghua.org.cn> Tue, 17 November 2020 06:21 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 13F653A0FCE for <lsr@ietfa.amsl.com>; Mon, 16 Nov 2020 22:21:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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=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 hkBpvSK0e2fu for <lsr@ietfa.amsl.com>; Mon, 16 Nov 2020 22:21:02 -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 DDC843A0FCC for <lsr@ietf.org>; Mon, 16 Nov 2020 22:21:01 -0800 (PST)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id DC9D84852D; Tue, 17 Nov 2020 14:20:57 +0800 (CST)
From: "Aijun Wang" <wangaijun@tsinghua.org.cn>
To: "'Jeff Tantsura'" <jefftant.ietf@gmail.com>, "'Robert Raszuk'" <robert@raszuk.net>
Cc: "'lsr'" <lsr@ietf.org>, "'Acee Lindem \(acee\)'" <acee=40cisco.com@dmarc.ietf.org>
References: <CAOj+MMH7zRaXNJTRC0ua7ohasUpo0MmeqgzcU9BdpcD7wD+Yrg@mail.gmail.com> <D477846E-1086-46A8-B2D6-E552623E2643@gmail.com>
In-Reply-To: <D477846E-1086-46A8-B2D6-E552623E2643@gmail.com>
Date: Tue, 17 Nov 2020 14:20:56 +0800
Message-ID: <016b01d6bca9$cf908c20$6eb1a460$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_016C_01D6BCEC.DDB72780"
X-Mailer: Microsoft Outlook 16.0
Content-Language: zh-cn
Thread-Index: AQILbNEP0SRic90ZNEbpRjygmkrFZQJx5udEqU7nmVA=
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZQ0JIH0NNGkpLQ0gfVkpNS05OQk9LTkNKTEpVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Okk6NBw4Lz8qMwgCPjFIPh4o PSkwC01VSlVKTUtOTkJPS05DTkNCVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpOTUxMNwY+
X-HM-Tid: 0a75d4dd0d469865kuuudc9d84852d
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/EBgvoVtMaiQRJcnwoJApkDtzOu0>
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: Tue, 17 Nov 2020 06:21:05 -0000

Hi, Jeff and Robert:

 

Please see the response inlines.

 

From: Jeff Tantsura <jefftant.ietf@gmail.com> 
Sent: Monday, November 16, 2020 6:36 PM
To: Robert Raszuk <robert@raszuk.net>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>cn>; lsr <lsr@ietf.org>rg>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases

 

+1 with Robert.

 

So you expect the following RIB state after PUA has been advertised:

10.0.0.1 - drop

10/24 - forward 

[WAJ] Yes, this is the expected result.

 

Unless there’s a recursively discarded next-hop (ala RTBH )  - how do you envision it?

[WAJ] This is the action that the node receives the PUA should do. Existing router may not support it, so we define the PUA capabilities announcement in section-6.3 of this draft <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-04#section-6.3>  

Regards,

Jeff





On Nov 16, 2020, at 00:25, Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net> > wrote:



I was not bringing RIFT's negative routies example as something inherently negative. I was just pointing it out to illustrate that today's data plane lookup does not really support "if does not match" checks.

[WAJ] In data plane, the device do still the “match” check, not “does not match” check.  When the router receives the PUA information, it will install one black hole route for a short time.

 

So your idea is that you install route for unreachable prefix to /dev/null ? 

[WAJ] Yes.

 

And how would that help connectivity restoration ? 

[WAJ] This action will trigger the path protection procedures, which will divert the traffic to other backup path.

 

Moreover it seems that it will just also prevent any local protection to locally bypass the failed destination. 

[WAJ] No, It will trigger the local protection instead, not prevent.

 

Bottom line is that I agree with one problem statement. However IMHO described actions upon reception of PUA are questionable at best. 

 

Cheers,
R.