Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-00.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 12 Sep 2014 17:22:28 -0400

Thanks for doing this Jeff.  It is a great start.

The Object Relationships issue does need more work however.
Some of the cases are handled...

YANG's tools for reuse can be used to meet the inheritance requirements.
I think that the requires and when clauses are probably powerful enough 
to meet the architecture requirements for optionality (arch 6.4.5.2).

I do not know of anything in YANG that corresponds to agent side 
templating, as was agreed by the working group and captured in arch 
6.4.5.3.  (Since I am one who argued against this, if we need more 
detailed examples I would appreciate some assistance.)

The object relationships are three piece.  Arch 6.4.5.4.2 on correlation 
and arch 6.4.5.4.3 on actual references seem to be covered by various 
parts of YANG.  But the initialization reference described in arch 
6.4.5.4.1 does not correspond to anything I know of in YANG.  Is there a 
YANG tool for that?  This is the case where the definition of an object 
Foo says that whenever a new Foo is created, it takes its initial values 
from an instance of Bar, so as to simplify instantiation.  This is 
similar too, but not the same as the templates material.

You talk about the priority requirements.  You should probably mention 
the multi-headed behavioral requirements there (as I think that the 
resolutions will be tightly coupled.)

Section 7.9 of the archtiecture document talks about several 
transactional scopes.  The text you have does not seem to deal with all 
of these.  Does YANG handle them all easily?

Yours,
Joel

On 9/12/14, 4:59 PM, [email-masked] wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>          Title           : I2RS requirements for netmod/netconf
>          Author          : Jeffrey Haas
> 	Filename        : draft-haas-i2rs-netmod-netconf-requirements-00.txt
> 	Pages           : 10
> 	Date            : 2014-09-12
>
> Abstract:
>     This document covers requests to the netmod and netconf Working
>     Groups for functionality to support requirements to implement the
>     I2RS architecture.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Sep 2014 18:09:02 -0700

On Fri, Sep 12, 2014 at 2:22 PM, Joel M. Halpern <[email-masked]>
wrote:

> I think that the requires and when clauses are probably powerful enough to
> meet the architecture requirements for optionality (arch 6.4.5.2).
>
> 6.4.5.3.  (Since I am one who argued against this, if we need more detailed
> examples I would appreciate some assistance.)
>

I agree with you that Agent templates do not belong in the I2RS base spec.
There is nothing in YANG or RESTCONF to support it (yet).
For some features the I2RS agent is supposedly simple and mostly stateless.
This template service does not seem to fit with that theme.
Are these templates ephemeral?  That would be annoying.  They are not
straight
config, so a new a configuration data model is needed to manage the
templates.
New protocol mechanisms to use templates in addition to payload data will
be needed.

> and arch 6.4.5.4.3 on actual references seem to be covered by various parts
> of YANG.  But the initialization reference described in arch 6.4.5.4.1 does
> not correspond to anything I know of in YANG.  Is there a YANG tool for
> that?  This is the case where the definition of an object Foo says that
> whenever a new Foo is created, it takes its initial values from an instance
> of Bar, so as to simplify instantiation.  This is similar too, but not the
> same as the templates material.
>

Nothing in YANG like that except the description-stmt.
The server can magically create whatever it wants, whenever it wants.

>
> You talk about the priority requirements.  You should probably mention the
> multi-headed behavioral requirements there (as I think that the resolutions
> will be tightly coupled.)
>
> Section 7.9 of the archtiecture document talks about several transactional
> scopes.  The text you have does not seem to deal with all of these.  Does
> YANG handle them all easily?
>

I would need to review this again -- I don't remember any problems last
time I read the arch draft.

I am confused about some text in the draft about ephemeral config:

In 2.1:

   The author wishes to
   prevent any action that would lead to preserving any configuration
   state entered via the I2RS agent across reboots.  If state has to be
   restored, it should be solely by replay actions from I2RS client via
   I2RS agent.

Why does the author wish to prevent NV-storage of the I2RS data?
What is it about the accidental reboot of the router that makes it the
I2RS data needed before the accidental reboot, but not after?

If the reason is because I2RS agents are simple and NV-storage is not
simple,
then why does the agent need to support templates?

This section might mention that the I2RS datastore has its own
access control model, that is not the same as the running config.

   2.  Configuration state in the existing running datastore where the
       module is "tagged ephemeral".

   3.  Permitting existing configuration to be optionally configured as
       ephemeral.  As an example, the NETCONF server advertises in its
       <hello> message if it supports the specified YANG module
       persistently and/or ephemerally.

I thought the I2RS charter said I2RS was not altering the local config.
Why does I2RS need to change the meaning of YANG configuration nodes
in an ad-hoc manner (via tagging)?

This does not really work because YANG validation may fail without some
config data
that has been tagged "do not save".  If the router reboots and the startup
config
does not validate, it is probably wedged. It can't really fall back to a
"known good config"
if I2RS has forced some of the data to be omitted from the saved config.

In sec 2.1.3, if you want a new third choice for the config-stmt for
"ephemeral",
then I2RS is gated on the completion of YANG 1.1 (and development of YANG
1.1 tools).
Are you really sure you want that?  That's why a YANG extension was
suggested instead
(or maybe do both).

> Joel

Andy

> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Sep 2014 13:41:57 -0400

> Thanks for doing this Jeff.  It is a great start.

Thanks Joel - especially for the patience.

FWIW, I invite others to send edits.  The xml is posted in github:
https://github.com/jhaas-pfrc/I2RS-netmod-netconf-requirements

> Some of the cases are handled...

Agreed.  This section was flagged by Alia as potentially requiring some
attention but we didn't manage to get text in here.

I think the biggest concern she had (trying to summarize) is that if 
B depends on A, when A is updated B needs to "know" that in some form.
(And presumably transitive relationships such as C depends on B depends on A
and A is updated...)

I don't know that there's any specific action here, but certainly an open
question.

> I think that the requires and when clauses are probably powerful
> enough to meet the architecture requirements for optionality (arch
> 6.4.5.2).
> 
> The object relationships are three piece.  Arch 6.4.5.4.2 on
> correlation and arch 6.4.5.4.3 on actual references seem to be
> covered by various parts of YANG.  But the initialization reference
> described in arch 6.4.5.4.1 does not correspond to anything I know
> of in YANG.  Is there a YANG tool for that?  This is the case where
> the definition of an object Foo says that whenever a new Foo is
> created, it takes its initial values from an instance of Bar, so as
> to simplify instantiation.  This is similar too, but not the same as
> the templates material.

A number of these items seem logical and perhaps even trivial in a
client-side environment.  The clarity of whether/how they can be implemented
in the agent is one of the reasons why the Architecture document has been
not been published.

> You talk about the priority requirements.  You should probably
> mention the multi-headed behavioral requirements there (as I think
> that the resolutions will be tightly coupled.)

How would you distinguish the property that priority imposes on the agent
from that which would come from the multi-headed case?

> transactional scopes.  The text you have does not seem to deal with
> all of these.  Does YANG handle them all easily?

The better question, I believe, is whether NETCONF/RESTCONF handles them
appropriately for the YANG involved.  Working through some of these cases
with Dean B. suggested that you could get most in NETCONF and some in
RESTCONF.  Whether they make sense for a given use case may drive a
particular application.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Sep 2014 14:01:09 -0400

> This template service does not seem to fit with that theme.

Attempting to summarize discussions with various I2RS WG participants, I
think it's a matter of perspective - and somewhat of preference.  The
tension seems to lie roughly along two points of view:

1. This is a programmatically driven API environment.  As such, there's
little excuse to not simply send everything needed as a large configuration
block - templates are extraneous.

2. By permitting templates, you enable much smaller transactions.  You also
potentially allow for a stronger security model by "locking down" stuff
outside of the template.

To offer a somewhat concrete example, consider an application for
provisioning L3VPN customers.  Some minimum required configuration on a
per-device basis includes:

VRF name.
A route-distinguisher.
A route-target for the VPN.
Customer PE-CE protocol and endpoint configuration.

Fully expanded, this is probably a few dozens of lines of configuration in
YANG.  What's interesting is that the above information is potentially
generic related to that configuration, which may have per-device variance -
potentially based upon vendor.

Thought about perhaps another way, the template inputs are effectively a
mini-YANG module with much of the back-end abstracted.

> New protocol mechanisms to use templates in addition to payload data will

All agreed.

> time I read the arch draft.

Some of this is a matter of where this information lives.

For tie-breaking of ephemeral vs. static config, is this provisioned
per-module or per element in the module?  Are there explicit lines of YANG
in each module for this?

For tie-breaking user priorities, NACM extensions may make sense.  This
particular state is effectively meta-data on the ephemeral config.

Since the epehemeral state is "highest priority wins", but there's no
requirement that the lower priority state is kept in any fashion, how do we
deal with inconsistent configuration that may result by a higher priority
user deleting part of their configured state?

> I2RS data needed before the accidental reboot, but not after?

I think my point of confusion is why you believe ephemeral configuration
would ever get NV-stored?

> then why does the agent need to support templates?

This is more a "clean slate" decision.  When the device comes up, it has no
I2RS state.

Note that the fully ephemeral nature of I2RS still doesn't feel
fully-settled in the WG.  See prior thread comments about wanting to do
copy-config on it. :-)

> I thought the I2RS charter said I2RS was not altering the local config.

Correct.

> in an ad-hoc manner (via tagging)?

For point 2, it'd be identifying I2RS modules (having the ephemeral
properties) in the YANG.

Point 3 is submitted as an option based on comments at the last IETF netmod
session where someone else indicated being able to store things ephemerally
would potentially be useful.  If this is indeed a wider use case, let's
discuss it.

> if I2RS has forced some of the data to be omitted from the saved config.

Agreed.  See also the priority discussion above.

> Are you really sure you want that?  That's why a YANG extension was

Worth discussing during the interim.

It has been suggested to me that many of the above properties can already be
implemented in a proprietary manner with no language extensions.  They would
simply not be either interoperable or clear about their ephemeral nature
based on module contents.

So, we're looking for a balance of expeditious and correct for the long term
maintainenace of the protocols and YANG.

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Mon, 15 Sep 2014 15:46:19 -0700

On Mon, Sep 15, 2014 at 11:01 AM, Jeffrey Haas <[email-masked]> wrote:

> the
> transactional

Several people have asked about "copy to local config", which is
really "NV-save the I2RS state".    What if the operator wants the
state to be active until it is explicitly removed?   There may be
significant latency
between the time the client discovers the agent has rebooted and
the state is re-installed.

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 17 Sep 2014 19:12:44 -0400

Joel and Jeff:

Can you comment on why and why not you consider "instance-identifier" and
"require-instance" yang key words to satisfying the requirements for object
relationship requirements?  Are you both assuming a configuration state
datastore in which one instance is "config true tagged empheral" and a
second instance is tagged "config" without the empheral tag? 

Sue 
-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Friday, September 12, 2014 5:22 PM
To: [email-masked]
Subject: Re: [i2rs] I-D Action:
draft-haas-i2rs-netmod-netconf-requirements-00.txt

I do not know of anything in YANG that corresponds to agent side templating,
as was agreed by the working group and captured in arch 6.4.5.3.  (Since I
am one who argued against this, if we need more detailed examples I would
appreciate some assistance.)

The object relationships are three piece.  Arch 6.4.5.4.2 on correlation and
arch 6.4.5.4.3 on actual references seem to be covered by various parts of
YANG.  But the initialization reference described in arch
6.4.5.4.1 does not correspond to anything I know of in YANG.  Is there a
YANG tool for that?  This is the case where the definition of an object Foo
says that whenever a new Foo is created, it takes its initial values from an
instance of Bar, so as to simplify instantiation.  This is similar too, but
not the same as the templates material.

Yours,
Joel

On 9/12/14, 4:59 PM, [email-masked] wrote:
> 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.
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 17 Sep 2014 19:25:29 -0400

Jeff:

In the discussion of the requirements
(draft-hares-i2rs-usecase-reqs-summary-00) BGP-REQ02, BGP-REQ05, BGP-REQ07,
and BGP-REQ13 (see below for reference) could need to custom cost
communities, traffic flow specifications, and BGP policies into running BGP
nodes. When you say "no configuration" then my understanding is that the
I2RS agent bypasses the "local" config and goes directly to the routing
module to change these policies.  Is this what you mean by "no local
configuration? 

Sue 
------

   o  BGP-REQ02: I2RS client SHOULD be able to push BGP routes with
      custom cost communities to specific I2RS agents on BGP routers for
      insertion in specific BGP Peer(s) to aid Traffic engineering of
      data paths.  These routes SHOULD be tracked by the I2RS Agent as
      specific BGP routes with customer cost communities.  These routes
      (will/will not) installed via the RIB-Info.

   o  BGP-REQ05: I2RS client-agent SHOULD support writing traffic flow
      specifications to I2RS Agents that will install them in associated
      BGP ASBRs and the PE routers.

   o  BGP-REQ07: I2RS client-agent exchange SHOULD support the I2RS
      client being able to prioritize and control BGP's announcement of
      flow specifications after status information reading BGP ASBR and
      PE router's capacity.  BGP ASBRs and PE routers functions within a
      router MAY forward traffic flow specifications received from EBGP
      speakers to I2RS agents, so the I2RS Agent SHOULD be able to send
      these flow specifications from EBGP sources to a client in
      response to a read or notification.

   o  BGP-REQ13: I2RS client SHOULD be able to instruct the I2RS Agent
      to write BGP Policies into the running BGP protocols and into the
      BGP configurations.

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Monday, September 15, 2014 2:01 PM
To: Andy Bierman
Cc: [email-masked]; Joel M. Halpern
Subject: Re: [i2rs] I-D Action:

VRF name.
A route-distinguisher.

> straight config, so a new a configuration data model is needed to 
> manage the templates.
> New protocol mechanisms to use templates in addition to payload data 
> will be needed.

All agreed.

> I would need to review this again -- I don't remember any problems 
> last time I read the arch draft.

> simple, then why does the agent need to support templates?

> This section might mention that the I2RS datastore has its own access 
> control model, that is not the same as the running config.
> 

Correct.

> This does not really work because YANG validation may fail without 
> some config data that has been tagged "do not save".  If the router 
> reboots and the startup config does not validate, it is probably 
> wedged. It can't really fall back to a "known good config"

> "ephemeral", then I2RS is gated on the completion of YANG 1.1 (and 
> development of YANG
> 1.1 tools).
> suggested instead (or maybe do both).

-- Jeff

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 18 Sep 2014 10:55:42 -0400

There may be some restrictions on the use of those keywords that I 
missed.  But from what I can tell. those tools let us say that item A 
references and uses the values from item B.  (The require part is not 
actually spelled out in our requirements, but is a useful tool.)  This 
seems to match teh primary mode we called for.  It does not handle some 
of the other cases.  I don't think this has anything to do with 
ephemeral vs config vs operational.

Yours,
Joel

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Sep 2014 11:04:27 -0400

Joel:

You have understood my question - is section 2.8 orthogonal to the 3 options
in 2.1?  The language in option 3 could imply an instance.  Section 2.8 was
vague so I wanted Jeff's clarification. 

Sue 
-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, September 18, 2014 10:56 AM
To: Susan Hares; [email-masked]
Subject: Re: [i2rs] I-D Action:

There may be some restrictions on the use of those keywords that I missed.
But from what I can tell. those tools let us say that item A references and
uses the values from item B.  (The require part is not actually spelled out
in our requirements, but is a useful tool.)  This seems to match teh primary
mode we called for.  It does not handle some of the other cases.  I don't
think this has anything to do with ephemeral vs config vs operational.

Yours,
Joel

On 9/17/14, 7:12 PM, Susan Hares wrote:
> Joel and Jeff:
>
> Can you comment on why and why not you consider "instance-identifier" 
> and "require-instance" yang key words to satisfying the requirements 
> for object relationship requirements?  Are you both assuming a 
> configuration state datastore in which one instance is "config true 
> tagged empheral" and a second instance is tagged "config" without the
empheral tag?
6.4.5.2).
> correlation and arch 6.4.5.4.3 on actual references seem to be covered 
> by various parts of YANG.  But the initialization reference described 
> in arch
> 6.4.5.4.1 does not correspond to anything I know of in YANG.  Is there 
> a YANG tool for that?  This is the case where the definition of an 
> object Foo says that whenever a new Foo is created, it takes its 
> initial values from an instance of Bar, so as to simplify 
> instantiation.  This is similar too, but not the same as the templates
material.
>> https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requi
>> r
>> ements/
>>
>> http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirement
>> s
>> -00
>>
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 18 Sep 2014 11:39:42 -0400

As I understand it, 2.8 is orthogonal to 2.1 of Jeff's draft.
As I said separately, 2.8 is correct for some of what we want, and 
incorrect for other aspects we as a WG have agreed to.  I am confident 
that those other aspects can be addressed.

Yours,
Joel

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 22 Sep 2014 16:08:58 -0400

Sue,

> vague so I wanted Jeff's clarification. 

With regard to the original 3 options, two of them were likely covered by
the existing keywords.  The one that wasn't was the original proposal for
the separate datastore.  This ran potentially afoul of cross-datastore
references.

The fourth option the netmod interim provided would appear to address that.
(Again, notes coming shortly.)

-- Jeff