Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

Aijun Wang <wangaijun@tsinghua.org.cn> Tue, 16 February 2021 01:17 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673A13A0B44 for <idr@ietfa.amsl.com>; Mon, 15 Feb 2021 17:17:04 -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_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=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 4poVo71YRzgp for <idr@ietfa.amsl.com>; Mon, 15 Feb 2021 17:17:02 -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 1FCDB3A0B3A for <idr@ietf.org>; Mon, 15 Feb 2021 17:17:01 -0800 (PST)
Received: from [240.0.0.1] (unknown [111.194.51.239]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 5BF0F1C0080; Tue, 16 Feb 2021 09:16:58 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-FE070F9B-091F-47E1-83B8-04C976EDF42B"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Message-Id: <46178377-5CA0-42D9-A9BF-7D7AC73F742D@tsinghua.org.cn>
Date: Tue, 16 Feb 2021 09:16:57 +0800
Cc: "UTTARO, JAMES" <ju1738@att.com>, "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>, idr@ietf.org, Susan Hares <shares@ndzh.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (18D52)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZTh9IS0xISUlOSkMZVkpNSkhPSENJSkNPQkxVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0JITVVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Kxw6Fzo5Nz8POSMeHCoxKgM3 NQ8aCzJVSlVKTUpIT0hDSUpDQ05IVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKSkpVSkJPVU5KVUlIQllXWQgBWUFMQkJDNwY+
X-HM-Tid: 0a77a869708bd993kuws5bf0f1c0080
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/s3mD7oYFo1HFDWdmu3fVyDawAB0>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Feb 2021 01:17:04 -0000

Hi, Robert:

Don’t you think Jim’s last comments is contradicted?
After replying this mail to you, I will focus on the discussion on Jeff’s thread. 

Aijun Wang
China Telecom

> On Feb 16, 2021, at 05:31, Robert Raszuk <robert@raszuk.net> wrote:
> 
> Jim, 
> 
> And quite frankly I think you nailed it. 
> 
> If one is to provide a service he better purchase the right gear for it. 
> 
> Not some weak PEs which balance on the cliff of falling under light wind ... 

[WAJ] There are lots of devices within the network, in different locations, from different vendors, bought/upgrade in different time. It is natural that they have different capabilities of wind resistance.

> 
> - - - 
> 
> Mitigations which are deployed in many networks have been suggested. Protect from issue not allow it to happen then try to patch it. 
> 
> Alternative deployment models have been proposed too. 
> 
> Sorry I do not buy the reason stated that mistaken redistribution of the Internet to the VPN will crash the network. Right gear carries Internet in a VRF just fine. And if it crashes ... so be it. Next time folks touching PEs will be more careful. 

[WAJ] The network should have the capability to prevent such thing happen. Is there any operator want to wait for it, do nothing and just give/educate the folks lessons in final?

> 
> I also do not accept as a reason Inter-AS option B or C. If you do not trust your AS peer do A+B or A. 

[WAJ] Trust is one side, protecting oneself is another side. 

> 
> For me this topic is considered closed. 
> 
> Thx,
> Robert.
> 
> 
> On Mon, Feb 15, 2021 at 10:15 PM UTTARO, JAMES <ju1738@att.com> wrote:
>> Here is another fact..
>> 
>>  
>> 
>> It is more like 10+ Million without an issue.
>> 
>>  
>> 
>> Thanks,
>> 
>>               Jim Uttaro
>>