IETF Logo Mail Archive

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

Aijun Wang <wangaj3@chinatelecom.cn> Tue, 09 March 2021 00:55 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 1B3C43A1B39; Mon, 8 Mar 2021 16:55:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 6XWm3bjGgeog; Mon, 8 Mar 2021 16:55:17 -0800 (PST)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.220]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE3F3A1B37; Mon, 8 Mar 2021 16:55:17 -0800 (PST)
HMM_SOURCE_IP: 172.18.0.92:58391.1822155855
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-106.121.6.11?logid-61b825635c1744c5aefe56caf07427cd (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with SMTP id 5B7A128008A; Tue, 9 Mar 2021 08:55:15 +0800 (CST)
X-189-SAVE-TO-SEND: 66040164@chinatelecom.cn
Received: from ([172.18.0.92]) by App0021 with ESMTP id 61b825635c1744c5aefe56caf07427cd for wangaijun@tsinghua.org.cn; Tue Mar 9 08:55:19 2021
X-Transaction-ID: 61b825635c1744c5aefe56caf07427cd
X-filter-score: filter<0>
X-Real-From: wangaj3@chinatelecom.cn
X-Receive-IP: 172.18.0.92
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, 09 Mar 2021 08:55:09 +0800
Message-Id: <6E0281D2-7755-499A-B084-CA8472949683@chinatelecom.cn>
References: <22FDE3EA-B5D1-4E4D-B698-1D79173E8637@tony.li>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, Gyan Mishra <hayabusagsm@gmail.com>, "Acee Lindem (acee)" <acee@cisco.com>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>, lsr <lsr@ietf.org>
In-Reply-To: <22FDE3EA-B5D1-4E4D-B698-1D79173E8637@tony.li>
To: Tony Li <tony.li@tony.li>
X-Mailer: iPhone Mail (18D52)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/PSg4LvGPA_e6-sCKNJ-z3tFVoQs>
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 00:55:19 -0000

Hi, Tony:

Aijun Wang
China Telecom

> On Mar 9, 2021, at 08:22, Tony Li <tony.li@tony.li> wrote:
> 
> 
> Hi Aijun,
>> 
>> There are two scenarios as introduced by Gyan: one is the node failure(Scenario 1), and another is the link failure(Scenario 2).
>> 
>> For scenario 1, also when all ABRs can’t reach the specified address, it is not efficient to advertise all of other detail prefixes when only one prefix or some prefixes are missing. The ABRs  tell exactly the specified failure prefixes via PUA message is reasonable.
> 
> 
> If no ABR can reach the address, then there is no point in advertising anything.  The traffic is going to black hole.

[WAJ] We just want to avoid such silent discard behavior, especially for the scenario that there is BGP session run on such failure prefix. 
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.

> 
> 
>> For scenarios 2, because the specified prefixes can be accessed via another ABR, then we can let this ABR to advertise the details prefixes information for the specified address, which behavior is similar with RIFT, as also mentioned in the presentation materials.
> 
> 
> Agreed.

[WAJ] Even for this scenario, the advertisement of the detail prefixes is trigger also via the PUA message from other ABR.

> 
> So, why do we need to punch a hole?
> 
> Tony
> 
>

v2.23.0 | Report a Bug | By Email