Re: [Lsr] Prefix Unreachable Announcement Use Cases

Huzhibo <huzhibo@huawei.com> Wed, 18 November 2020 02:36 UTC

Return-Path: <huzhibo@huawei.com>
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 ECF153A12BC for <lsr@ietfa.amsl.com>; Tue, 17 Nov 2020 18:36:40 -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 2lSknKOCb1qD for <lsr@ietfa.amsl.com>; Tue, 17 Nov 2020 18:36:38 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47DED3A12BA for <lsr@ietf.org>; Tue, 17 Nov 2020 18:36:38 -0800 (PST)
Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CbRhs1DdCz67FGC; Wed, 18 Nov 2020 10:34:21 +0800 (CST)
Received: from dggema718-chm.china.huawei.com (10.3.20.82) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 18 Nov 2020 03:36:33 +0100
Received: from dggema769-chm.china.huawei.com (10.1.198.211) by dggema718-chm.china.huawei.com (10.3.20.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 18 Nov 2020 10:36:32 +0800
Received: from dggema769-chm.china.huawei.com ([10.9.128.71]) by dggema769-chm.china.huawei.com ([10.9.128.71]) with mapi id 15.01.1913.007; Wed, 18 Nov 2020 10:36:31 +0800
From: Huzhibo <huzhibo@huawei.com>
To: "tony.li@tony.li" <tony.li@tony.li>, Aijun Wang <wangaijun@tsinghua.org.cn>
CC: lsr <lsr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, Robert Raszuk <robert@raszuk.net>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
Thread-Topic: [Lsr] Prefix Unreachable Announcement Use Cases
Thread-Index: AQHWus275EEkcvdE9EaQpI0Pj8h7tKnHr8AAgAAjWgCAAKr9gIAAKWQAgAA53ICAAC4pAIAACZYAgAB2YICAAFjhAIAAJG8AgAFLHwCAAALfAIAB1KSg
Date: Wed, 18 Nov 2020 02:36:31 +0000
Message-ID: <d8c4497b5910457cad2691479d8c365d@huawei.com>
References: <CAOj+MMH7zRaXNJTRC0ua7ohasUpo0MmeqgzcU9BdpcD7wD+Yrg@mail.gmail.com> <D477846E-1086-46A8-B2D6-E552623E2643@gmail.com> <016b01d6bca9$cf908c20$6eb1a460$@tsinghua.org.cn> <4CCB3F3C-8537-4072-8763-D4B3C557EBD9@tony.li>
In-Reply-To: <4CCB3F3C-8537-4072-8763-D4B3C557EBD9@tony.li>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.201.204]
Content-Type: multipart/alternative; boundary="_000_d8c4497b5910457cad2691479d8c365dhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/2zgAo8V961VqVAufG9Kk0dqEIA8>
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: Wed, 18 Nov 2020 02:36:41 -0000

Hi Tony:

In fact, this protection use case protects the SRv6 mid-point. https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/. When the SRv6 mid-point fails, the PLR node can perform the next SID operation, which is triggered by FIB miss. However, if there is a summary or default route in the area, FIB Miss cannot be triggered.

Thanks

Zhibo

From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of tony.li@tony.li
Sent: Tuesday, November 17, 2020 2:31 PM
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: lsr <lsr@ietf.org>rg>; Jeff Tantsura <jefftant.ietf@gmail.com>om>; Robert Raszuk <robert@raszuk.net>et>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases


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.


This seems to be making some major assumptions about how path protection features operate. Those assumptions need to be
very explicitly called out.

The path protection features that I’m familiar with are triggered by topological changes along the existing operable path. A PUA
does not provide that.  Rather, it’s something of a temporary signal saying ’this broke’. Without more specifics about the failure, it’s difficult to
understand exactly what path protection should make of this.  If a prefix is unreachable, the obvious implication is that the associated link has
failed.  Path protection in a remote area is highly unlikely to have the topological details necessary to find an alternate path to that prefix.

Tony