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:[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