IETF Logo Mail Archive

Re: [Lsr] Prefix Unreachable Announcement Use Cases

tony.li@tony.li Tue, 17 November 2020 06:31 UTC

Return-Path: <tony1athome@gmail.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 CFECA3A101A for <lsr@ietfa.amsl.com>; Mon, 16 Nov 2020 22:31:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 afxF_exfTl86 for <lsr@ietfa.amsl.com>; Mon, 16 Nov 2020 22:31:15 -0800 (PST)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 403253A1003 for <lsr@ietf.org>; Mon, 16 Nov 2020 22:31:15 -0800 (PST)
Received: by mail-pf1-x433.google.com with SMTP id t8so278172pfg.8 for <lsr@ietf.org>; Mon, 16 Nov 2020 22:31:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Qnu9oLL40I2GblavovRvl40z2rLbf1XwpYJ9RQSMwRY=; b=ErHxR2/sPw0+QKX4H7IhzdqtRNvjReH7VHu2r7lF1T2BiSseVvVFtFu+bKZQzLmavQ oGD/6pdeBTUKqNEKWK7UdFmJg+fCUWd8e8tmEk7rrJpa76YLUG8jEq/HFxtdIooiTaK7 muYFnXws8xt0eRxqyMAR5IpAl6NeJnJFQNH90LVvMLa3EEJiObKNjNtQglHH9IwUtJOH L012ERJkalVVeWJsK1JdnF4zk2Z/56N3li5XWrLspUHUOvSyP7R9BHxHDwNVHv7nU+VM iP5Cu/o9JxPrQPuDa5WKuugMwEDwlDtTez50gX770LuQSPZ2mBOQfZiClktoSfcgkfgR nhRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Qnu9oLL40I2GblavovRvl40z2rLbf1XwpYJ9RQSMwRY=; b=joYV8wz87QLw/DNAoVaR87o+jqj+3+lEned5FS5gX+4hjUpw2DJgU/9jhar3rkmwlI JUEM+M7SkxjKjdf/x9cS3CCdyryXvi61gse6uQlQDYzxiCYbIBP2Avyab6QuGyBXqe+H hv+ILXzMCZ6Ti2pDTL2mdTs2rNVGGnRxYIcBmolPyTf79WrRYs+sPKegSdA1VCyL+KNJ 10Xpgh8yuLvp5q4iXW1bOYO3HdyFmU6Qg1xiajUKVAPar/5r3HTK3CFVEQcc88QAi2Tw QchaV+3pljpARz1ZjNwXK3GiQM1WARSZxl3H/e/s7C86zXO8+P/wqisuc1ZATldNHRo7 4niA==
X-Gm-Message-State: AOAM531ba6SuoqR/vYJ/2Bcm2O0TUlpBfMeWSGxY/7zbzEGzC6XNBQIS U32M5ED+efjCpkquQO+fHAU=
X-Google-Smtp-Source: ABdhPJyDg9+gNk6OpEIPo0FkZIMHksXcwdC9fvWJANtceMaLXkOMXt0tZALX1/WKE5BgN4aDjnwNRg==
X-Received: by 2002:a17:90a:6907:: with SMTP id r7mr3286253pjj.208.1605594674675; Mon, 16 Nov 2020 22:31:14 -0800 (PST)
Received: from [192.168.4.24] (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id 15sm2109673pjy.0.2020.11.16.22.31.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2020 22:31:14 -0800 (PST)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <4CCB3F3C-8537-4072-8763-D4B3C557EBD9@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_71F65CCC-1DF6-43EB-91DF-C8C726696AB8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 16 Nov 2020 22:31:12 -0800
In-Reply-To: <016b01d6bca9$cf908c20$6eb1a460$@tsinghua.org.cn>
Cc: Jeff Tantsura <jefftant.ietf@gmail.com>, Robert Raszuk <robert@raszuk.net>, lsr <lsr@ietf.org>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
References: <CAOj+MMH7zRaXNJTRC0ua7ohasUpo0MmeqgzcU9BdpcD7wD+Yrg@mail.gmail.com> <D477846E-1086-46A8-B2D6-E552623E2643@gmail.com> <016b01d6bca9$cf908c20$6eb1a460$@tsinghua.org.cn>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/O9ssH1epul0YPumuW1HuIqQUjqI>
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:31:17 -0000

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

v2.23.0 | Report a Bug | By Email