Re: [Idr] WG adoption call - draft-li-idr-flowspec-srv6-05,txt

Susan Hares <> Fri, 30 July 2021 13:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0DC73A2AED; Fri, 30 Jul 2021 06:50:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.348
X-Spam-Level: *
X-Spam-Status: No, score=1.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8MfqFlDph9Bs; Fri, 30 Jul 2021 06:50:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB7793A0B92; Fri, 30 Jul 2021 06:50:29 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: Susan Hares <>
To: "'Ketan Talaulikar (ketant)'" <>,,
References: <022201d77fe3$eb9ba9b0$c2d2fd10$> <> <00c801d78544$82862a20$87927e60$> <>
In-Reply-To: <>
Date: Fri, 30 Jul 2021 09:50:21 -0400
Message-ID: <013301d78549$d6ef1ae0$84cd50a0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0134_01D78528.4FE012F0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHSMA+SzG3WNAYeCjdPMBqg8QJxWwKU/A8uAqFp45ECNB1xlasq2YDw
Content-Language: en-us
Archived-At: <>
Subject: Re: [Idr] WG adoption call - draft-li-idr-flowspec-srv6-05,txt
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: Fri, 30 Jul 2021 13:50:35 -0000



[WG chair hat on]

The IDR chairs determined after the June 7th interim discussion on Flow
specification options, that the WG desired only DDoS usage cases to be
standardized in v1.   For notes on the interim, see



Therefore, the full draft status indicates which  current IDR drafts are
classified for v1 encoding and which drafts are classified for v2 encoding.


The proposal for flowspec-v2 main draft has author these drafts pushed to
flow-specification v2. We are looking to start a WG adoption call in
September for the base draft. 


The existing IDR drafts listed for flow-specification v1 are:  

a) draft-ietf-idr-flowspec-redirect-ip-02.txt,  

b) draft-ietf-idr-flowspec-path-redirect, and 

c) draft-ietf-idr-flowspec-interfaceset. 


Anyone wishing to provide a v1 flow specification draft, 

must carefully address the use case and acknowledge

the flow-specification v1 ordering issues in the draft. 

 [WG hat off]


[Individual contributor hat on] 

Jeff Haas provided several options for alternatives to v1

to solve the term ordering problems and TLV encodings. 

The WG did not adopt these issues.  


Based on Jeff's work, the flow specification v2 issues

on TLV and capability issues are well-known. 


I hope we can adopt a v2 specification in September

and get rapid development of flow-specification v2 



Cheers, Sue 


From: Ketan Talaulikar (ketant) [] 
Sent: Friday, July 30, 2021 9:26 AM
To: Susan Hares;;
Subject: RE: [Idr] WG adoption call - draft-li-idr-flowspec-srv6-05,txt


Hi Sue,


Thanks for that clarification and I did notice that in your email. 


However, the draft does not mention that it is for flowspec v2 and I don't
see any reference to any work that the WG has adopted for flowspec v2 - all
pointers are to flowspec v1. Therefore these questions. It should not happen
that these get implemented/deployed as proposed in the draft using the v1
framework. The authors should fix that in the draft text before considering


Can this proposal be considered/implemented in the (v1) way that is
proposed? I do not flow Flowspec closely to be sure of the answer.


I would have thought that the WG first adopts the v2 framework/approach and
then the v2 feature extensions? 


In any case, I will leave these aspects to the chairs.





From: Susan Hares <> 
Sent: 30 July 2021 18:42
To: Ketan Talaulikar (ketant) <>;;
Subject: RE: [Idr] WG adoption call - draft-li-idr-flowspec-srv6-05,txt




The authors have indicated draft-li-idr-flowspec-srv6-05.txt is for v2 (see
my WG Call).   I look forward to the author's response to the remainder of
the questions. 


I hope authors will consider presenting at the 9/13/2015 Interim meeting
where we discuss the flow specification v2 base specification and drafts.  




From: Ketan Talaulikar (ketant) [] 
Sent: Friday, July 30, 2021 8:19 AM
To: Susan Hares;;
Subject: RE: [Idr] WG adoption call - draft-li-idr-flowspec-srv6-05,txt




I have reviewed and have
the following questions for the authors before we consider adoption.


1.	FlowSpec v1 is supposed to be focussed on the DDOS use-case. I don't
find any text in the draft that clarifies how/why this is related to DDOS
use-case. To me, this seems like something for FlowSpec v2. Per (what I
understood to be) WG consensus, this work is then perhaps deferred to v2.
2.	The draft proposes a new type "Whole SID". My understanding from the
text is that this rule applies to the IPv6 DA and not the segments within
the SRH. If so, then:

a.	What distinguishes a SID from any other IPv6 address in the DA
b.	Why isn't the existing IPv6 DA type not sufficient?

3.	The draft proposes a new type "Some bits of SID (SBoS)". Again, I
believe this applies to the IPv6 DA again - so the same two Qs above apply
to this type to. What prevents a router (mistakenly) applying this rule to
packets with non-SRv6 SID in their DA.
4.	When the SBoS type is used, the SRv6 SID structure MUST be indicated
as part of the rule. Then the parts of the SID of interest that need to be
matched are also given in the space for the SID. Is my understanding
correct? If so, the text was not very clear to me.
5.	The question of why this SBoS type is required again crops us since
the base FlowSpec rule for DA does allow pattern matching on the IPv6 DA as
well? Perhaps I am mistaken, and if so the document does not provide any
text or justification for why these new types are required.
6.	Finally, there is no text related to the specific applicability
scenarios for these extensions. Exactly why it is difficult to determine
whether this falls under v1 or v2 scope.





From: Idr <> On Behalf Of Susan Hares
Sent: 23 July 2021 22:28
Subject: [Idr] WG adoption call - draft-li-idr-flowspec-srv6-05,txt


This begins a 2 week WG adoption call for draft-li-idr-flowspec-srv6-05.txt.


I am missing 3 IPR statements (Zhenbin Li , Lei Li , and Lei Liu).  

These authors should send in their IPR statements in response to this call. 


This draft is targeted for the V2 version of flow specification.  

Flow specification v2 draft will be discussed at an interim on 9/13/2021. 


If it is adopted, it will be developed as part of the v2 set of drafts. 


Please consider if: 


1) if this draft is useful for networks, 

2) if you wish to adopt this draft prior to adopting flow specification v2. 


Cheerily, Susan Hares