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

Robert Raszuk <robert@raszuk.net> Tue, 23 November 2021 11:42 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 1706C3A0529 for <lsr@ietfa.amsl.com>; Tue, 23 Nov 2021 03:42:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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] 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 cJpchZBKma7E for <lsr@ietfa.amsl.com>; Tue, 23 Nov 2021 03:42:03 -0800 (PST)
Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (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 E43A73A0124 for <lsr@ietf.org>; Tue, 23 Nov 2021 03:42:02 -0800 (PST)
Received: by mail-vk1-xa2e.google.com with SMTP id b125so12186384vkb.9 for <lsr@ietf.org>; Tue, 23 Nov 2021 03:42:02 -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=i+vlA/NPKB8tWkgZvj3kcIh+L+cahqtCyD/XXLUKqos=; b=fYeb/YWmsOaUMfNRc7JBCq4FEpxLyFC/g0UYba9SBhMVW4SfQ3Xp1uy8MMHB42MUsH 2vnjMTk7/jH4POWG4K076ouqo/XlwU7MyxCKLk3YVZUyVsm58ZNW3KPgOooF2mqwqJ9a imHhnSwCHCg3Hk6nrWef8q4DiuUNJfkbE8ivpWlC8SSa8BDHcM72QY6crz/KrxN/cqwy 80duIqXz59U7sU6NmCK1/dZEcqW6EOWN+NIUtx6wXEHfIZz34oIr1JC/bqCrTOFf+SUx uuXN4rTKlXkyj7lSTt5BJ9I5UmCQepuYopsnOf3BeZkvSz/i97GjlLsKp+ZPPptlfvlR v1rg==
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=i+vlA/NPKB8tWkgZvj3kcIh+L+cahqtCyD/XXLUKqos=; b=ZSimDkWXGWTLxAKY+m1II2nuTiPd/h9bRPyuDRPRHBcXKcERdYUng5kco6kn9UkRre Q+kkPo0W+H8S5D4fLQ6kwlG/CubOewiZKz13V3j5OYpIHBzfK7VkQvaoZOT98YxlORee oECugLB1eOKte7J0Qv9bM3THkvah/4arrexYolGbLFvfdVUvlWAuzDuHNwTc53qw5bAN A9Xdij9CU0HtCKoCSnDD4fE6oCKDlLQ7bc8NkkrcBLEFkxZ2r0CWUZs6rVCN4l5hza0X Z337DDe88ARKJpdqnPT2ETzmXeyDt6ANf3VB9oe4wekf908e9TjZplyhDUfrxQqqLXuX 5y6g==
X-Gm-Message-State: AOAM530KzpLX4sKdm88e+TaZVkymaH/MtNohdsfa0jlqMpSk5G7tPKlV pYEq5rij58LGdff6vWtxcedXyZzkEDc0GCKdKIlDQw==
X-Google-Smtp-Source: ABdhPJyTnivwUQApg5i2en3umrApyBSZ++1aYLgupF/lmsxo1oIyYYX38N2GAmVHSt8kvZ37A5szEcsyRV7FR6pRGTc=
X-Received: by 2002:a05:6122:214e:: with SMTP id m14mr9537440vkd.19.1637667720737; Tue, 23 Nov 2021 03:42:00 -0800 (PST)
MIME-Version: 1.0
References: <CAOj+MMGy1qpxcKwVw7ovLcKZAB5oWzxix17Xoq1GzDbnHrx=jg@mail.gmail.com> <4FBAD82D-8AD6-486C-A776-A1F1C5D200D2@tsinghua.org.cn>
In-Reply-To: <4FBAD82D-8AD6-486C-A776-A1F1C5D200D2@tsinghua.org.cn>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 23 Nov 2021 12:41:49 +0100
Message-ID: <CAOj+MMEm+rdY=ULUAxyMZVzzefL208S1ayc7BBVEp9_JoWvCWQ@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="000000000000c1463405d1733a64"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Un0PXwsduPviXUvhe8L9ugrAUYE>
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 11:42:08 -0000

> For IGP solution, the BFD is not required.

Excuse me ?

BFD is used on vast majority of the WAN links today as those links are not
always dark fiber such that you can detect LOS. Those WAN links are
(unfortunately) emulated circuits which require BFD to detect failure in a
reasonable time.

I hope you are not talking about IGP hellos or BGP keepalives here.

We are talking PE-P or PE-RR.

Thx,
R.



On Tue, Nov 23, 2021 at 12:38 PM Aijun Wang <wangaijun@tsinghua.org.cn>
wrote:

> Hi, Robert:
>
> Aijun Wang
> China Telecom
>
> On Nov 23, 2021, at 18:04, Robert Raszuk <robert@raszuk.net> wrote:
>
> 
>
> > 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.
>
> [WAJ] Then you depend again the BFD session which there is configuration
> overhead. For IGP solution, the BFD is not required.
> And, for tunnels situations, where you configure the monitor peer?
>
> Aijun Wang
> China Telecom
>
>
> 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.
>>
>>
>>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>