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

[John Strassner <[e-mail]>]

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:[e-mail]] On Behalf Of Susan Hares
Sent: Wednesday, January 06, 2016 3:25 PM
To: 'John Strassner'
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [netmod] [Supa] [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt

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

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 <[e-mail]<mailto:[e-mail]>> 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]<mailto:[e-mail]>]
Sent: Monday, January 04, 2016 3:54 PM
To: Susan Hares; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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-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

> [e-mail]<mailto:[e-mail]>

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

>

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



--
regards,
John