[netmod] action-stmt

[Andy Bierman]

Hi,

The action-stmt example on page 27 is wrong.
The  element is missing.  It is shown correctly
on page 105.
p27
  
   http://acme.example.com/system";>
 eth1
 
   192.0.2.1
 
   
 


p105

 
   
 http://example.net/server-farm";>
   apache-1
   
 2014-07-29T13:42:00Z
   
 
   
 


Sec. 7.15  provides few details wrt/ input processing.
Extra input is ignored? (draft is silent about that).
YANG attributes like "insert"or "operation" are ignored? (also silent).

Sec 7.15.2, para 2 is not clear whether the XML hierarchy
has to exist in any particular datastore (or opstate).
Since there is no mention of datastores in 7.15, I
assume the text just refers to the input containing
schema-valid XML, which may or may not correspond
to actual data instances somewhere inn the server.



Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[John Strassner]

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:netmod-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Wednesday, January 06, 2016 3:25 PM
To: 'John Strassner'
Cc: i...@ietf.org; s...@ietf.org; netmod@ietf.org
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:straz...@gmail.com]
Sent: Tuesday, January 05, 2016 10:28 PM
To: Susan Hares
Cc: Joel M. Halpern; i...@ietf.org; netmod@ietf.org; s...@ietf.org; 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  evaluates to TRUE
IF 
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 
mailto:sha...@ndzh.com>> 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:j...@joelhalpern.com]
Sent: Monday, January 04, 2016 3:54 PM
To: Susan Hares; i...@ietf.org; 
netmod@ietf.org; s...@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 al

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

[John Strassner]

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?


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.


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.


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


regards,
John

From: Supa [mailto:supa-boun...@ietf.org] On Behalf Of Susan Hares
Sent: Wednesday, January 06, 2016 6:13 AM
To: 'John Strassner'; 'Joel M. Halpern'
Cc: i...@ietf.org; netmod@ietf.org; s...@ietf.org
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:supa-boun...@ietf.org] On Behalf Of John Strassner
Sent: Tuesday, January 05, 2016 10:12 PM
To: Joel M. Halpern
Cc: i...@ietf.org; s...@ietf.org; netmod@ietf.org; 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, t

Re: [netmod] Draft clemm netmod mount draft

[Alexander Clemm (alex)]

Hi,

this was intended as an example.  The reason to include the interfaces module 
is the scenario in which a controller would like to have a model/inventory of 
the various interfaces across the network.  Each network device will have its 
own instantiation of the interfaces module.  Rather than replicating interfaces 
information in a network controller model, by mounting this data under the 
corresponding network element’s list element, the need to re-define interface 
data (just to be included in a different place in the containment hierarchy) is 
avoided.

Hope that helps
--- Alex (just returning from holiday break, hence the delayed response)

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of 
rohitrran...@outlook.com
Sent: Tuesday, December 22, 2015 3:45 AM
To: netmod@ietf.org
Subject: [netmod] Draft clemm netmod mount draft


In the controller-network data model , is the interfaces module imported for a 
specific reason ?

Sent from Outlook Mobile
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Susan Hares]

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:straz...@gmail.com] 
Sent: Tuesday, January 05, 2016 10:28 PM
To: Susan Hares
Cc: Joel M. Halpern; i...@ietf.org; netmod@ietf.org; s...@ietf.org; 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  evaluates to TRUE
IF 
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  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:j...@joelhalpern.com] 
Sent: Monday, January 04, 2016 3:54 PM
To: Susan Hares; i...@ietf.org; netmod@ietf.org; s...@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

Re: [netmod] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06

[Eliot Lear]

On 1/6/16 4:59 PM, Dean Bogdanovic wrote:
>> On Jan 4, 2016, at 10:24 PM, Eliot Lear  wrote:
>>
>> Hi,
>>
>> I guess what I'm hearing is that we should do a hopefully very short
>> augmentation for domain names in the matches clause and standardize that
>> separately.  Does that seem reasonable?
> Yes, if you think there is a need for such a draft and IPR issue is cleared, 
> WG adopts it, why not

The only reason not to do that is you will end up many many of drafts
like mine, dinking the model.  I realize some view that as a positive. 
I'm not so sure.

Eliot




signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt

[Kent Watsen]

It’s true that the draft is largely centered around the intended/applied config 
notion, but not exclusively.  Specifically, 4-B has "Ability to map intended 
config nodes to associated derived state nodes".  I think that this might be 
the only exclusion though and, if it weren’t for it I would’ve used your title 
suggestion from the LC review.   Should one requirement have such influence 
over the title is the question.  I was trying to be fair to it, but maybe it's 
going too far.

Regarding visibility and control, I was attempting to use common words (not 
normative terms) here.  My intent for them is something along the lines of:

visibility: read/understand
control: write/orchestrate

Thanks,


Kent


On 1/6/16, 1:30 AM, "Juergen Schoenwaelder" 
 wrote:

>Acee,
>
>for me the document is centered around the notion of intended /
>applied config:
>
>#1 is clearly about intended/applied cfg
>
>#2 is about intended/applied cfg (since sync config operations is
>   largely defined using intended/applied cfg)
>
>#3 is about the relationship of applied config and derived state
>
>#4 is about the relationship of intended / applied config and
>   operational state
>
>I find "Enhanced Operational State Visibility and Control" abstract
>and somewhat confusing (what is visibility? what is control?).
>
>/js
>
>On Tue, Jan 05, 2016 at 08:08:29PM +, Acee Lindem (acee) wrote:
>> Juergen, 
>> 
>> As another non-author, I disagree with this characterization of the draft.
>> The intended/applied configuration is an important requirement but
>> certainly not the only one precisely articulated in the draft.
>> 
>> Acee 
>> 
>> On 1/5/16, 3:02 PM, "netmod on behalf of Juergen Schoenwaelder"
>> > j.schoenwael...@jacobs-university.de> wrote:
>> 
>> >On Mon, Jan 04, 2016 at 10:29:54PM +, Kent Watsen wrote:
>> >> 
>> >> This update addresses comments received during the Last Call.
>> >>
>> >
>> >I not entirely happy with the new title:
>> >
>> >   Terminology and Requirements for Enhanced
>> >Operational State Visibility and Control
>> >
>> >Since the key contribution is the concept of intended configuration
>> >and applied configuration, why not put these terms into the title
>> >instead of "Enhanced Operational State Visibility and Control", which
>> >is somewhat vague? What about this proposal:
>> >
>> >   Terminology and Requirements for Distinguishing
>> >  Intended and Applied Configuration
>> >
>> >/js
>> >
>> >-- 
>> >Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>> >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> >Fax:   +49 421 200 3103 
>> >
>> >___
>> >netmod mailing list
>> >netmod@ietf.org
>> >https://www.ietf.org/mailman/listinfo/netmod
>> 
>
>-- 
>Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06

[Dean Bogdanovic]

> On Jan 6, 2016, at 10:30 AM, Juergen Schoenwaelder 
>  wrote:
> 
> On Mon, Jan 04, 2016 at 07:23:38PM +0100, Eliot Lear wrote:
>> Hi Juergen,
>> 
>> On this point:
>> 
>> On 12/21/15 4:33 PM, Juergen Schoenwaelder wrote:
>> 
>>> And
>>> should the interface reference not use a more specific type than
>>> 'string’?
 Interface references can be many things, from standard naming we are 
 familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as 
 string gives us most flexibility in that regards.
>>> I disagree that the goal here is most flexibility. We do have an
>>> interfaces data model in the IETF. Why are we avoiding to refer to it
>>> here?
>>> 
>> 
>> I think it would be helpful if you could be specific as to your
>> concern.  It is absolutely the case that the SNMP folk did an awful lot
>> of work on managing interfaces.  While I am not concerned about the form
>> of the name, I wonder if your concern is around some of the semantics,
>> but I can't tell.
>> 
> 
> My question is why the model does not use interface-ref or
> interface-state-ref defined in RFC 7223 but instead an opaque string
> to refer to an interface. Have we thought about the design tradeoffs?
> 
> My question is _not_ about how we deal with interface naming schemes,
> that discussion took place when RFC 7223 was created.

In the example where the ACL is attached to the interface, we are using 
interface-ref, so replacing interface in the metadata, can be easily done.

> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

[Gert Grammel]

Sorry, missed Kent’s remark:
[KENT] or due to missing hardware, right?

That’s one root cause, but I didn’t want to go into much details here. Missing 
Hardware is one issue, other issues are unconscious configuration requests from 
the client, faulty HW, bugs etc. Whatever the root cause, the result is 
intended != applied and Client+Server have to deal with it in a meaningful 
manner.

Gert

From: Robert Wilton [mailto:rwil...@cisco.com]
Sent: 06 January 2016 17:49
To: Kent Watsen; Gert Grammel
Cc: netmod@ietf.org
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on 
error)

Hi Kent,
On 06/01/2016 16:43, Kent Watsen wrote:
[As a contributor]

Gert> If a client is has the intention to update/change a config, its decision 
is based on the present state of the configuration when the decision is taken. 
Ideally the present configuration is in a state where intended == applied 
config, so there is stable ground upon which a change is applied. However there 
is also the case where intended != applied config and there are two reasons for 
that.

a)  a previous intended config is in the process of being applied

b)  a previous configuration failed due to an error
[KENT] or due to missing hardware, right?   Regardless, I don’t think this 
thread has bearing of the requirements draft.  Note that I removed the 
*-on-error terms from the Terminology section in -02 by instead rewording 
requirement 2-C, which was the only place they were being referenced before and 
the reference was merely suggestive (not normative).  Can we leave it to the 
solution drafts to sort out?

Yes, deferring this issue to the solutions draft works for me.

I don't think that it will have any bearing on the discussion of the overall 
solution approach.

Thanks,
Rob
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

[Gert Grammel]

Kent,

I would agree that the discussion doesn’t affect the requirements draft in its 
current state. The solutions draft would be a better place probably.

Gert

From: Kent Watsen
Sent: 06 January 2016 17:43
To: Gert Grammel; Robert Wilton
Cc: netmod@ietf.org
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on 
error)

[As a contributor]

Gert> If a client is has the intention to update/change a config, its decision 
is based on the present state of the configuration when the decision is taken. 
Ideally the present configuration is in a state where intended == applied 
config, so there is stable ground upon which a change is applied. However there 
is also the case where intended != applied config and there are two reasons for 
that.

a)  a previous intended config is in the process of being applied

b)  a previous configuration failed due to an error
[KENT] or due to missing hardware, right?   Regardless, I don’t think this 
thread has bearing of the requirements draft.  Note that I removed the 
*-on-error terms from the Terminology section in -02 by instead rewording 
requirement 2-C, which was the only place they were being referenced before and 
the reference was merely suggestive (not normative).  Can we leave it to the 
solution drafts to sort out?


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

[Robert Wilton]

Hi Kent,

On 06/01/2016 16:43, Kent Watsen wrote:

[As a contributor]

Gert> If a client is has the intention to update/change a config, its 
decision is based on the present state of the configuration when the 
decision is taken. Ideally the present configuration is in a state 
where intended == applied config, so there is stable ground upon which 
a change is applied. However there is also the case where intended != 
applied config and there are two reasons for that.


a)a previous intended config is in the process of being applied

b)a previous configuration failed due to an error

[KENT] or due to missing hardware, right?   Regardless, I don’t think 
this thread has bearing of the requirements draft.  Note that I 
removed the *-on-error terms from the Terminology section in -02 by 
instead rewording requirement 2-C, which was the only place they were 
being referenced before and the reference was merely suggestive (not 
normative).  Can we leave it to the solution drafts to sort out?


Yes, deferring this issue to the solutions draft works for me.

I don't think that it will have any bearing on the discussion of the 
overall solution approach.


Thanks,
Rob

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

[Kent Watsen]

[As a contributor]

Gert> If a client is has the intention to update/change a config, its decision 
is based on the present state of the configuration when the decision is taken. 
Ideally the present configuration is in a state where intended == applied 
config, so there is stable ground upon which a change is applied. However there 
is also the case where intended != applied config and there are two reasons for 
that.

a)  a previous intended config is in the process of being applied

b)  a previous configuration failed due to an error

[KENT] or due to missing hardware, right?   Regardless, I don’t think this 
thread has bearing of the requirements draft.  Note that I removed the 
*-on-error terms from the Terminology section in -02 by instead rewording 
requirement 2-C, which was the only place they were being referenced before and 
the reference was merely suggestive (not normative).  Can we leave it to the 
solution drafts to sort out?


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

[Gert Grammel]

Hi Rob,

See below ...

--Gert

From: Robert Wilton [mailto:rwil...@cisco.com]
Sent: 05 January 2016 16:05
To: Gert Grammel
Cc: netmod@ietf.org
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on 
error)

Hi Gert,

Considering a rollback-on-error request that failed:

If you leave the configuration in intended config then what happens if a 
separate config request comes in from another client?  Should that request be 
processed in the context of the failed intended config, or the last successful 
config change, or must it wait for the original client to decide how to process 
the failure that occurred?
Gert> If a client is has the intention to update/change a config, its decision 
is based on the present state of the configuration when the decision is taken. 
Ideally the present configuration is in a state where intended == applied 
config, so there is stable ground upon which a change is applied. However there 
is also the case where intended != applied config and there are two reasons for 
that.

a)  a previous intended config is in the process of being applied

b)  a previous configuration failed due to an error
In case a) the following config just needs to wait, or if it can be applied 
without interfering with the previous intended config *may* be executed in 
parallel (up to the server to implement)
Case b) is just about the same as stop-on-error or continue-on-error. If there 
is an error in configuring a node and the new intended config uses 
stop-on-error, then it should not be executed. In contrast, a continue-on-error 
configuration can be applied independently.

Also what would happen if the client disconnects from the server when a 
rollback-on-error request has failed, and the server is waiting for the client 
to tell it what to do?
Gert> the previous (rolled-back) configuration is applied and the intended 
config remains different from the applied config. It will stay like that until 
the Client figured out what to do. E.g. one option is to re-apply the intended 
config with a continue-on-error semantic. If a second client, despite the 
server calamities, decides to change the config, it can try to do so in a 
continue-on-error mode as well.

I think that what you describe sounds more like a config request to a candidate 
configuration datastore.  I.e. write the config to candidate, and then commit.  
If the commit fails, the configuration in the running datastore is rolled back 
but the configuration remains in the candidate datastore.  But note that in 
this scenario both the intended and applied configuration have both been 
reverted to the state before the commit operation was attempted.
Gert> bear with me but I don't parse the two sentences as they seem 
contradictory. Perhaps you could spend a few more words.
I am advocating for a case with a consistent behavior in case of failures in 
all execution models. Irrespective of stop-on-error, continue-on-error or 
rollback-on-error, the non-performing configuration is the diff between 
intended and applied configuration that can conveniently be reported by the 
server. In any of those cases, the server is rightfully in an errored state 
with respect to configuration and it is risky to attempt a new configuration 
unless the client resolves the misalignment. It appears to me that we have 
broadly 3 failure cases to deal with:

1)  The client did a poor job in figuring out which configuration to push 
on a server

2)  The server did a poor job in reporting its own state to the client (see 
cheating synchronous), which in turn can lead to 1)

3)  Something unexpected happens in between the client figuring out the 
intended config and the server applying it.
Case 1) can only be dealt by the Client. 2) is often dealt with re-applying the 
same intended config a bit later, hoping the server is in a better mood now (by 
experience it often works). If it still doesn't, it's again up to the client to 
figure out what's best now. Since the event in 3) may impact the state of the 
node quite a bit, also here it is the job of the client to figure out which 
config to apply based on the new state.

Thanks,
Rob

On 28/12/2015 17:40, Gert Grammel wrote:
Rob,

>From a client perspective there should be no difference in the intended state 
>behavior depending on error conditions, if continue-on-error leaves the 
>intended state, a rollback-on-error should keep it as well. Moreover, a client 
>reaction on a unsuccessful application of intended state could be to a) 
>re-try, b) retry with continue-on-error or c) retry wit stop-on-error. Those 
>actions would not require any change of intended state.
It shouldn't be the server to decide what the intended state is supposed to be 
or hoe long it should last.

Gert


Sent from my Apple ][

On 23 Dec 2015, at 22:25, Robert Wilton 
mailto:robert.pub...@wilton.org.uk>> wrote:
Hi Gert,

Please see one comment inline ...

On 23/12/2015 10:24, Gert Grammel wrote:
Rob, Kent,

Re: [netmod] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06

[Dean Bogdanovic]

> On Jan 4, 2016, at 10:24 PM, Eliot Lear  wrote:
> 
> Hi,
> 
> I guess what I'm hearing is that we should do a hopefully very short
> augmentation for domain names in the matches clause and standardize that
> separately.  Does that seem reasonable?

Yes, if you think there is a need for such a draft and IPR issue is cleared, WG 
adopts it, why not

Dean

> 
> Eliot
> 
> On 12/19/15 2:05 PM, Dean Bogdanovic wrote:
>> The basic design idea for the base model is structure that all vendors 
>> support. Some of the examples mentioned below, like FQDN, are not supported 
>> by all vendors and are protected by IPR (which I wasn’t aware of it). There 
>> are many possible match conditions that could be added to the base model, 
>> like Auth header in IPSec or IPSec encapsulation security payload to keep it 
>> with security. There are many match conditions in Class of Services as well. 
>> All these match conditions would have created more issues to come to 
>> consensus about the base model, so for that reason we went with the minimal 
>> model that would be easy for all vendors to implement.
>> 
>> Dean
>> 
>>> On Dec 18, 2015, at 5:21 PM, Sterne, Jason (Jason) 
>>>  wrote:
>>> 
>>> I'm not a fan of adding something like that in the base model.  Let's get a 
>>> basic model done and then we can consider an extension draft.  I'd think 
>>> that things like TCP flags, for example, would be a more natural & common 
>>> thing to add to an ACL model than a host name match so I can't see host 
>>> name being in there before TCP flags (which I'm not advocating for in the 
>>> base model).
>>> 
>>> I also don't think the metadata interface match should be in this base 
>>> model either.  That is out of place IMO.  The base model provides an ACL 
>>> that can then get associated with objects like interfaces (as in the 
>>> example in section A.3)
>>> I'd also suggest we consider making the actions 'deny' and 'permit' 
>>> presence containers instead of empty leafs.  That would allow easier 
>>> augmentations (e.g. additional 'permit' parameters for policy based 
>>> forwarding for example).
>>> 
>>> Regards,
>>> Jason
>>> 
>>> -Original Message-
>>> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Nadeau Thomas
>>> Sent: Thursday, December 17, 2015 10:53
>>> To: Lear Eliot
>>> Cc: Benoit Claise; RTG YANG Design Team; netmod WG
>>> Subject: Re: [netmod] Working group Last Call: 
>>> draft-ietf-netmod-acl-model-06
>>> 
>>> 
>>> You raise a good point. Do the contributors/editors have any thoughts 
>>> on this suggestion?
>>> 
>>> —Tom
>>> 
>>> 
 On Dec 17, 2015:9:44 AM, at 9:44 AM, Eliot Lear  wrote:
 
 
 
 On 12/17/15 2:45 PM, Nadeau Thomas wrote:
>   Do you mean an ASCII DNS name (versus an IP address w a mask)?
 I was thinking of "host" in RFC 6021.
 
 Eliot
 
 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> ___
>>> Rtg-dt-yang-arch mailing list
>>> rtg-dt-yang-a...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch
>> 
> 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Susan Hares]

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:supa-boun...@ietf.org] On Behalf Of John Strassner
Sent: Tuesday, January 05, 2016 10:12 PM
To: Joel M. Halpern
Cc: i...@ietf.org; s...@ietf.org; netmod@ietf.org; 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  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.


In my role as I2RS chair,  I2RS needs to make progress soon on the
I2RS FB-RIB data model.  We would appreciate your aid.


Sue

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, January 04, 2016 12:04 PM
To: Susan Hares; Qin Wu; Russ White
Subject: New Ve

Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06

[Juergen Schoenwaelder]

On Mon, Jan 04, 2016 at 07:23:38PM +0100, Eliot Lear wrote:
> Hi Juergen,
> 
> On this point:
> 
> On 12/21/15 4:33 PM, Juergen Schoenwaelder wrote:
> 
> > And
> >  should the interface reference not use a more specific type than
> >  'string’?
> >> Interface references can be many things, from standard naming we are 
> >> familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as 
> >> string gives us most flexibility in that regards.
> > I disagree that the goal here is most flexibility. We do have an
> > interfaces data model in the IETF. Why are we avoiding to refer to it
> > here?
> >
> 
> I think it would be helpful if you could be specific as to your
> concern.  It is absolutely the case that the SNMP folk did an awful lot
> of work on managing interfaces.  While I am not concerned about the form
> of the name, I wonder if your concern is around some of the semantics,
> but I can't tell.
>

My question is why the model does not use interface-ref or
interface-state-ref defined in RFC 7223 but instead an opaque string
to refer to an interface. Have we thought about the design tradeoffs?

My question is _not_ about how we deal with interface naming schemes,
that discussion took place when RFC 7223 was created.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[John Strassner]

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 
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.
>>
>> 
>> In my role as I2RS chair,  I2RS needs to make progress soon on the
>> I2RS FB-RIB data model.  We would appreciate your aid.
>> 
>>
>> Sue
>>
>> -Original Message-
>> From: internet-dra...@ietf.org [mailto:internet-dra...@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-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, encap

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

[John Strassner]

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  evaluates to TRUE
IF 
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  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:j...@joelhalpern.com]
> Sent: Monday, January 04, 2016 3:54 PM
> To: Susan Hares; i...@ietf.org; netmod@ietf.org; s...@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.
>
> >
>
> > 
>
> > In my role as I2RS chair,  I2RS needs to make progress soon on the
>
> > I2RS FB-RIB data model.  We would appreciate your aid.