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

From: "Susan Hares" <[email-masked]>
Date: Thu, 4 Feb 2021 10:52:14 -0500

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)? 

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

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

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

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

Cheerily, Sue

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 9 Feb 2021 20:53:05 -0500

Hi,

I am a co-author and support approval of this draft for standards
track publication. See below

On Thu, Feb 4, 2021 at 10:52 AM Susan Hares <[email-masked]> wrote:
> 1) the WG still has to discussion where we make the cutoff for flow-specification v2,
> 1.) Does WG to standardize this technology with the IPR Statement (which appeared in 5/8/2020 after a modification of the draft)?

Yes. (Note this is the same situation as with
draft-ietf-idr-flowspec-l2vpn which has already been approved by the
WG).

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

I believe so.

> 3) Would this technology inter-work with tunnels created by draft-ietf-idr-tunnel-encap-22.txt?

I have reviewed draft-ietf-idr-tunnel-encap-22.txt. It is not clear to
me how idr-flowspec-nvo3 draft could fail to "inter-work" with the
idr-tunnel-encap draft. idr-tunnel-encap specifies an attribute and
community to invoke tunneling for certain traffic. idr-flowspec-nvo3
specifies how to match on certain tunnelled traffic and perform some
actions on such traffic.

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

The situation is pretty much the same, as far as I can see, as in RFC
8956 and draft-ietf-idr-flowspec-l2vpn. flow-specification v2 will
have to take such things into account whether or not this draft
progresses.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 12 Feb 2021 11:35:29 -0800

Dear All,
I've reviewed the draft. I find it well-written and proposing a good
practical solution to the very common case in L3 overlay networks. I
particularly appreciate the coverage of several tunneling protocols that
the draft provides. I've noticed that Geneve protocol (RFC 8926
<https://datatracker.ietf.org/doc/rfc8926/>) is not listed. As a
non-blocking comment, perhaps the case for Geneve can be added to the
document.
In conclusion, I support progressing this document to its publication as
Standard RFC.

Regards,
Greg

On Thu, Feb 4, 2021 at 7:52 AM Susan Hares <[email-masked]> wrote:

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 12 Feb 2021 15:06:31 -0500

On Fri, Feb 12, 2021 at 2:35 PM Greg Mirsky <[email-masked]> wrote:
> Dear All,
> I've reviewed the draft. I find it well-written and proposing a good practical solution to the very common case in L3 overlay networks. I particularly appreciate the coverage of several tunneling protocols that the draft provides. I've noticed that Geneve protocol (RFC 8926) is not listed. As a non-blocking comment, perhaps the case for Geneve can be added to the document.
> In conclusion, I support progressing this document to its publication as Standard RFC.

Hi Greg,

Thanks for your support. Adding Geneve encapsulation to this draft
seems reasonable and I believe it would be easy to do.

Donald

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

---

From: Lizhenbin <[email-masked]>
Date: Wed, 17 Feb 2021 02:09:14 +0000

Hi All,

I support progressing this document to be published as Standard RFC.

Best Regards,
Zhenbin (Robin)

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

Greetings:

Cheerily, Sue

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 17 Feb 2021 17:15:09 +0000

I support moving this document to be published as Standard RFC.

Best Regards,
Linda Dunbar

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

Greetings:

Cheerily, Sue

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 18 Feb 2021 10:49:31 +0800

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: [email-masked] <[email-masked]> On Behalf Of Susan Hares
Sent: Thursday, February 4, 2021 11:52 PM
To: [email-masked]
Subject: [Idr] WG LC - draft-ietf-idr-flowspec-nvo3-12 - Technology only
(2/4/2020 to 2/18/2020).

Greetings: 

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

[WAJ] Yes.

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

[WAJ] Yes

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

Cheerily, Sue

---

From: Chenshuanglong <[email-masked]>
Date: Thu, 18 Feb 2021 03:26:10 +0000

Hi All

Thanks,
Shuanglong

Greetings:

Cheerily, Sue

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 18 Feb 2021 17:40:53 +0530

Hi,

I have read the draft and found it clear and concise and ready for
publication. Is there any extra security consideration because of
tunneled traffic? Even if none, it might be useful to add some
analysis text!

Thanks!
Dhruv

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 18 Feb 2021 12:36:36 +0000

Hi Sue,

I've reviewed this document and support its publication as standard RFC.

Best regards,
Jie

Greetings:

Cheerily, Sue

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 19 Feb 2021 01:32:26 -0500

Hi Sue

I support publication of this document as a standard RFC.

Since this document supports GRE, IP in IP and L2TPv3, even though the
title states NVO3 overlays, should this draft really include all tunnel
types described in tunnel-encap-22 that would be applicable to flow spec
dissemination. If so the then maybe removal of NVO3 in the draft name and
change to tunneled traffic maybe appropriate.

 Yes

 Yes

 Yes.  I think it is very important for this document to support the tunnel
encap draft NVO overlay encapsulations.

4) Should this technology wait for a flow-specification v2?
I don’t think so.  As we are proceeding with modified WG LC without any
implementations i think in that light we can proceed to publish and not
wait for flow spec v2.  At that time we can always to an bis update if
needed to the publication as necessary.

Thank you

Gyan

On Thu, Feb 18, 2021 at 7:37 AM Dongjie (Jimmy) <[email-masked]> wrote:

> Hi Sue,
>
>
>
> I’ve reviewed this document and support its publication as standard RFC.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Susan Hares
> *Sent:* Thursday, February 4, 2021 11:52 PM
> *To:* [email-masked]
> *Subject:* [Idr] WG LC - draft-ietf-idr-flowspec-nvo3-12 - Technology
> only (2/4/2020 to 2/18/2020).
>
>
>
> Greetings:
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 19 Feb 2021 13:17:49 -0500

Hi Gyan,

> I support publication of this document as a standard RFC.

Thanks for your support.

> Since this document supports GRE, IP in IP and L2TPv3, even though the title states NVO3 overlays, should this draft really include all tunnel types described in tunnel-encap-22 that would be applicable to flow spec dissemination. If so the then maybe removal of NVO3 in the draft name and change to tunneled traffic maybe appropriate.

For historic reasons, the file name of this draft has "-nvo3-" in it.
The title of the document used to have NVO3 in it ("BGP Dissemination
of Network Virtualization Overlays (NVO3) Flow Specification Rules").
That was true of versions -00 through -06. However, with version -07
the title was changed to "BGP Dissemination of Flow Specification
Rules for Tunneled Traffic". It would, of course, be possible to
change the file name but the version number would have to be reset to
00 which might be misleading.

The only tunnel type specifically listed in
draft-ietf-idr-tunnel-encaps-22 that is not in
draft-ietf-idr-flowspec-nvo3-12 is MPLS-in-GRE. I'm not sure that is
needed as such. Certainly someone could generate DoS traffic at the
GRE level that said it has MPLS inside the GRE. Some modification of
flowspec-nvo3 to accommodate this would probably be a good idea but
there isn't any matching of MPLS stacks in any of BGP flowspec
currently. So, I think some improvement in the GRE tunnel provisions
in flowspec-nvo3 but I don't think taking on flowspec matching on MPLS
stacks is warranted.

Thanks,
Donald

>  Yes.  I think it is very important for this document to support the tunnel encap draft NVO overlay encapsulations.
>
> I don’t think so.  As we are proceeding with modified WG LC without any implementations i think in that light we can proceed to publish and not wait for flow spec v2.  At that time we can always to an bis update if needed to the publication as necessary.
>
> Thank you
>
>
> Gyan
>
>
> Gyan Mishra
> Network Solutions Architect
>
> M 301 502-1347
> 13101 Columbia Pike
> Silver Spring, MD
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 20 Feb 2021 14:22:13 -0500

Thanks Donald.

This document is ready for publication.

Thanks

Gyan

On Fri, Feb 19, 2021 at 1:18 PM Donald Eastlake <[email-masked]> wrote:

> >  Yes.  I think it is very important for this document to support the
> tunnel encap draft NVO overlay encapsulations.
> >

-- 

*Gyan Mishra*