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

From: "Susan Hares" <[email-masked]>
Date: Mon, 4 Jan 2016 14:01:55 -0500

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-masked] [mailto:[email-masked]] 
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.

The IETF Secretariat

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 4 Jan 2016 15:53:59 -0500

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:
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 4 Jan 2016 17:33:54 -0500

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-masked]] 
Sent: Monday, January 04, 2016 3:54 PM
To: Susan Hares; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] FW: New Version Notification for
draft-hares-i2rs-bnp-eca-data-model-03.txt

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.

  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

> 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 

> From:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]]

> Subject: New Version Notification for 

> draft-hares-i2rs-bnp-eca-data-model-03.txt

> URL:
<https://www.ietf.org/internet-drafts/draft-hares-i2rs-bnp-eca-data-model-03
.txt>
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/>
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>
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>
https://www.ietf.org/rfcdiff?url2=draft-hares-i2rs-bnp-eca-data-model-03

> 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.

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/i2rs>

---

From: John Strassner <[email-masked]>
Date: Tue, 5 Jan 2016 19:12:11 -0800

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

Absolutely agree. In particular, draft-chen was the first attempt at
trying to conceptualize what such a data model should look like.

> 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-masked]>
wrote:

> 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
>
>> https://www.ietf.org/internet-drafts/draft-hares-i2rs-bnp-eca-data-model-03.txt
>> Status:
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 5 Jan 2016 19:27:45 -0800

Sue,

> 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.

Sorry, it does NOT do this. To quote from this section:

   A Filter Based RIB uses Event-Condition-Action policy. A Filter-
   based RIB entry specifies matches on fields in a packet (which may
   include layer 2 fields, IP header fields, transport or application
   fields) or size of the packet or interface received on. The matches
   are contained in an ordered list of filters which contain pairs of
   match condition-action (aka event-condition-action).

Please tell me WHERE the event is in the above definition. All I see is
a condition-action rule. (BTW, the analysis of PCIM and PCIMe is also
not quite correct in your draft).

> In section 1.2, it links this to an event-condition-action model.

Sorry, it does NOT do this.

First, this section simply says, and I quote:

   "The filter based-RIB uses event-condition-action policy (ECA) rules."

That is a tautology at best.

Second, in Section 2, under the definition of FB-Route, the draft says:

   "The policy rules in the filter-based RIB are prescriptive of the
     Event-Condition-Action form which is often represented by
        if Condition then action."

Please note that this definition is incorrect, and in conflict with SUPA.
The whole point of an EVENT-condition-action policy rule is to define
a rule of the form:

    IF <event_clause> evaluates to TRUE
        IF <condition_clause evaluates to TRUE
            THEN execute actions in <action_clause>
        ENDIF
    ENDIF

This definition has been established in the industry and academia
for at least 2 decades.

Variations of the above have been defined and published (e.g.,
FOCALE has an alternate set of actions to execute if the condition
clause evaluated to FALSE; this has NOT been proposed for SUPA
at this time). There have also been extensions to handle sets and
groups, as well as specific ordering (DEN-ng, SID, FOCALE).

Therefore, I would suggest that you change your drafts to use a
condition-action policy rule, OR update the drafts (I would be happy
to help) to use a correct definition of an ECA policy rule.

regards,
John

On Mon, Jan 4, 2016 at 2:33 PM, Susan Hares <[email-masked]> 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
> FB-RIB – that discussion may be useful between I2RS, Netmod and SUPA.
>
>
>
> > From: [email-masked] [mailto:[email-masked]
> <[email-masked]>]
>

-- 
regards,
John

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 6 Jan 2016 09:12:57 -0500

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-masked]] On Behalf Of John Strassner
Sent: Tuesday, January 05, 2016 10:12 PM
To: Joel M. Halpern
Cc: [email-masked]; [email-masked]; [email-masked]; Susan Hares
Subject: Re: [Supa] [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt

Hi Joe, et al.,

 

> 2) The approach with the supa eca data model is still under

> development.

 

regards,

John

On Mon, Jan 4, 2016 at 12:53 PM, Joel M. Halpern <[email-masked]> wrote:

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

<i2rs Chair hat on>

Sue

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
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

Abstract:

The IETF Secretariat

-- 

regards,

John

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 6 Jan 2016 18:25:00 -0500

John: 

You are correct in indicating that the draft assumes you understand the event = Packet reception.  It is a failing in the draft that Joel has indicated on these lists.  I will be updating the ECA drafts and FB-RIB drafts.  I will send a copy to you and Joel for review this week. 

Thank you for pointing out the errors in the drafts, 

Sue 

From: John Strassner [mailto:[email-masked]] 
Sent: Tuesday, January 05, 2016 10:28 PM
To: Susan Hares
Cc: Joel M. Halpern; [email-masked]; [email-masked]; [email-masked]; John Strassner
Subject: Re: [Supa] [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt

Sue,

regards,
John

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-masked]] 
Sent: Monday, January 04, 2016 3:54 PM
To: Susan Hares; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt

  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

> From:  <mailto:[email-masked]> [email-masked] [ <mailto:[email-masked]> mailto:[email-masked]]

> URL:             <https://www.ietf.org/internet-drafts/draft-hares-i2rs-bnp-eca-data-model-03.txt> 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/> 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> 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> https://www.ietf.org/rfcdiff?url2=draft-hares-i2rs-bnp-eca-data-model-03

>  <https://www.ietf.org/mailman/listinfo/i2rs> https://www.ietf.org/mailman/listinfo/i2rs

-- 

regards,

John

---

From: John Strassner <[email-masked]>
Date: Thu, 7 Jan 2016 00:49:59 +0000

Hi Sue,

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

<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-masked]] On Behalf Of Susan Hares
Sent: Wednesday, January 06, 2016 6:13 AM
To: 'John Strassner'; 'Joel M. Halpern'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Supa] [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt

John:

Sue

Hi Joe, et al.,

regards,
John

On Mon, Jan 4, 2016 at 12:53 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
I think there are two issues here.

Yours,
Joel

<i2rs Chair hat on>

Sue

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
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

Abstract:

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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2rs

_______________________________________________
Supa mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/supa

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 7 Jan 2016 00:50:38 +0000

Sue:

I'm happy to help. I2RS is important work, and I would like to ensure that SUPA could help your work (without delaying it, of course).

Also, I'm interested in the data models that you come up with, as they are excellent examples of what SUPA needs to support.

regards,
John

From: netmod [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Wednesday, January 06, 2016 3:25 PM
To: 'John Strassner'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [netmod] [Supa] [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt

John:

Sue

Sue,

regards,
John

On Mon, Jan 4, 2016 at 2:33 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:

Joel:

Cheerily,

Sue

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, January 04, 2016 3:54 PM
To: Susan Hares; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt

Yours,

Joel

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

--
regards,
John