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:[email protected]] 
Sent: Monday, January 04, 2016 6:09 PM
To: Susan Hares; [email protected]
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:[email protected]]
> Sent: Monday, January 04, 2016 3:54 PM
> To: Susan Hares; [email protected]; [email protected]; [email protected]
> 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: [email protected] <mailto:[email protected]> 
> [mailto:[email protected]]
>
>  > 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-mod
> 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
>
>  > [email protected] <mailto:[email protected]>
>
>  > https://www.ietf.org/mailman/listinfo/i2rs
>
>  >
>

_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to