Subject: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

From: "Susan Hares" <[email-masked]>
Date: Sat, 5 Mar 2016 17:48:40 -0500

The interim on 3/7/2016 will have a discussion of revisions to the BGP Flow
specification (BGP-FS) to add more features.  There are two suggested
options:

1)      A minimal features to existing BGP-FS (option 1) 

Add a few new match filters to the BGP-FS NLRI and few new actions to the
BGP-FS actions (in Extended communities).  Actions would need to be done in
a defined order. Each new actions would need to define conflicts with
existing actions.   

Best use case:  DoS attack prevention 

2)      Create a BGP-FS version 2 (option 2) 

Create a new BGP-FS NLRI (v2) with a field that indicates the ordering of
the BGP NLRI.  Add new BGP-FS actions with an order field in the BGP Wide
Communities.  Filters are done in the order defined in the filter.  Actions
are done in the order defined in the actions.   Order numbers that tie are
handled in a defined order. 

Best use case: SDN/NFV filter management 

A write-up on the issues and proposed solutions is contained in: 

draft-hares-idr-flowspec-combo-01.txt.
<https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/>    The WG
can select both option 1 and option 2.  This is a WG work item call for
input to the chairs on the scope of the WG item.  In you discussion of this
topics, the chairs would appreciate if you would indicate if you would
support IDR working on option 1, option 2 or both option 1 and 2.  This WG
call items also includes a call for draft-hares-idr-flowspec-combo-01.txt as
a write-up of the work-item options.  The WG may wish to split this draft
into multiple drafts. 

The following drafts are being consider for either option: 

1)      draft-eddy-idr-flowspec-packet-rate

2)      draft-hao-idr-flowspec-nv03

3)      draft-hao-idr-flowspec-label

4)      draft-liang-idr-bgp-flowspec-time

5)      draft-litowski-idr-flowspec-interfaceset 

6)      draft-vandevelde-idr-flowspec-path-redirect

7)      draft-li-idr-flowspec-rpd-01.txt 

8)      draft-wu-idr-flowspec-yang.cfg. 

If you wish to comment on any of these drafts, we will 

We will conclude the Call for WG opinions on 3/17/2016 so these authors can
have a day to revise and submit their drafts before the draft deadline. 

Sue Hares and John Scudder 

PS:

draft-li-idr-flowspec-rpd discusses limits on the distribution of the policy
which has been recast in draft-hares-idr-flowspec-combo as a bgp-wide
community of Container type 1 with an atom of BGP Flow Specification
ordering. However,  this draft is included in the list to be able to update
the mechanism from this draft into that context.  

The yang model for BGP Flow specification is also included in this work item
as it will need to be modified based on the approaches.  The yang model is
in draft-wu-idr-flowspec-yang-cfg.  In your comments, please indicate if you
feel these drafts or other drafts.

---

From: Gunter Van De Velde <[email-masked]>
Date: Sun, 06 Mar 2016 10:34:12 +0100

My consern with the concept of BGP-FS version 2 is that it means jumping to solution space, even before having a rough agreement on the requirements and scope for a SDN policy distribution mechanism.
An additional concern is about using BGP for NFV management as there may be more appropriate mechanisms available (outside BGP). 

If the intent is to truly use BGP as a mechanism to distribute SDN policies and and related management information, then what does that mean exactly? what does such protocol extension 
expose as capabilities? What are the use-cases that drive the need for existence of such technology? In that case it may be better to construct a tailor designed BGP Policy Distribution framework version 1 (BGP-PD version 1)

I believe in keeping changes to RFC5575 to a minimum, and only extend to simple match/action capabilities that "drive indirection" and "network wide" rules.
I also believe that before trying to document a solution space for BGP based SDN policy distribution, that both the problem space and intended protocol properties exposed as consumable SDN API’s need to be discussed and agreed upon. In that light i feel that the concept of a BGP-FS version 2 is not the right approach.

G/

> On 05 Mar 2016, at 23:48, Susan Hares <[email-masked]> wrote:
> 
> The interim on 3/7/2016 will have a discussion of revisions to the BGP Flow specification (BGP-FS) to add more features.  There are two suggested options:
> Add a few new match filters to the BGP-FS NLRI and few new actions to the BGP-FS actions (in Extended communities).  Actions would need to be done in a defined order. Each new actions would need to define conflicts with existing actions.   
>  
> Create a new BGP-FS NLRI (v2) with a field that indicates the ordering of the BGP NLRI.  Add new BGP-FS actions with an order field in the BGP Wide Communities.  Filters are done in the order defined in the filter.  Actions are done in the order defined in the actions.   Order numbers that tie are handled in a defined order. 
>  
> draft-hares-idr-flowspec-combo-01.txt.  <https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/>   The WG can select both option 1 and option 2.  This is a WG work item call for input to the chairs on the scope of the WG item.  In you discussion of this topics, the chairs would appreciate if you would indicate if you would support IDR working on option 1, option 2 or both option 1 and 2.  This WG call items also includes a call for draft-hares-idr-flowspec-combo-01.txt as a write-up of the work-item options.  The WG may wish to split this draft into multiple drafts. 
>  
> We will conclude the Call for WG opinions on 3/17/2016 so these authors can have a day to revise and submit their drafts before the draft deadline. 
>  
> draft-li-idr-flowspec-rpd discusses limits on the distribution of the policy which has been recast in draft-hares-idr-flowspec-combo as a bgp-wide community of Container type 1 with an atom of BGP Flow Specification ordering. However,  this draft is included in the list to be able to update the mechanism from this draft into that context.  
>  
> The yang model for BGP Flow specification is also included in this work item as it will need to be modified based on the approaches.  The yang model is in draft-wu-idr-flowspec-yang-cfg.  In your comments, please indicate if you feel these drafts or other drafts.  
>  
> _______________________________________________
> Idr mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 6 Mar 2016 07:51:11 -0500

Gunter: 

Thank you for being the first responder to the BGP-FS call for input.  My understanding is that you approve option 1, but are concerned about the scope of option 2.   Do you feel the actions need ordering for option 1?  

I will ask those who propose the SDN/NFV work to write their understanding of the use cases for the next IETF, and post it on the list.  In the last few interims, there seem to be a consensus of people indicating that the SDN/NFV was a valid use case.  However, interims are small discussion formats so the chairs have sent this call for input. 

On working toward a specific solution space: the IESG has encouraged parallel efforts between problem space development and solutions in order to aid rapid deployment of protocols.   The draft-hares-idr-flowspec-combo  is a summary of the problem space and solutions from the WG chair’s viewpoint.  Thank you for letting me know we need to add problem space details.  

Sue       

From: Idr [mailto:[email-masked]] On Behalf Of Gunter Van De Velde
Sent: Sunday, March 06, 2016 4:34 AM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

G/

 

 <https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/> draft-hares-idr-flowspec-combo-01.txt.    The WG can select both option 1 and option 2.  This is a WG work item call for input to the chairs on the scope of the WG item.  In you discussion of this topics, the chairs would appreciate if you would indicate if you would support IDR working on option 1, option 2 or both option 1 and 2.  This WG call items also includes a call for draft-hares-idr-flowspec-combo-01.txt as a write-up of the work-item options.  The WG may wish to split this draft into multiple drafts. 

PS:

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

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 7 Mar 2016 09:15:07 +0100

Hi Sue/Gunter,

On the topic of problem space, requirements ... etc aren't we reinventing
the wheel ? Aren't I2RS documents doing that already ?

https://datatracker.ietf.org/wg/i2rs/documents/

And if they do is BGP FSv2 the right approach to be used as I2RS channel ?

If yes I would question that simply based on the nature of BGP which is
p2mp distribution (even if augmented now for other reasons with RTC).

In most of the cases network elements need to get unique set of parameters
which just does not fit BGP distribution model. If so why BGP?

Is using port 179 and reuse of non AF/SAFI specific code the only reason?

Or is the problem perhaps due to no APIs and common message bus across
vendors and we are trying to fit BGP to become one in the fear that it will
take decade(s) for vendors to support new common network element mgmt/API
channel ?

If we go with FSv2 what is the "read" or telemetry channel from device
which will trigger proper FSv2 filter ? Is it again BGP ?

- -

On FSv1 I think we are ok to proceed. On the question of ordered actions or
not I think one may need to support both as likely there will be folks who
will need one or the other depending on what they are going to filter :)

Best,
r.

On Sun, Mar 6, 2016 at 1:51 PM, Susan Hares <[email-masked]> wrote:

> Gunter:
>
>
>
> Thank you for being the first responder to the BGP-FS call for input.  My
> understanding is that you approve option 1, but are concerned about the
> scope of option 2.   Do you feel the actions need ordering for option 1?
>
>
>
> I will ask those who propose the SDN/NFV work to write their understanding
> of the use cases for the next IETF, and post it on the list.  In the last
> few interims, there seem to be a consensus of people indicating that the
> SDN/NFV was a valid use case.  However, interims are small discussion
> formats so the chairs have sent this call for input.
>
>
>
> On working toward a specific solution space: the IESG has encouraged
> parallel efforts between problem space development and solutions in order
> to aid rapid deployment of protocols.   The draft-hares-idr-flowspec-combo
>  is a summary of the problem space and solutions from the WG chair’s
> viewpoint.  Thank you for letting me know we need to add problem space
> details.
>
>
>
> Sue
>
>
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Gunter Van De
> Velde
> *Sent:* Sunday, March 06, 2016 4:34 AM
> *To:* Susan Hares
> *Cc:* [email-masked]
> *Subject:* Re: [Idr] WG Work item call - Opinions on work items (3/5/2016
> to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt
>
>
>
> My consern with the concept of BGP-FS version 2 is that it means jumping
> to solution space, even before having a rough agreement on the requirements
> and scope for a SDN policy distribution mechanism.
>
> An additional concern is about using BGP for NFV management as there may
> be more appropriate mechanisms available (outside BGP).
>
>
>
> If the intent is to truly use BGP as a mechanism to distribute SDN
> policies and and related management information, then what does that mean
> exactly? what does such protocol extension
>
> expose as capabilities? What are the use-cases that drive the need for
> existence of such technology? In that case it may be better to construct a
> tailor designed BGP Policy Distribution framework version 1 (BGP-PD version
> 1)
>
>
>
> I believe in keeping changes to RFC5575 to a minimum, and only extend to
> simple match/action capabilities that "drive indirection" and "network
> wide" rules.
>
> I also believe that before trying to document a solution space for BGP
> based SDN policy distribution, that both the problem space and intended
> protocol properties exposed as consumable SDN API’s need to be discussed
> and agreed upon. In that light i feel that the concept of a BGP-FS version
> 2 is not the right approach.
>
>
>
> G/
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The interim on 3/7/2016 will have a discussion of revisions to the BGP
> Flow specification (BGP-FS) to add more features.  There are two suggested
> options:
>
> <https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/>   The
> WG can select both option 1 and option 2.  This is a WG work item call for
> call items also includes a call for draft-hares-idr-flowspec-combo-01.txt
> as a write-up of the work-item options.  The WG may wish to split this
> draft into multiple drafts.
>
>
>
> We will conclude the Call for WG opinions on 3/17/2016 so these authors
> can have a day to revise and submit their drafts before the draft deadline.
>
>
>
>
> draft-li-idr-flowspec-rpd discusses limits on the distribution of the
> policy which has been recast in draft-hares-idr-flowspec-combo as a
> bgp-wide community of Container type 1 with an atom of BGP Flow
> Specification ordering. However,  this draft is included in the list to be
> able to update the mechanism from this draft into that context.
>
>
>
> The yang model for BGP Flow specification is also included in this work
> item as it will need to be modified based on the approaches.  The yang
> model is in draft-wu-idr-flowspec-yang-cfg.  In your comments, please
> indicate if you feel these drafts or other drafts.
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: Gunter Van De Velde <[email-masked]>
Date: Mon, 07 Mar 2016 10:28:29 +0100

Indeed Robert, correct observation and roughly alined with mine on the question
asking if BGP is best API for SDN policy distribution ...

For any new feature potentially added to BGP FS (rfc5575) i feel that the p2mp
and indirection property of BGP must be considered as a key component.

Be well,
G/

Sent using CloudMagic Email
[https://cloudmagic.com/k/d/mailapp?ct=pa&cv=8.1.32&pv=6.0.1&source=email_footer_2] On Mon, Mar 07, 2016 at 9:15 AM, Robert Raszuk < [email-masked] [[email-masked]] > wrote:
Hi Sue/Gunter,
On the topic of problem space, requirements ... etc aren't we reinventing the
wheel ? Aren't I2RS documents doing that already ?
https://datatracker.ietf.org/wg/i2rs/documents/
[https://datatracker.ietf.org/wg/i2rs/documents/]

And if they do is BGP FSv2 the right approach to be used as I2RS channel ?
If yes I would question that simply based on the nature of BGP which is p2mp
distribution (even if augmented now for other reasons with RTC).

In most of the cases network elements need to get unique set of parameters which
just does not fit BGP distribution model. If so why BGP?
Is using port 179 and reuse of non AF/SAFI specific code the only reason?
Or is the problem perhaps due to no APIs and common message bus across vendors
and we are trying to fit BGP to become one in the fear that it will take
decade(s) for vendors to support new common network element mgmt/API channel ?
If we go with FSv2 what is the "read" or telemetry channel from device which
will trigger proper FSv2 filter ? Is it again BGP ?
- -
On FSv1 I think we are ok to proceed. On the question of ordered actions or not
I think one may need to support both as likely there will be folks who will need
one or the other depending on what they are going to filter :)
Best, r.

On Sun, Mar 6, 2016 at 1:51 PM, Susan Hares < [email-masked] [[email-masked]] > wrote:
Gunter:

Thank you for being the first responder to the BGP-FS call for input. My
understanding is that you approve option 1, but are concerned about the scope of
option 2. Do you feel the actions need ordering for option 1?

I will ask those who propose the SDN/NFV work to write their understanding of
the use cases for the next IETF, and post it on the list. In the last few
interims, there seem to be a consensus of people indicating that the SDN/NFV was
a valid use case. However, interims are small discussion formats so the chairs
have sent this call for input.

On working toward a specific solution space: the IESG has encouraged parallel
efforts between problem space development and solutions in order to aid rapid
deployment of protocols. The draft-hares-idr-flowspec-combo is a summary of the
problem space and solutions from the WG chair’s viewpoint. Thank you for letting
me know we need to add problem space details.

Sue

From: Idr [mailto: [email-masked] [[email-masked]] ] On Behalf Of Gunter Van De Velde
Sent: Sunday, March 06, 2016 4:34 AM
To: Susan Hares
Cc: [email-masked] [[email-masked]]
Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016)
and adoption of draft-hares-idr-flowspec-combo-01.txt

My consern with the concept of BGP-FS version 2 is that it means jumping to
solution space, even before having a rough agreement on the requirements and
scope for a SDN policy distribution mechanism.

An additional concern is about using BGP for NFV management as there may be more
appropriate mechanisms available (outside BGP).

If the intent is to truly use BGP as a mechanism to distribute SDN policies and
and related management information, then what does that mean exactly? what does
such protocol extension

expose as capabilities? What are the use-cases that drive the need for existence
of such technology? In that case it may be better to construct a tailor designed
BGP Policy Distribution framework version 1 (BGP-PD version 1)

I believe in keeping changes to RFC5575 to a minimum, and only extend to simple
match/action capabilities that "drive indirection" and "network wide" rules.

I also believe that before trying to document a solution space for BGP based SDN
policy distribution, that both the problem space and intended protocol
properties exposed as consumable SDN API’s need to be discussed and agreed upon.
In that light i feel that the concept of a BGP-FS version 2 is not the right
approach.

G/

On 05 Mar 2016, at 23:48, Susan Hares < [email-masked] [[email-masked]] > wrote:

The interim on 3/7/2016 will have a discussion of revisions to the BGP Flow
specification (BGP-FS) to add more features. There are two suggested options:

Add a few new match filters to the BGP-FS NLRI and few new actions to the BGP-FS
actions (in Extended communities). Actions would need to be done in a defined
order. Each new actions would need to define conflicts with existing actions.

Create a new BGP-FS NLRI (v2) with a field that indicates the ordering of the
BGP NLRI. Add new BGP-FS actions with an order field in the BGP Wide
Communities. Filters are done in the order defined in the filter. Actions are
done in the order defined in the actions. Order numbers that tie are handled in
a defined order.

draft-hares-idr-flowspec-combo-01.txt.
[https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/] The WG can select both option 1 and option 2. This is a WG work item call for
input to the chairs on the scope of the WG item. In you discussion of this
topics, the chairs would appreciate if you would indicate if you would support
IDR working on option 1, option 2 or both option 1 and 2. This WG call items
also includes a call for draft-hares-idr-flowspec-combo-01.txt as a write-up of
the work-item options. The WG may wish to split this draft into multiple drafts.

We will conclude the Call for WG opinions on 3/17/2016 so these authors can have
a day to revise and submit their drafts before the draft deadline.

PS:

draft-li-idr-flowspec-rpd discusses limits on the distribution of the policy
which has been recast in draft-hares-idr-flowspec-combo as a bgp-wide community
of Container type 1 with an atom of BGP Flow Specification ordering. However,
this draft is included in the list to be able to update the mechanism from this
draft into that context.

The yang model for BGP Flow specification is also included in this work item as
it will need to be modified based on the approaches. The yang model is in
draft-wu-idr-flowspec-yang-cfg. In your comments, please indicate if you feel
these drafts or other drafts.

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

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

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 7 Mar 2016 10:01:15 -0500

Robert: 

Thank you for your input on IDR Flow specification version 2’s ( that I2RS provides the ordering of flow specifications), and that BGP does not need to add option 2.    Does your concern on overlapping with I2RS include option 1 as well? 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, March 07, 2016 3:15 AM
To: Susan Hares
Cc: idr wg
Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

Hi Sue/Gunter,

On the topic of problem space, requirements ... etc aren't we reinventing the wheel ? Aren't I2RS documents doing that already ? 

If yes I would question that simply based on the nature of BGP which is p2mp distribution (even if augmented now for other reasons with RTC). 

In most of the cases network elements need to get unique set of parameters which just does not fit BGP distribution model. If so why BGP? 

Or is the problem perhaps due to no APIs and common message bus across vendors and we are trying to fit BGP to become one in the fear that it will take decade(s) for vendors to support new common network element mgmt/API channel ?  

If we go with FSv2 what is the "read" or telemetry channel from device which will trigger proper FSv2 filter ? Is it again BGP ? 

- - 

On FSv1 I think we are ok to proceed. On the question of ordered actions or not I think one may need to support both as likely there will be folks who will need one or the other depending on what they are going to filter :)

Best,

r.

Gunter: 

Sue       

G/

 

PS:

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 14 Mar 2016 15:46:04 +0000

Hi,

IMO in short term we need to work on option1, in which ordering and combination rules need to be specified.

As for option 2, we may need to take the characteristics of BGP into consideration and identify the appropriate use cases for BGP-FS, then make the protocol extension accordingly.

Best regards,
Jie

发件人: Idr [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2016年3月6日 6:49
收件人: [email-masked]
主题: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

PS:

---

From: Lucy yong <[email-masked]>
Date: Mon, 14 Mar 2016 18:37:43 +0000

support Jie’s suggestion.

Lucy

From: Idr [mailto:[email-masked]] On Behalf Of Dongjie (Jimmy)
Sent: Monday, March 14, 2016 10:46 AM
To: Susan Hares; [email-masked]
Subject: [Idr] ??: WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

Hi,

Best regards,
Jie

发件人: Idr [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2016年3月6日 6:49
收件人: [email-masked]<mailto:[email-masked]>
主题: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

PS:

---

From: Haoweiguo <[email-masked]>
Date: Tue, 15 Mar 2016 01:27:28 +0000

I also agree with Jie's suggestion.
weiguo
________________________________
From: Idr [[email-masked]] on behalf of Lucy yong [[email-masked]]
Sent: Tuesday, March 15, 2016 2:37
To: Dongjie (Jimmy); Susan Hares; [email-masked]
Subject: Re: [Idr] ??: WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

Lucy

Hi,

Best regards,
Jie

PS:

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 15 Mar 2016 01:57:43 +0000

+1.

Linda

From: Idr [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Monday, March 14, 2016 1:38 PM
To: Dongjie (Jimmy); Susan Hares; [email-masked]
Subject: Re: [Idr] ??: WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

Lucy

From: Idr [mailto:[email-masked]] On Behalf Of Dongjie (Jimmy)
Sent: Monday, March 14, 2016 10:46 AM
To: Susan Hares; [email-masked]<mailto:[email-masked]>
Subject: [Idr] ??: WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

Hi,

Best regards,
Jie

PS:

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 15 Mar 2016 21:21:16 +0000

I’ve listened the to the IDR Interim WebEx recording and my opinion is consistent with Gunter. I believe we should move forward with option 1 and not embark on option 2 until the requirements are clear AND we reach consensus that we want to use BGP Flow-Spec for SDN policy distribution.
Thanks,
Acee

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Gunter Van De Velde <[email-masked]<mailto:[email-masked]>>
Date: Sunday, March 6, 2016 at 4:34 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: IDR List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

G/

On 05 Mar 2016, at 23:48, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

PS:

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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 15 Mar 2016 17:33:47 -0400

Acee: 

Thank you for letting me know your opinion.  

At this point, I think we have rough consensus that we can move forward with option 1, and interest in option 2 with mixed reviews on whether we are ready to embark on option 2.   This call last for 2 more days – so we will see if that brings clarity on option 2.  

I think we can begin to do a WG adoption call for drafts for option 1. 

Sue 

From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2016 5:21 PM
To: Gunter Van De Velde; Susan Hares
Cc: [email-masked]
Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

Thanks,

Acee 

From: Idr <[email-masked]> on behalf of Gunter Van De Velde <[email-masked]>
Date: Sunday, March 6, 2016 at 4:34 AM
To: Susan Hares <[email-masked]>
Cc: IDR List <[email-masked]>
Subject: Re: [Idr] WG Work item call - Opinions on work items (3/5/2016 to 3/17/2016) and adoption of draft-hares-idr-flowspec-combo-01.txt

G/

 

PS: