Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Aijun Wang <wangaj3@chinatelecom.cn> Tue, 09 March 2021 06:48 UTC

Return-Path: <wangaj3@chinatelecom.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 F0D123A1509; Mon, 8 Mar 2021 22:48:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gY_cwMgkDrwk; Mon, 8 Mar 2021 22:48:38 -0800 (PST)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCF73A1505; Mon, 8 Mar 2021 22:48:36 -0800 (PST)
HMM_SOURCE_IP: 172.18.0.218:43544.697786415
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-106.121.6.11?logid-85072d768c764ebdb2b84cf60e75230f (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id 1A2812801B8; Tue, 9 Mar 2021 14:47:58 +0800 (CST)
X-189-SAVE-TO-SEND: 66040164@chinatelecom.cn
Received: from ([172.18.0.218]) by App0025 with ESMTP id 85072d768c764ebdb2b84cf60e75230f for draft-wang-lsr-prefix-unreachable-annoucement@ietf.org; Tue Mar 9 14:48:35 2021
X-Transaction-ID: 85072d768c764ebdb2b84cf60e75230f
X-filter-score: filter<0>
X-Real-From: wangaj3@chinatelecom.cn
X-Receive-IP: 172.18.0.218
X-MEDUSA-Status: 0
Sender: wangaj3@chinatelecom.cn
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Aijun Wang <wangaj3@chinatelecom.cn>
Mime-Version: 1.0 (1.0)
Date: Tue, 9 Mar 2021 14:47:52 +0800
Message-Id: <46B987AA-63F1-4B5D-BDBD-166AE6562C57@chinatelecom.cn>
References: <EB1B201E-91CD-44BA-A68A-7DD7C7FA9464@tony.li>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, lsr <lsr@ietf.org>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, Gyan Mishra <hayabusagsm@gmail.com>
In-Reply-To: <EB1B201E-91CD-44BA-A68A-7DD7C7FA9464@tony.li>
To: Tony Li <tony.li@tony.li>
X-Mailer: iPhone Mail (18D52)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/R2lFYFLqt-E-DQJbq5uJ1ZcjV1Q>
Subject: Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05
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, 09 Mar 2021 06:48:41 -0000

Hi, Tony:

Aijun Wang
China Telecom

> On Mar 9, 2021, at 12:32, Tony Li <tony.li@tony.li> wrote:
> 
> 
> Hi Aijun,
> 
>> Stuffing things in the IGP seems like a poor way of determining that there’s a BGP failure.  Wouldn’t BFD be a more appropriate way of determining the loss of connectivity?  Or aggressive BGP keepalive timers?
>> [WAJ] For BFD, you need to configure between each pair of them to track the connectivity.  For BGP keeplive times, the duration is too long.
> 
> 
> You have to configure BGP on both sides too.

[WAJ] Aim is the BGP process acts upon the PUA message automatically.

> 
> Most implementations do allow you to change the timers.

[WAJ] it is not efficient as the event trigger mechanism. It is the same comparison between Poll and Push/Notify mechanism.


> 
> 
>>> The other side of BGP peer can quickly remove the BGP session when it receives such PUA message which tell it the other peer is down now. Other BGP peer protection procedures can then take effects on.
>>> The immediate notification of the failure prefix can certainly accelerate the switchover of BGP control plane and also the service traffic that such BGP session carries.
>> 
>> 
>> The IGP is a very poor way of delivering service liveness information.
>> [WAJ] why? 
> 
> 
> Because it’s not a service (un)availability protocol. It’s a reachability and path computation function.  That is it’s role in the architecture.  Asking it to do something else is a violation of the architecture.
> 
> Routing protocols are not transport protocols. Or dump trucks. Or service advertisement protocols.

[WAJ]Here I think you can consider the ABR router advertises the wrong summary information and should correct itself via the PUA message. Action on the PUA message is the following optimize treatments.

> 
> 
>> That seems 100% unnecessary as the longer prefix will attract the traffic in the way that you want.
>> [WAJ] If the ABR advertises such detail prefix, it will certainly attract the traffic. But here the PUA message is just to trigger the ABR to advertise such detail prefix, or else, such ABR will still advertise the summary address.
> 
> 
> You don’t need the PUA message. The ABR can see the loss of topology and can realize that it’s the best path to the prefix and can then advertise the explicit longer prefix in addition to the normal summary.

[WAJ] The advertise of the details prefixes only occurs when some of the ABRs can reach the prefixes, but some can’t reaches.
If there is no PUA message, how can one ABR knows other ABRs can’t reach the prefixes? It can only know whether itself can reach or not.
Or else, you should require the ABR run SPF on behalf of other ABRs?

> 
> Tony
> 
>