Re: [Idr] WG LC - draft-ietf-idr-flowspec-nvo3-12 - Technology only (2/4/2020 to 2/18/2020).

Aijun Wang <wangaijun@tsinghua.org.cn> Thu, 18 February 2021 02:49 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 3B0AE3A1F24 for <idr@ietfa.amsl.com>; Wed, 17 Feb 2021 18:49:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 34Gk0-QpReLn for <idr@ietfa.amsl.com>; Wed, 17 Feb 2021 18:49:36 -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 3FCD73A1F13 for <idr@ietf.org>; Wed, 17 Feb 2021 18:49:35 -0800 (PST)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 22BE81C00CD; Thu, 18 Feb 2021 10:49:32 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: 'Susan Hares' <shares@ndzh.com>, idr@ietf.org
References: <012d01d6fb0d$b50468c0$1f0d3a40$@ndzh.com>
In-Reply-To: <012d01d6fb0d$b50468c0$1f0d3a40$@ndzh.com>
Date: Thu, 18 Feb 2021 10:49:31 +0800
Message-ID: <04dc01d705a0$af26a290$0d73e7b0$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_04DD_01D705E3.BD4AF400"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQE5ipLZCEMJAsA2CFkkCB7gfcHPSKuYKB5A
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZT0pNH0sdQh0fH0saVkpNSkhNSk1OTElITUpVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0JITVVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Mkk6Txw6MD8WSCI4ODkrATgP FgIwChBVSlVKTUpITUpNTkxJTElLVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpITkNINwY+
X-HM-Tid: 0a77b30ae731d993kuws22be81c00cd
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/4BFv4lGSBgHBqRlJAugLdePacQk>
Subject: Re: [Idr] WG LC - draft-ietf-idr-flowspec-nvo3-12 - Technology only (2/4/2020 to 2/18/2020).
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: Thu, 18 Feb 2021 02:49:41 -0000

HI, Susan:

 

I have read this documents and support its forwarding.

Wish the authors can have thoughts or some statements for the following
considerations in the next version:

The document should have some places to describe what the devices should do
when the "Tunnel Type" and "Tunnel Header Flowspec" does not match. 

Or Is this one the general problem for current flowspec RFC? 

 

Answers to your question inline below [WAJ]

 

Best Regards

 

Aijun Wang

China Telecom

 

From: idr-bounces@ietf.org <idr-bounces@ietf.org> On Behalf Of Susan Hares
Sent: Thursday, February 4, 2021 11:52 PM
To: idr@ietf.org
Subject: [Idr] WG LC - draft-ietf-idr-flowspec-nvo3-12 - Technology only
(2/4/2020 to 2/18/2020).

 

Greetings: 

 

This begins a modified draft-ietf-idr-flowspec-nvo3-12.txt. 

 

It is a modified WG LC because:

1) the WG still has to discussion where we make the cutoff for
flow-specification v2, 

2) there are no implementation for this WG LC

 

This WG LC should examine the following things: 

 

1.) Does WG to standardize this technology with 

the IPR Statement (which appeared in 5/8/2020 after a modification of the
draft)? 

[WAJ] Yes.

 

2) Is this approach to flow-specification for tunnels ready for
standardization?

[WAJ] Yes when they add some statements for the above comments.

 

3) Would this technology inter-work with tunnels created by 

 draft-ietf-idr-tunnel-encap-22.txt? 

[WAJ] Yes

 

4) Should this technology wait for a flow-specification v2? 

[WAJ] Can forward it directly. Implementation and deployment of this
solution can feed back to design of flow-specification v2 then.

 

Cheerily, Sue