Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

["Smith, Donald" <[e-mail]>]

Agreed, except data plane not service plane.



Well maybe both define service plane :)



I think service plane is data plane plus N(control plane) + M(mgmt. plane).

Where N and M are constant multipliers to show effect data could have on other planes.

Is that what you meant by service plane or am I totally off?



01100101000010|10011010111101?
Hint 7 bit ascii
[e-mail]<mailto:[e-mail]>
________________________________
From: Idr [[e-mail]] on behalf of Van De Velde, Gunter (Nokia - BE) [[e-mail]]
Sent: Thursday, April 28, 2016 1:31 AM
To: Susan Hares; John G. Scudder
Cc: [e-mail]
Subject: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

Hi John, Sue,

Its been a while since WG adoption call ended for a few Flowspec drafts. I want to touch base again on the status of this adoption call.


draft-vandevelde-idr-flowspec-path-redirect received a significant number of positive support feedback to support on the list and during the IDR WG meeting in Buenos Aires. The support was received from a very diverse set of contributors and affiliations. This work is timely and ready for adoption and covers DDoS redirection towards an appropriate service plane well.


Kind Regards,

G/


From: Idr <[e-mail]<mailto:[e-mail]>> on behalf of Susan Hares <[e-mail]<mailto:[e-mail]>>
Date: Sunday 10 April 2016 at 21:12
To: 'Gunter Van De Velde' <[e-mail]<mailto:[e-mail]>>, 'Zhuangshunwan' <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

Gunter and Shunwan:

Thank you for your input on this topic.   John and I receive a lot of input individually from 3/25 to 4/8, and began discussions with our AD (Alvaro).

John and I will discussing this adoption call during the upcoming week.  Any drafts that are adopted for the Flow Specification will be IDR Working Group (WG) Drafts.  As such, these drafts become the result of the consensus of the working group under the direction of the WG chairs.   WG drafts may be requested to be: a) merged with other WG drafts, b) split into 2+ drafts, or c) refined.

Cheerily,

Sue Hares

From: Idr [mailto:[e-mail]] On Behalf Of Gunter Van De Velde
Sent: Saturday, April 09, 2016 9:57 AM
To: Zhuangshunwan
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016


Dear Shunwan

With the adoption call ended, the IDR chairs can use the received input and combine it with draft submit timeline info (some work is as old as +7months). I personally do not see a need to merge as vandevelde-flowspec-idr-path-redirect covers already the goal effectively and afficiently

From the link you provided referencing a quote as old as September 2015!!!.. It is all still valid. One reserved bit was used to add SR binding index identifyer for segment routing use case way before even
draft-li-idr-flowspec-redirect-generalized-sid-00 existed...

***

From September 2015:

> Benefits:
>
> no need for signalling labels or extra encap in BGP
> Each path-id indexed LSP/tunnel table is a localised construct
> existing technology is used to construct the path-id indexed localised table
> Compatibility with technologies already using 32 or 128 bit identifiers for
> paths and sessions
> Easy for flow spec to signal as it introduces no need to signal labels etc¡­
> no conflicts with existing label exchange technologies

***

G/

Sent using CloudMagic Email<https://cloudmagic.com/k/d/mailapp?ct=pa&cv=8.3.8&pv=6.0.1&source=email_footer_2>

On Sat, Apr 09, 2016 at 10:19 AM, Zhuangshunwan <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ignas and all,

Regarding draft-vandevelde-idr-flowspec-path-redirect & draft-li-idr-flowspec-redirect-generalized-sid-, here are the achieved discussion information about "Semantics Independent" Flowspec:
https://www.ietf.org/mail-archive/web/idr/current/msg15081.html


01) draft-vandevelde-idr-flowspec-path-redirect ever said that it planned to define ¡°Semantics Independent¡± action.
Per the comment information, draft-vandevelde-idr-flowspec-path-redirect-00 & draft-vandevelde-idr-flowspec-path-redirect-01 defined the "Semantics Independent" Flowspec Redirection:

https://www.ietf.org/archive/id/draft-vandevelde-idr-flowspec-path-redirect-01.txt
¡­
This document defines a new BGP extended community.
¡­
The 2-byte local administrator field is formatted as shown in Figure 1.
                      0                   1
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |          Reserved       |TID|C|
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


02) draft-li-idr-flowspec-redirect-generalized-sid-00 defined a "Semantics Dependent¡± Flowspec Redirection:
https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized-sid/
¡­
   This document defines the following Redirect to Generalized Segment
   ID Extended Community:


   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type=TBD1     | Sub-Type=TBD2 | Flags(1 octet)| Segment Type  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Generalized Segment ID                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¡­


03) Now draft-vandevelde-idr-flowspec-path-redirect-02 introduces ¡°B¡± bit to map the value encoded in the global administrator field to a Binding Segment Identifier value:
https://www.ietf.org/archive/id/draft-vandevelde-idr-flowspec-path-redirect-02.txt
¡­
This document defines a new BGP extended community.
¡­
The 2-byte local administrator field is formatted as shown in Figure 1.

                      0                   1
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |          Reserved     |B|TID|C|
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¡­
   Bit 2 is defined to be the 'B' (Binding) bit.  When the 'B' bit is
   set, the value encoded in the global administrator field is a Binding
   Segment Identifier value the use of which is detailed in section 3.2.
¡­


Now draft-vandevelde also defines the "Semantics Dependent" Flowspec Redirection.
Should we combine the work of draft-vandevelde & draft-li ?


Thanks,
Shunwan


·¢¼þÈË: Idr [mailto:[e-mail]] ´ú±í Ignas Bagdonas
·¢ËÍʱ¼ä: 2016Äê4ÔÂ8ÈÕ 20:17
ÊÕ¼þÈË: [e-mail]<mailto:[e-mail]>
Ö÷Ìâ: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

I have read the drafts being polled.

For a group of drafts on redirect:


https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/
Support as being a good starting point.

https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/
Do not support. It is redundant.

https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized-sid/
Do not support. It is redundant.

Draft-vandevelde can achieve all what draft-hao and draft-li can, and in a more flexible way. Having the ability to decouple redirection tunnel type from redirection action is both practical and extensible - the actual tunnel to be used is a local operational decision for each network element, it is not necessary signalled at the same time and by the same mechanism. Decoupling signalling and redirect parts aligns well to operational practices of using specific tools for specific tasks. Just that BGP could do that does not necesasry mean that it should be used as a best fit. From operational perspective there is no need to have multiple solutions that try to address the narrow problem space in similar yet incompatible ways. There should be one document for redirect, and draft-vandevelde is a good starting base for that.


For the match:

https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/
Suport as a good starting point.

https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/
Support as a good starting point.

https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/
Support as a good starting point.

https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/
Support as a good starting point.

https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/
Support as a good starting point.



Ignas

On 25/03/2016 14:47, Susan Hares wrote:
IDR WG:

This begins a 2 week WG Call (3/25 to 4/8/2016) for the set of drafts to be considered in RFC5575 additions. These options are filters, actions or critical security additions.  The flow specification work has been a part of the interims since IETF 94
https://www.ietf.org/proceedings/interim/2016/02/08/idr/proceedings.html
https://www.ietf.org/proceedings/interim/2016/03/07/idr/proceedings.html

There will be a brief flow specification presentation at IETF 95, and the email list has select to start with option 1 ¨C extending RFC5575.  We also will be gathering details on the SDN/NFV use case for option 2 (new NLRI and Wide Communities support).

This is a group call for the drafts to be considered in the flow specification work.  For each of the drafts you wish to be considered Option 1, please indicate:


1)      If this option is valuable for the DDoS deployments or another critical deployments,

2)      Do you feel this draft is useful, but not ready for adoption,

3)      Do you feel this draft is a good start for this work.

The drafts to consider are:
https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/
https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/
https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/
https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized-sid/
https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/
https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/
https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/
https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/

And for the ordering of these filters and actions drafts ¨C the Option 1 section out of this
https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/
(A revised draft with just Option 1 will be posted)

Sue Hares and John Scudder






_______________________________________________

Idr mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/idr

This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.