Hi Sue,
You are correct, it is a very simple case, with one type of event. Joel
indicated flaws in the document that it did not indicate the event was a
“packet reception”. At this point, it sounds like you and Joel are suggesting
that this particular simplistic case of Event-Condition-Action is OK to go
forward with in the I2RS (for ephemeral state), and in appropriate WG for the
non-ephemeral case. Is this correct?
<jcs>
As long as it is clarified that there is, in fact, an event, then I think that
it is fine. Note that it should also be clarified that if the Event is not
received, then the condition clause can never be evaluated.
</jcs>
At IETF 94, I was simply comparing Chen’s document versus this very simple case
of an ECA. I did not mean to imply it was the only possible ECA case. I look
forward to hearing from the SUPA list regarding the generic ECA information
model and the different types of ECA.
<jcs>
That's what confused me - the chen document did have event nodes in it, and
your draft didn't. That being said, there are many ways to define Events. If
you look at the SUPA model, you will see the following exemplar methods:
· you can define a clause, of the canonical form {variable, operator,
value}, to represent an event (e.g., time == 08:00am)
· you can use an Event object as the variable or the value in the above
clause (e.g., use one or more attributes from one or more Event objects in the
comparison clause)
· you can use a Collection attributes to collect events for
aggregation, filtering, and/or correlation operations as part of the event
clause processing
· you can encode the entire event expression into an attribute
</jcs>
regards,
John
From: Supa [mailto:[email protected]] On Behalf Of Susan Hares
Sent: Wednesday, January 06, 2016 6:13 AM
To: 'John Strassner'; 'Joel M. Halpern'
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [Supa] [i2rs] FW: New Version Notification for
draft-hares-i2rs-bnp-eca-data-model-03.txt
John:
Thank you for your response. For filter-based FIB,
Event = receiving packet information on the interface
Condition = match on a variety of conditions (see the draft)
Action = a choice of actions modify packet, forward/drop packet, and count
packet.
You are correct, it is a very simple case, with one type of event. Joel
indicated flaws in the document that it did not indicate the event was a
“packet reception”. At this point, it sounds like you and Joel are suggesting
that this particular simplistic case of Event-Condition-Action is OK to go
forward with in the I2RS (for ephemeral state), and in appropriate WG for the
non-ephemeral case. Is this correct?
At IETF 94, I was simply comparing Chen’s document versus this very simple case
of an ECA. I did not mean to imply it was the only possible ECA case. I look
forward to hearing from the SUPA list regarding the generic ECA information
model and the different types of ECA.
Sue
From: Supa [mailto:[email protected]] On Behalf Of John Strassner
Sent: Tuesday, January 05, 2016 10:12 PM
To: Joel M. Halpern
Cc: [email protected]; [email protected]; [email protected]; Susan Hares
Subject: Re: [Supa] [i2rs] FW: New Version Notification for
draft-hares-i2rs-bnp-eca-data-model-03.txt
Hi Joe, et al.,
> 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.
Exactly. More particularly, in scanning this draft, I fail to see how
this is an accepted definition of ECA. In particular, there doesn't
seem to be any event in the rule definition.
Hence, I would suggest that you add wording that says that this is
one of many ways to build such a mapping.
> 2) The approach with the supa eca data model is still under
> development.
Absolutely agree. In particular, draft-chen was the first attempt at
trying to conceptualize what such a data model should look like.
> Having said that, the material in there is intended to be very
> general.
IFF you mean the SUPA info model, then absolutely (otherwise,
it has failed in its primary mission of providing an extensible
framework to define policies).
IFF you mean draft-chen, then I think it agrees with the spirit of
what you said. I think that we need to discuss how to map from
an info model to a data model in more detail before we come to
any conclusions of its efficacy.
> 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.
+1. In fact, the whole point of SUPA is to provide different ways
of forming an ECA policy rule to meet different demands of the
user. More particularly, at IETF94, you (Sue) assumed that an
ECA policy rule was made up of Event, Condition, and Action
objects. While that is certainly one alternative, there are others
as well. In addition, please note that the presence of these
objects is NOT sufficient to build an ECA policy rule (e.g., the
Event object needs an attribute (or multiple attributes) to be
compared to something in order to determine if the event
CLAUSE evaluates to TRUE or not.
regards,
John
On Mon, Jan 4, 2016 at 12:53 PM, Joel M. Halpern
<[email protected]<mailto:[email protected]>> wrote:
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]<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-model-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<http://tools.ietf.org>.
The IETF Secretariat
_______________________________________________
i2rs mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
Supa mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/supa
--
regards,
John
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
