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

["UTTARO, JAMES" <[e-mail]>]

Here were my comments in re I2RS.. See bullet 3..

Jim Uttaro


Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted

--------------------------------------------------------------------------------

From: "UTTARO, JAMES" <ju1738 at att.com>
To: "'Dean Bogdanovic'" <deanb at juniper.net>, "'Susan Hares'" <shares at ndzh.com>
Cc: 'Jeffrey Haas' <jhaas at pfrc.org>, "'<i2rs at ietf.org>'" <i2rs at ietf.org>, 'Russ White' <russw at riw.us>, 'Edward Crabbe' <edc at google.com>, "'t.petch'" <ietfc at btconnect.com>
Date: Mon, 16 Jun 2014 17:40:29 +0000
In-reply-to: <[e-mail]>
References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$[e-mail]> <055f01cf8708$49597000$dc0c5000$@riw.us> <[e-mail]>
List-id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>

--------------------------------------------------------------------------------

Susan,

                Following find my comments in re this document..

                General Comments.

                1) There is a need to better define what is meant by the "halfway point" between completely replacing the distributed control plane and configuring it all. It would seem to be that this "halfway point" is different based on what is being programmed. To that end it would be useful to call out higher level reqs some suggestions.

                2) Dissemination Scope of an I2RS Instruction Set ( Block of instructions intended to be atomic ) - An instruction set may be local or global in nature as it pertains to affected the distributed control plane when configured on a network element.

                                a)  A locally scoped instruction set may configure routing state in the RIB for comparison purposes but that state may not be disseminated via the distributed control  plane.

                                b) A globally scoped instruction set must configure routing state in the RIB for comparison purposes and that state is available for dissemination subject to any other policy.


                3) Ephemeral/Persistent Scope of an I2RS Instruction Set

                                a) Should the instruction set persist? What comes to mind for me are the "configuration" like changes i.e RT-C, FlowSpec .

                4) Liveness/Safety Properties - Would like to see some discussion in re these items.

                5) Uses Cases - I believe addl use cases whose focus is on configuration like services would be desirable. As an ex.. RT-C..

                Specific Comments

                C1 - P1 - Para 2

                ..." Such a system would not interact...." The paragraph uses a routing and best path selection as an example. I assume that this not limited to this application but spans configuration like state etc....

                C2 - P3 -Para 1

                "This represents a "halfway point" ..." This needs a clearer definition, I would suggest wording regarding  how the distributed control plane will be augmented by the addition of I2RS

                C3 - P3 - Para 3

                "...Each unique has been" Typo missing the word reqs.

                C4 - P3 - Para 5

                The reaction to Network Based Attacks may also include other actions i.e mirror, drop ...I assume you are not limiting the response to the attack to only re-direct.

                C5 - P4 - Para 4 1st Bullet

                Can the I2RS agent interact with other tools and get the desired info in this case available routes in the RIB? In general can I2RS provide a framework to collect data from multiple sources including directly from a router, RR, NM?

                C6 - P4 - Para 4 2nd Bullet

                Need to describe in how state learned via I2RS agent and state learned via distributed control plane interact across the set of applications ( See Above General Comments. )

                C7 - P5 - Para 4 3rd Bullet

                What is the ask for here? Is there a consistent definition of /dev/null being sought?

                C8 - P5 -Para 4 4th Bullet

                Not sure what this req is. Is it saying the policies configured via distributed control plane, local  and/or via I2Rs should have some form of id? Why is this needed if the policy no matter where it is learned is recorded in the running configuration??

                C10 - P5 - Para `1

                "In hub and spoke..." There are other hub/spoke solutions i.e Virtual Hub Rekhter et al...that do not rely on a centralized server.



Jim Uttaro


From: UTTARO, JAMES
Sent: Wednesday, September 17, 2014 7:50 AM
To: 'Dean Bogdanovic'; 'Andy Bierman'
Cc: 'Jeffrey Haas'; 'Jmh.direct'; 'Joel Halpern'; '[e-mail]'
Subject: RE: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-00.txt

+1

From: i2rs [mailto:[e-mail]] On Behalf Of Dean Bogdanovic
Sent: Wednesday, September 17, 2014 7:33 AM
To: Andy Bierman
Cc: Jeffrey Haas; Jmh.direct; Joel Halpern; [e-mail]<mailto:[e-mail]>
Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-00.txt

Andy,

Take an broadband edge scenario.  BRAS/BNG has 10s of thousand of subscribers. Through I2RS agent several subscriber related configurations have been added. Box reboots and all subscribers are gone. The subscriber related configuration has to be removed, as nobody knows if the subscriber incoming back and if it will get the same router properties.
IMO, use I2RS to change transient properties on the device.

Dean

On Sep 15, 2014, at 9:01 PM, Andy Bierman <[e-mail]<mailto:[e-mail]>> wrote:



On Mon, Sep 15, 2014 at 5:21 PM, Jmh.direct <[e-mail]<mailto:[e-mail]>> wrote:
The WG discussed this extensively.
Any effort to persist I2RS state introduces significant complexity.  In particular, very few configs have a mechanism to store a prrvious state so that thr system will behave correctly when the I2RS agent deletes the state it has created.  And there were other problems noted.
Whime some folks wanted petsistance, as a participant the conclusion of the WG was quite clear.


I am OK with leaving out persistence.  If glitches cause problems, vendors
will extend the standard with proprietary attempts to fix them.
There is complexity either way.


Yours,
Joel

Andy


Sent from my Samsung smartphone on AT&T



-------- Original message --------
Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-00.txt
From: Andy Bierman <[e-mail]<mailto:[e-mail]>>
To: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>
CC: "Joel M. Halpern" <[e-mail]<mailto:[e-mail]>>,"[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>


On Mon, Sep 15, 2014 at 11:01 AM, Jeffrey Haas <[e-mail]<mailto:[e-mail]>> wrote:
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?

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.



> 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


Andy


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