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

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 04 January 2016 23:50 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12E91ACD5E for <i2rs@ietfa.amsl.com>; Mon, 4 Jan 2016 15:50:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPD6xwJTpmGe for <i2rs@ietfa.amsl.com>; Mon, 4 Jan 2016 15:50:06 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B50A51ACD62 for <i2rs@ietf.org>; Mon, 4 Jan 2016 15:50:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9FCF18E002F; Mon, 4 Jan 2016 15:50:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1451951406; bh=7zggMYbapx1+wosQzS4tkXgYiR2ah1HyuTn6RTYp5n0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=oF6L56ugxPUIcNeVrYkvFPig99l/jTDB5IWe3MBK3RlFuVyuvdgjY9oSbofkWsjXe 20toe9TCI7sTMw1EL56R3+K1eSjzq6e2bFwEyldiX+zQKsoB02jNP70NgIhEjIZ/Ih thDH3y2C3N4OmirBaa8eyJUG4EVKZuRY4IfU8ZiA=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D9A711C0541; Mon, 4 Jan 2016 15:50:03 -0800 (PST)
To: Susan Hares <shares@ndzh.com>, i2rs@ietf.org
References: <20160104170330.13929.73845.idtracker@ietfa.amsl.com> <006701d14722$616c6950$24453bf0$@ndzh.com> <568ADBE7.3030101@joelhalpern.com> <00b501d1473f$fef22990$fcd67cb0$@ndzh.com> <568AFB86.8000603@joelhalpern.com> <00f501d14746$937a3e80$ba6ebb80$@ndzh.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <568B0508.2010608@joelhalpern.com>
Date: Mon, 04 Jan 2016 18:49:28 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <00f501d14746$937a3e80$ba6ebb80$@ndzh.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/Ue0sY4ot7QMX8nqiHvgPsJm3en8>
Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jan 2016 23:50:09 -0000

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:jmh@joelhalpern.com]
> Sent: Monday, January 04, 2016 6:09 PM
> To: Susan Hares; i2rs@ietf.org
> 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:jmh@joelhalpern.com]
>> Sent: Monday, January 04, 2016 3:54 PM
>> To: Susan Hares; i2rs@ietf.org; netmod@ietf.org; supa@ietf.org
>> 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: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>> [mailto:internet-drafts@ietf.org]
>>
>>   > 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
>>
>>   > i2rs@ietf.org <mailto:i2rs@ietf.org>
>>
>>   > https://www.ietf.org/mailman/listinfo/i2rs
>>
>>   >
>>
>
>