Re: [Lsr] Prefix Unreachable Announcement Use Cases

Aijun Wang <wangaijun@tsinghua.org.cn> Mon, 16 November 2020 03:07 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 55E853A10AD for <lsr@ietfa.amsl.com>; Sun, 15 Nov 2020 19:07:26 -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=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 cbiBIUlCCtw5 for <lsr@ietfa.amsl.com>; Sun, 15 Nov 2020 19:07:24 -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 572363A10A0 for <lsr@ietf.org>; Sun, 15 Nov 2020 19:07:23 -0800 (PST)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 8A7C24810E; Mon, 16 Nov 2020 11:07:17 +0800 (CST)
From: "Aijun Wang" <wangaijun@tsinghua.org.cn>
To: "'Robert Raszuk'" <robert@raszuk.net>, "'Jeff Tantsura'" <jefftant.ietf@gmail.com>
Cc: "'lsr'" <lsr@ietf.org>, "'Acee Lindem \(acee\)'" <acee=40cisco.com@dmarc.ietf.org>
References: <CAOj+MMEREV+TCwNiptdVj--HjD5nJV8zOiUJ5THcsomWCa1jJA@mail.gmail.com> <B0A6A569-30F7-4751-9F3B-C65BD23D39F3@gmail.com> <CAOj+MMEYnHeuNnNy-yDuxywMLe+yHv3QfXYqtqEgom7RbTO6Sg@mail.gmail.com>
In-Reply-To: <CAOj+MMEYnHeuNnNy-yDuxywMLe+yHv3QfXYqtqEgom7RbTO6Sg@mail.gmail.com>
Date: Mon, 16 Nov 2020 11:07:17 +0800
Message-ID: <020d01d6bbc5$9769e7e0$c63db7a0$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_020E_01D6BC08.A58EAE80"
X-Mailer: Microsoft Outlook 16.0
Content-Language: zh-cn
Thread-Index: AQGcUPTXJ+U6NoAo7cvOT28mq+owYAHx0eBhAYxY8GmqIvABYA==
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZS00eTUJNT0NDTkweVkpNS05PQk1LSExDS0pVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OBw6Cxw*KD8ePwo3LhkjHAgJ EBIwCkJVSlVKTUtOT0JNS0hDSEtCVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUlJTkJNNwY+
X-HM-Tid: 0a75cf05614c9865kuuu8a7c24810e
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/q1OubIj0Qb58CqDAuzIoWT2fVH8>
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: Mon, 16 Nov 2020 03:07:26 -0000

Hi, Robert:

 

Does the following responses satisfy your concerns If I understand your questions correctly? 

 

From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Monday, November 16, 2020 4:04 AM
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: lsr <lsr@ietf.org>rg>; Aijun Wang <wangaijun@tsinghua.org.cn>cn>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases

 

Jeff, 

 

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 if you intend to use unreachable prefixes in data plane as result you need to break summary into as atomic prefixes as your unreachable advertisement mask. 

[WAJ] When the number of unreachable prefixes is limited(this is the common situation),  Summary Route+PUA is the most efficient solution.

 

Hence my recommendation to use IGP to flood unreachable only for the purpose of control plane (namely BGP paths invalidation). 

[WAJ]  PUA and “Smart Disaggregation” in RIFT aim to the same problems, but there are some differences:

1.     In RIFT, the parallel node will advertise the detailed prefix when it detects that another node on the same level can’t reach the mentioned prefix. But for PUA, the decision/advertisement is made by the ABR node itself that knows the failure of links/nodes. 

2.     The advertisement information is different. In RIFT, the detail prefix information is advertised(by another node that can reach the failure prefix); in PUA, the detail unreachable prefix information is advertised instead(by the node that can’t reach the failure prefix). 

 After knowing this information, the receiver node can switch the path to send the traffic, or trigger the BGP control plane switchover as you said.

 

Cheers,

R.

 

On Sun, Nov 15, 2020 at 8:29 PM Jeff Tantsura <jefftant.ietf@gmail.com <mailto:jefftant.ietf@gmail.com> > wrote:

As RIFT chair - I’d like to respond to Robert’ comment -  the example is rather  unfortunate, in RIFT disaggregation is conditional and well contained within its context, it doesn’t  affect overall scalability.

Regards,

Jeff





On Nov 15, 2020, at 08:44, Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net> > wrote:



Hi Aijun,

 

I would in fact only propose that the presented mechanism is narrowed down to invalidate BGP (service) routes - in fact their next hops. 

 

The reason being that the moment you make the solution generic, moreover the moment you want it to be used in RIB and data plane I am afraid you are running into similar (even if local) deaggregation mechanism like recently described in RIFT. That would kill all the scalability of advertising summary routes in the first place and I bet would face lots of opposition. 

 

Thx,

R.

 

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.

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