Re: [Lsr] Prefix Unreachable Announcement Use Cases

Aijun Wang <wangaijun@tsinghua.org.cn> Fri, 20 November 2020 14:27 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 97AD33A0AAD for <lsr@ietfa.amsl.com>; Fri, 20 Nov 2020 06:27:34 -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=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 nHhVPZc3WkRQ for <lsr@ietfa.amsl.com>; Fri, 20 Nov 2020 06:27:31 -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 415303A0A93 for <lsr@ietf.org>; Fri, 20 Nov 2020 06:27:30 -0800 (PST)
Received: from localhost.localdomain (unknown [106.121.130.5]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 68FBA4580F; Fri, 20 Nov 2020 22:27:24 +0800 (CST)
Content-Type: multipart/alternative; boundary=Apple-Mail-8E520655-D36D-40AC-982F-BE292B5D2148
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Fri, 20 Nov 2020 22:27:22 +0800
Message-Id: <8384F1B4-7AB2-4951-BAEA-3FC02A0ADDBD@tsinghua.org.cn>
References: <CA+wi2hNY4tAxoAbQNb13z+CNcP8+GPX2eKV_poFLrrr5TudmsQ@mail.gmail.com>
Cc: Jeff Tantsura <jefftant.ietf@gmail.com>, lsr <lsr@ietf.org>, Robert Raszuk <robert@raszuk.net>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
In-Reply-To: <CA+wi2hNY4tAxoAbQNb13z+CNcP8+GPX2eKV_poFLrrr5TudmsQ@mail.gmail.com>
To: Tony Przygienda <tonysietf@gmail.com>
X-Mailer: iPhone Mail (18A373)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZHUNMGB1PTE5CH0lNVkpNS05DQ0lPT09NSEtVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Ny46SSo6Sj8uCQMJPDcKE0sQ GDwaCSxVSlVKTUtOQ0NJT09OS0pCVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS01VSklKVUpIS1VOWVdZCAFZQUpKT0JONwY+
X-HM-Tid: 0a75e60d7a929865kuuu68fba4580f
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/NKQG7gZhqdjK-unPVLR1e3oG53M>
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: Fri, 20 Nov 2020 14:27:35 -0000

Hi, Tony:

Aijun Wang
China Telecom

> On Nov 20, 2020, at 17:45, Tony Przygienda <tonysietf@gmail.com> wrote:
> 
> 
> Yes, acknowledging the idea of negative disaggregation is inspired by RIFT work is fine (and normally, when inspired by an idea at least in research cycles it is considered basic courtesy to refer to the according source, something has been lost more and more in IETF over time I dare to observe which in itself reflects on the community IMO) but please do not try to compare the two beyond that.
[WAJ] PUA has no relation with RIFT. I have not yet study what’s problem it encountered, but welcome the experts have such design experience to point out the pitfall that PUA can bypass.

> Disaggregation works well on directed graphs (lattices) or arguably if your addressing scheme is aligned with regular topology (hypercube e.g.). it works in generic graphs in super special cases only & it will be @ best a crutch that may under all the correct circumstances have some utility but probably ends up hurting operationally more than helping.
[WAJ] PUA will try to avoid the solution that can only fit some special topology or address schema.

> The indication that "magic timer" is needed in the draft should be first warning, all kind of seat-of-pants heuristics to dis- and re-aggregate 2nd. 

[WAJ] “timer” is not uncommon in IGP protocol. Using it within PUA mechanism is just to assure the service switch successfully upon it receives the PUA.

> Just quickly flying through the draft I see lots of logic problems already that will lead to vexing effects, e.g. indication of missing neighbor will work in specific type of topologies, in others varying by one link only may lead to stable blackholes. 
[WAJ] Would you like to state the above conclusion more clearly?

> 
> my 2c
> 
> -- tony 
> 
>> On Sun, Nov 15, 2020 at 11:29 AM Jeff Tantsura <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> 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
>>> https://www.ietf.org/mailman/listinfo/lsr
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr