Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt

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

Joel:

I2RS is simply dealing with a subset of ECA (event = packet arrival,
condition=match, action = packet forward/modification).  
Draft-hares-i2rs-bnp-eca-data-model-03 tries to restrict us to just this
space.  Someone in I2RS asked for packet size and time of day as the current
filtering does this type of filtering. 

You have succinctly summarized my attempt to work with the generic SUPA
model.   I tried to give the authors this feedback at IETF 94 politely, but
perhaps I should post something again that gives the problem again. 

Sue


-----Original Message-----
From: Joel M. Halpern [mailto:[e-mail]] 
Sent: Monday, January 04, 2016 6:49 PM
To: Susan Hares; [e-mail]
Subject: Re: [i2rs] FW: New Version Notification for
draft-hares-i2rs-bnp-eca-data-model-03.txt

The basic problem I see is with the action clause being a wide open "do
something".  That is not satisfiable.  It would make more sense to aim at
forwarding actions.  Otherwise, we are trying to tackle the entire policy
space, or worse the programmable packet space (do anything when a suitable
packet arrives) which seems a bad idea.

Yes, once can view a packet arrival as an event.  I realized that after I
wrote my note.

I guess what bothers me is that I do not see the value of trying to
integrate this with the whole ECA policy space.  Any competent ECA
abstraction can handle "packet arrival on interface" as a subclass of event.
And if we can represent the necessary filters and RIB actions, then we
should fix the abstractions.

I will try to look at draft-hares-i2rs-bnp-eca-data-model.  But I guess my
point is that I2RS should not betrying to define the general ECA policy data
model space.  I2RS was not chartered to deal with the entire space of
policy, at least as I understood things when we started.

Yours,
joel

On 1/4/16 6:21 PM, Susan Hares wrote:
> Joel:
>
> <wg chair hat off>
>
>   The working group charter defines Filter-Based RIBs as:
>
> o Filter-based RIBs include a match of fields in IP header plus other 
> IP packet format fields. The matches in the filter-based RIBs may be 
> ordered to allow appropriate sequencing of the filter. Each match 
> contains an action which may be forwarding to a next hop address or 
> other actions. I2RS will coordinate this work with appropriate working 
> groups in routing, security and operations & management areas.
>
> I interpret this charter statement as:
>
> Event: IP packet arrives
> Condition: match on filter
> Action: action for forwarding to a next hop.
>
> If the WG feels this different than the general SUPA ECA, then I 
> personally can accept this.
> I have a few questions:
>
> 1) Do you feel the draft-hares-i2rs-bnp-eca-data-model fits the 
> event-condition-action restrictions above?
> 2) Given the above, do you have suggestions for the draft-kini-info-model?
>
> Sue
>
>
> -----Original Message-----
> From: Joel M. Halpern [mailto:[e-mail]]
> Sent: Monday, January 04, 2016 6:09 PM
> To: Susan Hares; [e-mail]
> Subject: Re: [i2rs] FW: New Version Notification for 
> draft-hares-i2rs-bnp-eca-data-model-03.txt
>
> I would disagree with the statement that an FB-Rib uses an 
> Event-Condition_action policy.
> Filters are not events.  they may be represented as a subclass of 
> conditions, but even that is not clear.  And the actions in an FB-RIB 
> are probably better thought of as RIB resutls than as actions.
>
> At the same time, there are a lot of properties needed by a general 
> policy system (such as SUPA) that are not needed by FB-RIB filters / 
> forwarding entries.
>
> So I would tend to suggest that coupling this to the general policy 
> problem is merely hindering our ability to get things done.
>
> Yours,
> Joel
>
> On 1/4/16 5:33 PM, Susan Hares wrote:
>> Joel:
>>
>> On #1) the dependency between I2RS Filter-based RIB (FB-RIB) and ECA, 
>> please see draft-kini-i2rs-fb-rib-info-model-02.txt. In section 1.1, 
>> it gives the definition of the FB-RIB.  In section 1.2, it links this 
>> to an event-condition-action model.  If you disagree with the 
>> definition
> of
>>    I2RS FB-RIB, then we should probably restrict this conversation to 
>> the I2RS mail list.  Any feedback on the Info-model or data-model 
>> would be helpful.  The authors hoped to go to a WG adoption call at 
>> the end of this week.
>>
>> One challenge for the ephemeral I2RS FB-RIB, is there is no 
>> definition of the non-ephemeral FB-RIB.  If you think there should be 
>> a non-ephemeral FB-RIB - that discussion may be useful between I2RS, 
>> Netmod and SUPA.
>>
>> On #2) SUPA ECA model, I agree that we should be able to have a 
>> common draft.  At IETF 94, I raised issues regarding the SUPA versus 
>> my ECA definition.
>>
>> Cheerily,
>>
>> Sue
>>
>> -----Original Message-----
>> From: Joel M. Halpern [mailto:[e-mail]]
>> Sent: Monday, January 04, 2016 3:54 PM
>> To: Susan Hares; [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: [i2rs] FW: New Version Notification for 
>> draft-hares-i2rs-bnp-eca-data-model-03.txt
>>
>> I think there are two issues here.
>>
>> 1) It is not clear to me why there is any dependence of the fb-rib 
>> data model on an eca data model.  While supa does allow for policy 
>> model to be sent directly to the router, it also allows many other cases.
>>
>> 2) The approach with the supa eca data model is still under development.
>>
>>     Having said that, the material in there is intended to be very 
>> general.  From what I understand, there should be no difficulty in 
>> refining the action side of that model to actions which affect the 
>> fb-rib in ways that are consistent with the fb-dib data model.
>>
>> Yours,
>>
>> Joel
>>
>> On 1/4/16 2:01 PM, Susan Hares wrote:
>>
>>   > This model provides a Event-Condition-Action (ECA) policy model.
>>
>>   > The I2RS FB-RIB yang data model utilizes this model, but to my
>>
>>   > knowledge the Netmod or netconf has not adopted an ECA policy 
>> model to
>>
>>   > parallel the ACL model.
>>
>>   >
>>
>>   > Chen and co-authors have created the model:
>>
>>   >
>>
>>   > draft-chen-supa-eca-data-model-05.txt
>>
>>   >
>>
>>   > But it does not align with this yang model or seem sufficient to
>>
>>   > support the FB-RIB information model.   At IETF 94,
>>
>>   > I presented a discussion of the issues I found with the
>>
>>   > draft-chen-supa-eca-data-model-05.txt, but it has not been updated.
>>
>>   > We would appreciate feedback on this version of yang model.
>>
>>   >
>>
>>   > <i2rs Chair hat on>
>>
>>   > In my role as I2RS chair,  I2RS needs to make progress soon on 
>> the
>>
>>   > I2RS FB-RIB data model.  We would appreciate your aid.
>>
>>   > <i2rs chair hat off>
>>
>>   >
>>
>>   > Sue
>>
>>   >
>>
>>   > -----Original Message-----
>>
>>   > From: [e-mail] <mailto:[e-mail]> 
>> [mailto:[e-mail]]
>>
>>   > Sent: Monday, January 04, 2016 12:04 PM
>>
>>   > To: Susan Hares; Qin Wu; Russ White
>>
>>   > Subject: New Version Notification for
>>
>>   > draft-hares-i2rs-bnp-eca-data-model-03.txt
>>
>>   >
>>
>>   >
>>
>>   > A new version of I-D, draft-hares-i2rs-bnp-eca-data-model-03.txt
>>
>>   > has been successfully submitted by Susan Hares and posted to the 
>> IETF repository.
>>
>>   >
>>
>>   > Name:
draft-hares-i2rs-bnp-eca-data-model
>>
>>   > Revision:          03
>>
>>   > Title:                  An Information Model for Basic Network Policy
>> and Filter Rules
>>
>>   > Document date:           2016-01-04
>>
>>   > Group:                              Individual Submission
>>
>>   > Pages:                               30
>>
>>   > URL:
>> https://www.ietf.org/internet-drafts/draft-hares-i2rs-bnp-eca-data-mo
>> d
>> el-03.txt
>>
>>   > Status:
>> https://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-eca-data-model/
>>
>>   > Htmlized:
>> https://tools.ietf.org/html/draft-hares-i2rs-bnp-eca-data-model-03
>>
>>   > Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-hares-i2rs-bnp-eca-data-model
>> -
>> 03
>>
>>   >
>>
>>   > Abstract:
>>
>>   >     This document contains the Basic Network Policy and Filters (BNP
> IM)
>>
>>   >     Data Model which provides a policy model that support an ordered
> list
>>
>>   >     of match-condition-action (aka event-condition-action (ECA)) for
>>
>>   >     multiple layers (interface, L1-L4, application) and other factors
>>
>>   >     (size of packet, time of day).  The actions allow for setting
> actions
>>
>>   >     (QOS and other), decapsulation, encapsulation, plus forwarding
>>
>>   >     actions.  The policy model can be used with the I2RS filter-based
>>
>>   >     RIB.
>>
>>   >
>>
>>   >
>>
>>   >
>>
>>   >
>>
>>   > Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>>
>>   >
>>
>>   > The IETF Secretariat
>>
>>   >
>>
>>   >
>>
>>   > _______________________________________________
>>
>>   > i2rs mailing list
>>
>>   > [e-mail] <mailto:[e-mail]>
>>
>>   > https://www.ietf.org/mailman/listinfo/i2rs
>>
>>   >
>>
>
>