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

["Susan Hares" <[e-mail]>]

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]
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]> 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]
主题: 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 – 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 – 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]
https://www.ietf.org/mailman/listinfo/idr