Re: [Lsr] Prefix Unreachable Announcement Use Cases

Robert Raszuk <robert@raszuk.net> Wed, 18 November 2020 07:38 UTC

Return-Path: <robert@raszuk.net>
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 3AABA3A0CE3 for <lsr@ietfa.amsl.com>; Tue, 17 Nov 2020 23:38:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 okgeFkfjsbiw for <lsr@ietfa.amsl.com>; Tue, 17 Nov 2020 23:38:39 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F743A1512 for <lsr@ietf.org>; Tue, 17 Nov 2020 23:38:23 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id 74so1555206lfo.5 for <lsr@ietf.org>; Tue, 17 Nov 2020 23:38:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r3+11cC/4bYBolzdk/6dsNNlW5w0/esX0r25vtQFP7c=; b=TZtStZH5YsPn8C9pMTMsTqXrQ0QnqIVnnlTl7oWk0xpKXyO5FX7fsxOPngFBH6/GOP nll5vMWcjur2x69xqBZe6Bmc2Izf+6MByFOVRatyPx7uCKTQkYhI/3MlPjRXiqagMSOp nfQEwQ3Qyu75XGiZjvD0g5jmbezCupwlc2wuRPB+JCTI40VHj2PE7g6qU+WXmVXXxPz7 5ta40QEVIaX8aKvhd+Xha0d73G/W/dC+SvHfKMIcAvStjTpp7OudIlMjJLCSYsFVyfKB /Z+WiZzzkPcOp+5D5h8g9AYBL67Zj9hL0afz4+8WM5EwxVPTxlnVVQ5834TOc8gfYsCu +uXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r3+11cC/4bYBolzdk/6dsNNlW5w0/esX0r25vtQFP7c=; b=BFabsHBuBRmreYD3h0nSnzWEFrhZlbYQ41g0RClyjWPSp1OWVgltNio9Flo8G0EUcj ACzkkwqr94ssvrl2ezddRXDhaHdmC6bbdX1WC3YD0LVsLGG4P7QpeLEgA24mWHLAb0v3 LE3KS/x7ddgS8IAmSQJycPFWvtFVE8AIgYIb10OJTTcImdDZOo+7hkH9AyHOsuu43/xH D08upr3H6YkSOIJa07+3vfwIB1C3QekMRkcLj8jQbFAQNoH/CK/XyvJtlNuaYLztJmzO POEFMqeP0qdzx9nkS0maRd/zeV345Kd3fIYbxqah86fewZswbRQR7j8HxeLaPfIGEyW5 742A==
X-Gm-Message-State: AOAM531aa5knVKAsYTHP64Y/lphFNfyQNa1BBrkOz+MDZ5m5V871JXaz A6Lk+DRYRQvdtgRpEaf/qx1fB/P+Mmc/MaVdCCahTw==
X-Google-Smtp-Source: ABdhPJwMjGkXg1sMf6YsYiY9SgZJ2n0Ga0umz8ZoRZsVGebgrVp8/Rrt/bwPPsw6+0KoarSUmVNRJNf11xBBWWuV32M=
X-Received: by 2002:ac2:5219:: with SMTP id a25mr3306336lfl.264.1605685101596; Tue, 17 Nov 2020 23:38:21 -0800 (PST)
MIME-Version: 1.0
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> <d8c4497b5910457cad2691479d8c365d@huawei.com>
In-Reply-To: <d8c4497b5910457cad2691479d8c365d@huawei.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 18 Nov 2020 08:38:11 +0100
Message-ID: <CAOj+MMHLhqjuV5TSLwSor8n3Trup6XGntfBKYOSP_qikC1TQYA@mail.gmail.com>
To: Huzhibo <huzhibo@huawei.com>
Cc: "tony.li@tony.li" <tony.li@tony.li>, Aijun Wang <wangaijun@tsinghua.org.cn>, lsr <lsr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001a322905b45cb2cd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Q3wei9z6RR2cxlQtWw6X2KPBV5o>
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 07:38:41 -0000

Hi Zhibo,

> However, if there is a summary or default route in the area, FIB Miss
cannot be triggered.

If PUA is a /dev/null route this is not a FIB miss. It's a FIB hit.

Thx,
R.

On Wed, Nov 18, 2020 at 3:36 AM Huzhibo <huzhibo@huawei.com> wrote:

> 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
>
>
>