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

Aijun Wang <> Thu, 18 February 2021 02:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B0AE3A1F24 for <>; Wed, 17 Feb 2021 18:49:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.896
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 34Gk0-QpReLn for <>; Wed, 17 Feb 2021 18:49:36 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FCD73A1F13 for <>; Wed, 17 Feb 2021 18:49:35 -0800 (PST)
Received: from DESKTOP2IOH5QC (unknown []) by (Hmail) with ESMTPA id 22BE81C00CD; Thu, 18 Feb 2021 10:49:32 +0800 (CST)
From: Aijun Wang <>
To: 'Susan Hares' <>,
References: <012d01d6fb0d$b50468c0$1f0d3a40$>
In-Reply-To: <012d01d6fb0d$b50468c0$1f0d3a40$>
Date: Thu, 18 Feb 2021 10:49:31 +0800
Message-ID: <04dc01d705a0$af26a290$0d73e7b0$>
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-Tid: 0a77b30ae731d993kuws22be81c00cd
Archived-At: <>
Subject: Re: [Idr] WG LC - draft-ietf-idr-flowspec-nvo3-12 - Technology only (2/4/2020 to 2/18/2020).
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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: <> On Behalf Of Susan Hares
Sent: Thursday, February 4, 2021 11:52 PM
Subject: [Idr] WG LC - draft-ietf-idr-flowspec-nvo3-12 - Technology only
(2/4/2020 to 2/18/2020).




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

[WAJ] Yes.


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

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


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


[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