Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

[Gyan Mishra <[e-mail]>]

I support WG adoption.

1) Is this document clear about the proposal?

Yes.  Some refinements needed per the feedback from the WG.

2) Do you think we should do this with Flow Specification v2?

Yes

I think this will help fix some issues with unknown components in FS1 and
may delay FS2 as now operators  have an alternative to support features
incrementally as necessary.  I think this would be helpful with FS2 as well
and should be pursued in parallel to FS2.

Or should we do this instead of Flow Specification v2?

No

I think this is a good idea to provide fixed for issues in FS1 and provide
the stop gap measures for unknown components.  We should continue to pursue
FS2 and I think this incremental strategy may help FS2 as well.  In
building this incremental concept we should ensure that it will be future
proof so can work with future FS2 as well.

3) Will this help operational networks?

Yes.  It will help address immediately issues with unsupported components
stop gap measure till FS2  can be realized.

Kind Regards

Gyan

On Fri, Apr 9, 2021 at 11:59 AM Robert Raszuk <[e-mail]> wrote:

> Jeff,
>
> Before answering first I wanted to get clarity on question #1. Now I have
> it. Hence ready to answer the questions:
>
> > 1) Is this document clear about the proposal?
>
> No. Current text gives too much freedom to implementation in what they
> want to signal in the capabilities (supported by platform filters, enabled
> by platform filters, recognizable by BGP types).
>
> > 2) Do you think we should do this with Flow Specification v2?
> > Or should we do this instead of Flow Specification v2?
>
> We should stop changing Flowspec v1 and shift all this new work to
> Flowspec v2. It is just one new SAFI. We could perhaps also rename it to
> Confspec instead of mixing it with Flowspec as number of requested new
> changes or additions do not even describe the IP packet flows.
>
> IMO there is no need to do interim solutions. For one we will never be
> done with interim and it will be much harder to move to new clean solution.
>
> > 3) Will this help operational networks?
>
> It could help, but only in some deployment scenarios and with obvious
> danger to break flowspec v1 original deployment use case.
>
> Many thx,
> Robert.
>
>
>
>
> On Fri, Apr 9, 2021 at 5:45 PM Jeffrey Haas <[e-mail]> wrote:
>
>> Robert,
>>
>> On Fri, Apr 09, 2021 at 05:34:54PM +0200, Robert Raszuk wrote:
>> > IDR WG and AD made a decision many months back that no new features you
>> may
>> > be referring to sitting in your backlog will be added to flowspec v1.
>> Did
>> > you miss that - I think so based on your replies.
>>
>> Considering that the recommendation was based in part on my commentary on
>> the work for RFC 8955 and the problems with incremental deployment of new
>> features... why yes, I'm familiar with the motivations for the current
>> status quo.
>>
>> The motivation for this draft is to see if we have a way forward in the
>> interim.
>>
>> > > The point of the proposal is to offer an option that addresses
>> incremental
>> > > deployment of new flowspec features without requiring a flowspec v2.
>> >
>> > And that is the key src of my objection as I see what is being cooked
>> here.
>> > It is against already reached WG consensus. New features should go to
>> FSv2
>> > leaving FSv1 to do its original job.
>>
>> I'd request you go back to Sue's simple 3 question adoption request and
>> just
>> answer the questions there.
>>
>> Thanks.
>>
>> -- Jeff
>>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*