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

Aijun Wang <wangaijun@tsinghua.org.cn> Tue, 09 March 2021 01:14 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 7F29E3A1B87; Mon, 8 Mar 2021 17:14:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 3NAmoaIwdZBM; Mon, 8 Mar 2021 17:13:58 -0800 (PST)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 355453A1B84; Mon, 8 Mar 2021 17:13:57 -0800 (PST)
Received: from [240.0.0.1] (unknown [106.121.6.11]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 2BF881C017F; Tue, 9 Mar 2021 09:13:50 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-3248E349-D8ED-45C8-AE09-5307B6CD8E17"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Tue, 09 Mar 2021 09:13:49 +0800
Message-Id: <7CA2E614-F8A6-40A7-8507-CF45F7DB0F49@tsinghua.org.cn>
References: <439DD1F9-9924-405F-9FBD-6704D85B05D6@cisco.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, Aijun Wang <wangaj3@chinatelecom.cn>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>, lsr <lsr@ietf.org>
In-Reply-To: <439DD1F9-9924-405F-9FBD-6704D85B05D6@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
X-Mailer: iPhone Mail (18D52)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZGBlJSUpIQkpJGBgZVkpNSk5JTklPSEtISUNVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0hOT1VLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6K0k6Egw*Tz8KPQ8ONTgrDy83 TioKCUlVSlVKTUpOSU5JT0hLTExNVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS01VSklKVU1VSkpZV1kIAVlBSkhPSEM3Bg++
X-HM-Tid: 0a78148c1d67d993kuws2bf881c017f
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/UqEwj1ZoJ9cUCQ9RlvMrvCq6RkA>
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 01:14:02 -0000

Hi, Acee:

Let me state my considerations for your questions.

Aijun Wang
China Telecom

> On Mar 9, 2021, at 08:37, Acee Lindem (acee) <acee@cisco.com> wrote:
> 
> 
> Speaking as a WG member:
>  
> Hi Gyan,
>  
> The first question is how do you know which prefixes within the summary range to protect? Are these configured? Is this half-assed best-effort protection where you protect prefixes within the range that you’ve installed recently? Just how does this work? It is clearly not specified in the draft.

[WAJ] Currently, we consider PUA is one generic notification for the failure prefixes. The ABR can detect the failure prefixes within its attached areas.
There will only two kinds of nodes will react on the PUA message:
One is the receiving side that run BGP session on such failure prefixes(accelerate the BGP switchover procedures), the other is the other ABRs(advertising the detail prefixes if it can reach the prefixes that notified by the receiving PUA)


>  
> The second comment is that using the prefix-originator TLV is a terrible choice of encoding. Note that if there is any router in the domain that doesn’t support the extension, you’ll actually attract traffic towards the ABR blackholing it.

[WAJ] No. if such router doesn’t support the extension, it will not advertise the PUA message, nor will it act on such message.
>  
> Further, I think your example is a bit contrived. I’d hope that an OSPF area with “thousands” of summarized PE addresses wouldn’t be portioned by a single failure as in figure 1 in the draft and your slides.
> I also that the option of a backbone tunnel between the ABRs was removed from the draft since it diminished the requirement for this functionality.
[WAJ]Tunnel should only be used in some extreme scenarios. For example, when all ABRs can’t advertise the PUA or detail reachable prefixes. We can discuss this later.
>  
> Thanks,
> Acee
>  
> From: Gyan Mishra <hayabusagsm@gmail.com>
> Date: Monday, March 8, 2021 at 6:57 PM
> To: Acee Lindem <acee@cisco.com>, Aijun Wang <wangaj3@chinatelecom.cn>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>, lsr <lsr@ietf.org>
> Subject: https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05
>  
>  
> Acee. 
>  
> Please ask the two questions you raised about the PUA draft so we can address your concerns.
>  
> If anyone else has any other outstanding questions or concerns we would like to address as well and resolve.
>  
> Once all questions and  concerns are satisfied we would like to ask for WG adoption.
>  
> Kind Regards 
>  
> Gyan
> --
> 
> 
> Gyan Mishra
> Network Solutions Architect 
> M 301 502-1347
> 13101 Columbia Pike 
> Silver Spring, MD
>