Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Robert Raszuk <robert@raszuk.net> Tue, 23 November 2021 10:03 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 D8CF73A0C4A for <lsr@ietfa.amsl.com>; Tue, 23 Nov 2021 02:03:46 -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 tdKibyFoLGbu for <lsr@ietfa.amsl.com>; Tue, 23 Nov 2021 02:03:42 -0800 (PST)
Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 6C3CE3A0C02 for <lsr@ietf.org>; Tue, 23 Nov 2021 02:03:42 -0800 (PST)
Received: by mail-ua1-x92f.google.com with SMTP id p2so42511590uad.11 for <lsr@ietf.org>; Tue, 23 Nov 2021 02:03:42 -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=8loCp5fRFDhJVSc/PLCpFmwJIzY/WQfk7C36Atwkuag=; b=DO63mLD22o4vLdovd0vnZVNraiu2NgVUnVd68QhoHDONbyL1efUNJleVtE7Q4mwGhh CxIg6CTRtX7BXaWeyJzJf3uEC/XAaiMiRskJYIflie3KGNDiJOUQW1OHRZBX9g4BQ6AL aZFz1lz8RFVkwustZx44eUmbqq/qMrhC8jA+DctD3eDpWdyP27j6Vx0iKyZSZoMy/Akx s75AfFMJ0VV2/JxN1Z7EgdeJ1AM8Ux3wVicBYfEj+L23g86UTDrmq1WEa+Hf4lcJkWqr upiEgeZt6nJrZaYlG6vADJVxirE27YrxsVsaiF2d+jiNritgasgH5sU1aUYv2bhOqW0H DRaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8loCp5fRFDhJVSc/PLCpFmwJIzY/WQfk7C36Atwkuag=; b=tJ+lxvJHkDxPeRVVWC+ah5TNzGYpps+aAvVZL+vNunhTNt7wtpHO8nXXz+kQaguRfS 9rdEagslUxjmmiq3NXHkqBstcwZOc3evbo5KfK3BhEetP+F/fNG6sSGgh4iq0CvS1fMh R3R2FDuEGio1hhQw+IhNSk2TS9StDehgqenq7ykzoAwXCzL4966b8aDth38hS+ytRfU0 WNa70Q8/4JTfSpfc9FzRY7vc2d2uMrNw7p9jyjJV4UwDQVhAW9pUYLuUMZOYlQ9+WwAj MKjGupji9gcXkG7MzeUT4J57cd8j6bTUaixce0CybstG7eliDgLKYWWaTVyM77WcdXNp sz7Q==
X-Gm-Message-State: AOAM530IwoCq395ceC0WQ5hMb6amMNm7AnrVPSfHzAzqIqFEwuVlI/U0 XHHfO7cMCi2//RiKN2IHS7iH7zQwYNzpCSP2vsEpgg==
X-Google-Smtp-Source: ABdhPJwRuc8Vek4oFs8k0gbSLzAKTyUMm2y3cu0exSPok+D/EFG+X2Cco6+lJfVN/uYCmxBhbtVc6sDJgQz2iw1TQnE=
X-Received: by 2002:a67:ab48:: with SMTP id k8mr7514917vsh.30.1637661819789; Tue, 23 Nov 2021 02:03:39 -0800 (PST)
MIME-Version: 1.0
References: <62025C40-55E9-4B81-84C7-9A14F1353642@tony.li> <18B5A2FE-2ACE-4B57-997B-6D13CBD49132@tsinghua.org.cn> <F682D8BB-5628-4177-BDCD-EB97D30B7F2A@tony.li> <016301d7df4b$583af8c0$08b0ea40$@tsinghua.org.cn> <23A8E4DF-3882-4127-992C-04E315FBE555@tony.li> <BY5PR11MB4337C76E8C58F025E6E2585DC19F9@BY5PR11MB4337.namprd11.prod.outlook.com> <C3D40822-EA2C-494D-8A69-701279A10776@tony.li> <BY5PR11MB4337BDCFF94B6F86C876B0EFC19F9@BY5PR11MB4337.namprd11.prod.outlook.com> <3BEAD653-2B78-44A0-B801-F94E8C5CFAE6@tony.li> <01b501d7e039$fd8d1bc0$f8a75340$@tsinghua.org.cn> <CAOj+MMGbSWpq8KPS-axmx=WMFfpjtQGD9BUPx8FCNeFMz+JMZA@mail.gmail.com> <000c01d7e049$0adbcb50$209361f0$@tsinghua.org.cn>
In-Reply-To: <000c01d7e049$0adbcb50$209361f0$@tsinghua.org.cn>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 23 Nov 2021 11:03:29 +0100
Message-ID: <CAOj+MMGy1qpxcKwVw7ovLcKZAB5oWzxix17Xoq1GzDbnHrx=jg@mail.gmail.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Gyan Mishra <hayabusagsm@gmail.com>, Christian Hopps <chopps@chopps.org>, Tony Li <tony.li@tony.li>, lsr <lsr@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, Tony Przygienda <tonysietf@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000007f7c805d171dbc2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/WrnEsOh6FQqYmezOa085XaAEZ04>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes
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, 23 Nov 2021 10:03:47 -0000

> When the node is failed, or is detached from the network, it can’t send
the BGP update to other peers already.

LOL ... that's given. Same for IGP too.

The UPDATE will be generated by the BGP peer of such node - typically RR.
And if you run BFD on that session it can be as fast as loosing IGP adj to
an IGP neighbour of the failing node.

Cheers,
R.




On Tue, Nov 23, 2021 at 10:03 AM Aijun Wang <wangaijun@tsinghua.org.cn>
wrote:

> Hi, Robert:
>
>
>
> When the node is failed, or is detached from the network, it can’t send
> the BGP update to other peers already.
>
> And, as we have discussed, the potential usage of such information is not
> only BGP, but may be tunnel endpoints.
>
> Yes, I agree, the light speed is the same.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-bounces@ietf.org <lsr-bounces@ietf.org> *On Behalf Of *Robert
> Raszuk
> *Sent:* Tuesday, November 23, 2021 4:40 PM
> *To:* Aijun Wang <wangaijun@tsinghua.org.cn>
> *Cc:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Gyan Mishra <
> hayabusagsm@gmail.com>; Christian Hopps <chopps@chopps.org>; Tony Li <
> tony.li@tony.li>; lsr <lsr@ietf.org>; Acee Lindem (acee) <acee@cisco.com>;
> Tony Przygienda <tonysietf@gmail.com>
> *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
> LSR Meeting Minutes
>
>
>
> Aijun,
>
>
>
> *> or lose the fast convergences*
>
>
>
> Putting aside all the drawbacks already discussed, what makes you think
> that flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 areas
> would be any faster then sending BGP UPDATE message(s) across 2-3 RRs ?
>
>
>
> Assume you need to detect the failure and react to it in your RP/RE
> regardless how it is signalled. If triggered by ABRs you not only need to
> detect the failure of a node, but also flood it locally within the local
> area.
>
>
>
> Light propagation speed last time I checked does not seems to be different
> for BGP vs OSPF/ISIS packets.
>
>
>
> Thx,
>
> R.
>
>
>