IETF Logo Mail Archive

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

Aijun Wang <wangaijun@tsinghua.org.cn> Tue, 23 November 2021 11:38 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
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 590BD3A0128 for <lsr@ietfa.amsl.com>; Tue, 23 Nov 2021 03:38:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 dI7Ob9y9-c2T for <lsr@ietfa.amsl.com>; Tue, 23 Nov 2021 03:38:51 -0800 (PST)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3843A0124 for <lsr@ietf.org>; Tue, 23 Nov 2021 03:38:48 -0800 (PST)
Received: from smtpclient.apple (unknown [221.223.96.4]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id B3CF11C1061; Tue, 23 Nov 2021 19:38:38 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-D504009F-B0D0-4049-8B08-5A8433402D4A"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Tue, 23 Nov 2021 19:38:37 +0800
Message-Id: <4FBAD82D-8AD6-486C-A776-A1F1C5D200D2@tsinghua.org.cn>
References: <CAOj+MMGy1qpxcKwVw7ovLcKZAB5oWzxix17Xoq1GzDbnHrx=jg@mail.gmail.com>
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>
In-Reply-To: <CAOj+MMGy1qpxcKwVw7ovLcKZAB5oWzxix17Xoq1GzDbnHrx=jg@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (19A404)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgPGg8OCBgUHx5ZQUlOS1dZCBgUCR5ZQVlLVUtZV1 kWDxoPAgseWUFZKDYvK1lXWShZQUpMS0tKN1dZLVlBSVdZDwkaFQgSH1lBWUJDTBpWSEJPQktIH0 4ZGkJCVRMBExYaEhckFA4PWVdZFhoPEhUdFFlBWVVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6ORQ6Ggw5Nj4COhwVISwcLzkt Pg4aCTZVSlVKTUhMTU1MTkpCS0pJVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSUpVSUlIVUJNVU9ZV1kIAVlBSk5PS0o3Bg++
X-HM-Tid: 0a7d4c973918d993kuwsb3cf11c1061
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/-o_WdpH3-acEgIu0KdDjcnFsP6o>
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:38:55 -0000

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

v2.23.0 | Report a Bug | By Email