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 protected]] On Behalf Of Jeffrey Haas
Sent: Monday, September 15, 2014 2:01 PM
To: Andy Bierman
Cc: [email protected]; Joel M. Halpern
Subject: Re: [i2rs] I-D Action:
draft-haas-i2rs-netmod-netconf-requirements-00.txt
On Fri, Sep 12, 2014 at 06:09:02PM -0700, Andy Bierman wrote:
> 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.
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.
> 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.
All agreed.
> > 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.
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?
> 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?
I think my point of confusion is why you believe ephemeral configuration
would ever get NV-stored?
> 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 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. :-)
> 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.
Correct.
> Why does I2RS need to change the meaning of YANG configuration nodes
> 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.
> 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.
Agreed. See also the priority discussion above.
> 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).
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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
