Subject: [i2rs] sRE: Comments on draft-ietf-i2rs-architecture

From: "Susan Hares" <[email-masked]>
Date: Fri, 12 Feb 2016 07:35:38 -0500

Russ:

Thank you for the comments.  I apologize for the delay in responding.
Please See the comments below.   I've attached a difference on the text for
the changes I did agree to make plus one more: 

Deborah Brungard (our AD for this draft) also asked me 

   Thus, one of the key aims for I2RS is the keep the protocol and
   modeling architecture simple.  So for each architectural component or
   aspect, we ask ourselves "do we need this complexity, or is the
   behavior merely nice to have?"  Protocol parsimony is clearly a goal.
 
Deborah asked me to remove the last sentence. 

Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Russ White
Sent: Saturday, January 30, 2016 8:23 PM
To: [email-masked]
Subject: [i2rs] Comments on draft-ietf-i2rs-architecture

Y'all -- went through all the drafts last week, and have some comments,
mostly minor (I think). These are for the architecture draft.

:-)

Russ

==

Network-oriented applications require easy access to this information to
learn the network topology, to verify that programmed state is installed in
the forwarding plane, to measure the behavior of various flows, routes or
forwarding entries, as well as to understand the configured and active
states of the router.

Configuration and/or installation seems to be missing here. Maybe just add

--

Network-oriented applications also require easy access to an interface which
will allow them to program and control state related to forwarding.

-- to bring this into line with the remainder of the document.

Sue: I've added to version 13.  While it is a bit redundant - I think it
will help the reader. 

==

The I2RS provides a framework for registering and for requesting the
appropriate information for each particular application. The I2RS provides a
way for applications to customize network behavior while leveraging the
existing routing system as desired.

This would probably read better if these two sentences were reversed. 

Sue: Sounds good. 

I'm not certain what "registration" might mean here -- is this a stand-in
for installation/configuration?

Sue: Registering and requesting - includes the existing streams.  

.         configuration/installation where netmod/netconf registers
libraries and/or services,

.         registering/requesting of notification information in the pub/sub
notification streams,

.         registering/requesting of logging information in the logging
streams, 

.         registering/requesting of actions/responses (rpc/reply) in
netconf/netmod or the IPFIX registering/requesting of data streams (for
analytics),

It also leaves the door open for adopting new streams that are yet to be
created.  One future, might be a IoT stream that combines routing
config/notification/logging with data or security that is compressed. 

Given this information, do you have any specific suggestions? 

==

...manipulation of protocol-internal dynamically determined data is
envisioned.

"Determined" doesn't seem right here -- maybe "learned and/or calculated"

would be better?

Sue: Dynamically determined can be "learned, calculated, requested in
notification or logging, 

generated as a result of an action or a requested data stream of on-box
analytics stream. 

"Dynamically determined" seemed like the best way to say this in the
introduction.   What do you think?   

==

One example of a notification of such an event (which is unrelated to an
object creation, modification or deletion) is when a next-hop in the RIB is
resolved enough to be used by a RIB manager for installation in the
forwarding plane as part of a particular route.

"Resolved enough" seems a bit strained/awkward here. Maybe --

...when a next hop in the RIB is resolved in a way that allows it to be used
for forwarding..." 

-- or some such.

Sue: good addition.  Added to -version 13

==

Static System State: An I2RS agent needs access to static state on a routing
element beyond what is contained in the routing subsystem. 

This doesn't feel quite right... Is this trying to describe things that
cannot be changed because they are locally/manually configured, or because
they are simply a part of the unchangeable embedded software on the device,
or because they are out of scope for the I2RS interface? It seems like this
is trying to say the first, but it's not quite clear. Maybe - 

Static System State: An I2RS agent needs access to state that it nonetheless
cannot change (because it is locally configured, a value embedded in
hardware, or is out of the scope of the I2RS interface).

Sue:  Static System State: Is trying to get at the environment the I2RS
client is in. Compared to the dynamic

Nature of routing, the security environment, the embedded system
environment, the hardware environment

are all relatively static state.   

How about this change: 

Old:/

Static System State: An I2RS agent needs access to static state on a routing
element beyond what is contained in the routing subsystem.  An example of
such state is specifying queueing behavior for an interface or traffic. How
the I2RS agent modifies or obtains this information is out of scope, but the
standardized

information and data models for what is exposed are part of I2RS.

New:/

Static System State: An I2RS agent needs access to static state on a routing
element beyond what is contained in the routing subsystem.  An example of
such state is specifying queueing behavior for an interface or traffic. A
second example of such state is the security environment the routing system
runs in.  How the I2RS agent modifies or obtains this information is out of
scope, but the standardized information and data models for what is exposed
are part of I2RS.

==

This notification identifies that the associated I2RS Agent has started.

Maybe --

Notifies clients that this agent is starting.

Sue: Textual change: 

Old:/ This notification identifies that the associated I2RS Agent has
started./

New:/This notification signals to the I2RS Client(s) that this I2RS Agent
has started./

Question: 

Where would the list of clients to send this notification come from? Are we
assuming manual configuration, as data isn't kept between restarts (I2RS is
only supposed to manage ephemeral state)?

Sue's Response: 

List of clients to send the notification to is kept in manual I2RS
configuration which survives a reboot.

Old: 

/NOTIFICATION_I2RS_AGENT_STARTING:   This notification identifies that

the associated I2RS Agent has started.  It includes an agent-boot-

count that indicates how many times the I2RS Agent has restarted

since the associated routing element restarted.  The agent-boot-

count allows an I2RS Client to determine if the I2RS Agent has

restarted.

/

New/

NOTIFICATION_I2RS_AGENT_STARTING:  This notification

Signals to the I2RS Client(s) that the associated I2RS Agent has started.  

It includes an agent-boot-count that indicates how many times the 

I2RS Agent has restarted since the associated routing element restarted.

The agent-boot-count allows an I2RS Client to determine if the I2RS Agent

has restarted. (Note: The list of I2RS clients to send the 

notification after the reboot and the agent-boot-count must 

survive the reboot process.) 

/

==

This notification reports that the associated I2RS Agent is shutting down
gracefully. Ephemeral state will be removed.

This just feels choppy -- these two sentences could be merged, I think.

Sue: Good catch

old: /This notification reports that the associated I2RS Agent is shutting
down gracefully. Ephemeral state will be removed./

New: This notification reports that the associated I2RS Agent is shutting
down gracefully, and

that I2RS ephemeral state will be removed./

==

T.3 Text:/  

Changes may originate from either Local Configuration or from I2RS. The
modifications and data stored by I2RS are separate from the local device
configuration, but conflicts between the two must be resolved in a
deterministic manner that respects operator-applied policy. That policy can
determine whether Local Configuration overrides a particular I2RS client's
request or vice versa. To achieve this end, either by default Local
Configuration always wins.

/

Is the agent responsible for restoring local state that is overridden, or
not? The entire problem of local state and it's interaction with the I2RS
agent needs to be more fully explored/explained, or at least there needs to
be something saying, "the interaction between locally configured state and
state injected by an I2RS agent is implementation and object dependent." If
it is object dependent, however, this is something that might need to
considered in the YANG models.

Sue:  By Default, the I2RS Agent is responsible for restoring state after
the I2RS agent goes away.   Conceptually, this is the simply removing the
ephemeral state out of the combined yang module.  

There are the following yang module cases: 

1)       independent module non-interacting (I2RS topology module),

2)      Independent module interacting (I2RS RIB) - interacts with
ietf-netmod-routing-cfg + static routes

Or the FB-RIB forwarding (configuration, I2RS,  BGP-FlowSpecification). 

3)      Dependent module - dependent function - BGP local route added to BGP
routes, 

4)      Dependent module - independent function - BGP monitoring of data  

Each of these cases take planning for the interaction between Yang models in
standard way. 

However, the operators have indicated the specifics of interactions between
yang module, or between yang modules and proprietary configuration must be
able to be governed by operator-applied policy. The requirement in standards
is to build the knobs between config/operational yang modules (I2RS and
other modules), and allow knobs to be added to control interaction between
standardize yang modules and proprietary. 

/new - my text in red. 

Changes may originate from either Local Configuration or from I2RS. The

modifications and data stored by I2RS are separate from the local

device configuration, but conflicts between the two must be resolved

in a deterministic manner that respects operator-applied policy.  

The deterministic model must be clearly indicated by each 

I2RS data model based on a combination of 

the general I2RS rules, rules associated with the data model, 

and knobs for adjusted by operator-applied policy.    

This operator-applied policy can determine whether Local Configuration 

overrides a particular I2RS client's request or vice versa.  

To achieve this end, the I2RS data modules have a general

rule that default Local Configuration always wins.

Optionally, an I2RS data model may be allow an operator-applied

policy to permit a priority to be configured on the device for 

the Local Configuration mechanism interaction with the I2RS model.

The policy mechanism would compare the

I2RS client's priority with that priority assigned to the

Local Configuration in order to determine which wins for this data model. 

==========

Is the above change enough or should I add the following 

A non-defining example may clarify this situation: 

.         Assume I2RS two general rules of: 

o   I2RS ephemeral state supercedes configured state,  

o   By default, updating the configured state causes the ephemeral state to
be lost, and a notification to be sent to the I2RS Client.

The I2RS RIB could define a knob that allows the priority route of an
ephemeral route in the I2RS RIB ephemeral route to be higher than a static
route so that if a state route is updated for a specific prefix, then the
route from I2RS RIB's ephemeral state  still takes precedence. 

========

Another question -- this is a political football, I know -- but the agent is
responsible for restoring locally configured state that is overwritten, how
is this more complex or harder than restoring the state written by multiple
clients?

Sue: 2016 is Chinese year of the monkey.  The monkey for I2RS in 2016 is the
multiple client induced state.  

You and I believe that multiple states are as easy as single state, but when
I took over as

Chair I agreed not to undo existing I2RS WG decision for a single pane of
glass. 

I believe two pane system (I2RS/Config) will work even if the multiple panes
of glass is more deployable. 

==

All such communication channels will use the same higher level I2RS
protocol.

I'm struggling with what this might mean -- transport protocol? YANG model
(marshalling protocol)? If there's a specific protocol in mind (there is,
right?), perhaps it would be best just to name it here.

Sue:  The challenge is that I2RS goals were not to create a protocol even
though the language from the bottom up even though the language makes it
seem like we are . Let me describe it and then let us work on language. 

The I2RS protocol is comprised of a set of protocols:   configuration
protocols (netconf/restconf/?) with additions for I2RS (ephemeral state,
secure protocol, multi-headed (future))  plus analytical protocols (IPFix /
?? ) + an understanding of the security environment + a secure transport
protocol with a set of security information associated with it. 

We used the phrase higher-level protocol.  If it is unclear, should the term
"higher-layer protocol" be defined in definition or in this section? 

_______________________________________________

i2rs mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Russ White" <[email-masked]>
Date: Fri, 12 Feb 2016 21:48:44 -0500

> Sue: Registering and requesting - includes the existing streams.

I think the question I had when reading this is "who is registering and
requesting the streams?" Maybe just: "a framework for
applications/controllers/??? To register and request information from agents
running on forwarding devices..." Or some such might make it clearer. 

> introduction.   What do you think?

I guess it's okay, just something about dynamic stuff and determined stuff
doesn't seem to fit together for me. :-)

> scope, but the standardized information and data models for what is
> exposed are part of I2RS.

This is fine...

started./
> New:/This notification signals to the I2RS Client(s) that this I2RS Agent
has
> started./

This is fine...

> survive the reboot process.)

Or perhaps --

Note: This notification will only be transmitted to I2RS clients which are
known in some way after a reboot. The agent-boot-count MUST survive the
reboot process.

> old: /This notification reports that the associated I2RS Agent is shutting
down
> gracefully. Ephemeral state will be removed./
> 

This is good.

> Sue:  By Default, the I2RS Agent is responsible for restoring state
> after the I2RS agent goes away.   Conceptually, this is the simply
> removing the ephemeral state out of the combined yang module.

I think the paragraph in question implies something more than just the agent
going away, though -- it implies the withdrawal of ephemeral data by a
client. Your answer implies this is handled by the model, rather than the
agent -- but I'm not certain how this would work. Is the assumption that the
subsystem the agent is controlling will have both of the two sets of state,
and will always choose the ephemeral over the configured? Or is the
assumption that the agent will always have this information?

> There are the following yang module cases:

There is another potential case, as well -- the ephemeral state currently
wins, but a user locally configures something that should override the
ephemeral state. This seems to add a lot of the same complexity the "single
pane of glass" is trying to avoid. Perhaps it should be called out in the
draft that locally configured state is never allowed to overwrite ephemeral
state once the ephemeral state is written -- IE, once the agent wins over
the locally configured state, this can never be changed (?), if we're really
to avoid the complexity?

> responsible for restoring locally configured state that is overwritten,
how is
> this more complex or harder than restoring the state written by multiple
> clients?

> You and I believe that multiple states are as easy as single state, but
when I
> took over as

Actually, I don't think the complexity has been avoided at all -- it still
exists in the interaction between the local configured state and the
ephemeral state managed by the agent. Complexity is like that -- it crops up
when you don't expect it. Once the local state/agent state is resolved,
multiple panes of glass will already be solved.

protocol.
> (marshalling protocol)? If there's a specific protocol in mind (there is,
right?),
> perhaps it would be best just to name it here.
> 

> "higher-layer protocol" be defined in definition or in this section?

Or maybe just say, "a transport protocol?" I don't know what a "higher level
protocol" means -- does it mean the protocol is higher up the OSI protocol
stack, more abstract, lower on the OSI stack, or... ?? 

:-)

Russ

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 15 Feb 2016 08:51:50 -0500

Focusing on the remaining two remaining items - I've suggested text below.
I've attached a difference for just these last two changes.

Sue 

1)      Interactions with Local Configuration

rule that by default the Local Configuration always wins.

Optionally, an I2RS data model may allow an operator-applied

The policy mechanism would compare the I2RS client's priority 

with that priority assigned to the Local Configuration in order

to determine which wins for this data model.  

For the case when the I2RS ephemeral state always wins for a data model, 

if there is an I2RS ephemeral state value it is installed 

instead of the local configuration state. 

The local configuration information is stored so that if/when 

I2RS client removes I2RS ephemeral state the local configuration 

state can be restored.  

When the Local Configuration always wins, some communication between that

subsystem and the I2RS Agent is still necessary.  

As an I2RS Agent connects to the routing sub-system, the 

I2RS Agent must also communicate with the Local Configuration 

to exchange model information so the I2RS agent knows the 

details of each specific device configuration change that

the I2RS Agent is permitted to modify.  In addition, when the system

determines, that a client's I2RS state is preempted, the I2RS agent

must notify the affected I2RS clients; how the system determines this

is implementation-dependent. 

2) higher layer protocol 

/old:

All such

communication channels will use the same higher-layer I2RS protocol. 

/new: 

All such communication channels will use the same higher-layer I2RS protocol

(which combines secure transport and I2RS contextual information).

Let me know if you think 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Russ White
Sent: Friday, February 12, 2016 9:49 PM
To: 'Susan Hares'; [email-masked]
Cc: ''Alia Atlas''
Subject: Re: [i2rs] Comments on draft-ietf-i2rs-architecture

> appropriate information for each particular application. The I2RS 

> provides

a

> way for applications to customize network behavior while leveraging 

> the existing routing system as desired.

/new: 

The I2RS provides a framework for applications (including

                  controller applications) to register and to request the 

                  appropriate information for each particular application.

Sue: If you think of something better, let me know. 

> Static System State: An I2RS agent needs access to static state on a

routing

> element beyond what is contained in the routing subsystem.  An example 

> of such state is specifying queueing behavior for an interface or 

> traffic. A second example of such state is the security environment 

> the routing

system

> runs in.  How the I2RS agent modifies or obtains this information is 

> out

of

This is fine...

Sue: Thanks 

started./

> New:/This notification signals to the I2RS Client(s) that this I2RS 

> Agent

has

This is fine...

Sue: Thanks 

> NOTIFICATION_I2RS_AGENT_STARTING:  This notification Signals to the 

> I2RS Client(s) that the associated I2RS Agent has started.

> It includes an agent-boot-count that indicates how many times the I2RS 

> Agent has restarted since the associated routing element restarted.

> The agent-boot-count allows an I2RS Client to determine if the I2RS 

> Agent has restarted. (Note: The list of I2RS clients to send the 

> notification after the reboot and the agent-boot-count must survive 

> the reboot process.)

Or perhaps --

Sue: Good text change.  I've adopted this one. 

> old: /This notification reports that the associated I2RS Agent is 

> shutting

down

> New: This notification reports that the associated I2RS Agent is 

> shutting down gracefully, and that I2RS ephemeral state will be 

> removed./

This is good.

Sue: Thanks 

Sue:  (this next few paragraphs are explanation - I still need to determine
if I need to fix something). 

The paragraph deals with interactions between the Local Configuration (yang
model) and the 

I2RS-Agent (yang model).   Yes, the I2RS agent needs to have both sets of
state (config and I2RS agent)

for any model where the two overlap in some meaningful way.   The I2RS Agent
should always have the information about the two panes [I2RS and Config] and
the merged result.    

For example,  I2RS RIB and ietf-netmod-routing-cfg - will overlap in some
static routes.  The two models should know what intersection there is and
the I2RS RIB could overlap.  By default, the I2RS Ephemeral state should
take precedence over the config.  The operator-applied policy, could alter
this precedence for all routes or a single route.    As another example, the
I2RS Topology model gathers information but does not configure over existing
models.  The I2RS Topology model has precedence, but there is no
intersecting topology model. 

===

=====

We are still dealing with 2 panes of glass:  I2RS pane and Configuration
pane.  The single pane of glass is just the idea that the I2RS panes reduce
to a single view for I2RS.   

The priority of the two planes needs to stay constant once established.  If
the ephemeral state is by general rule and/or operator-priority the highest
precedence (meaning it overwrites then config pane), then it stays
overwritten.   The changes going on to the configuration pane occur in the
background, and the changes to the ephemeral stay in the fore-ground.   In
this case, when the ephemeral state disappears - the current configuration
pane must be re-asserted as the state. 

If the configuration pane has the highest priority, the ephemeral state only
changes what the configuration state does not have.   If the configuration
writes over an ephemeral state, the state is lost and the I2RS agent sends a
notification to the I2RS Client.  

> Another question -- this is a political football, I know -- but the 

> agent is responsible for restoring locally configured state that is 

> overwritten, how is  this more complex or harder than restoring the state
written by 

> multiple clients?

> You and I believe that multiple states are as easy as single state, 

> but when I took over as Chair I agreed not to undo existing I2RS WG
decision for a single pane 

> of glass.

Sue:  I agree the complexity is now between two panes of glass (config/I2RS)

Here's the text for this section: 

rule that by default the Local Configuration always wins.

Optionally, an I2RS data model may allow an operator-applied

The policy mechanism would compare the I2RS client's priority 

with that priority assigned to the Local Configuration in order

to determine which wins for this data model.  

For the case when the I2RS ephemeral state always wins for a data model, 

if there is an I2RS ephemeral state value it is installed 

instead of the local configuration state. 

The local configuration information is stored so that if/when 

I2RS client removes I2RS ephemeral state the local configuration 

state can be restored.  

When the Local Configuration always wins, some communication between that

subsystem and the I2RS Agent is still necessary.  

As an I2RS Agent connects to the routing sub-system, the 

I2RS Agent must also communicate with the Local Configuration 

to exchange model information so the I2RS agent knows the 

details of each specific device configuration change that

the I2RS Agent is permitted to modify.  In addition, when the system

determines, that a client's I2RS state is preempted, the I2RS agent

must notify the affected I2RS clients; how the system determines this

is implementation-dependent. 

===================

protocol.

> I'm struggling with what this might mean -- transport protocol? YANG 

> model (marshalling protocol)? If there's a specific protocol in mind 

> (there is,

right?),

> Sue:  The challenge is that I2RS goals were not to create a protocol 

> even though the language from the bottom up even though the language 

> makes it seem like we are . Let me describe it and then let us work on
language.

> We used the phrase higher-level protocol.  If it is unclear, should 

> the term

Sue: 

/old:

All such

communication channels will use the same higher-layer I2RS protocol. 

/new: 

All such communication channels will use the same higher-layer I2RS protocol

(which combines secure transport and I2RS contextual information).

i2rs mailing list

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Feb 2016 12:20:34 -0500

Basic problem with the proposed text.
The policy for resolving the conflict is NOT per-model.  It is defined 
by the architecture, system, and protocol.  Declaring that the 
resolution must be indicated by each data model seems flat wrong.

Yours,
Joel

On 2/15/16 8:51 AM, Susan Hares wrote:
> Focusing on the remaining two remaining items – I’ve suggested text
> below.  I’ve attached a difference for just these last two changes.
>
> Sue
>
> 1)Interactions with Local Configuration
>
> applications/controllers/??? To register and request information from
> agents running on forwarding devices..." Or some such might make it
> clearer.
>
> /new:
>
> I guess it's okay, just something about dynamic stuff and determined
> stuff doesn't seem to fit together for me. :-)
>
> Note: This notification will only be transmitted to I2RS clients which
> are known in some way after a reboot. The agent-boot-count MUST survive
> the reboot process.
>
> Sue: Good text change.  I’ve adopted this one.
>
> I think the paragraph in question implies something more than just the
> agent going away, though -- it implies the withdrawal of ephemeral data
> by a client. Your answer implies this is handled by the model, rather
> than the agent -- but I'm not certain how this would work. Is the
> assumption that the subsystem the agent is controlling will have both of
> the two sets of state, and will always choose the ephemeral over the
> configured? Or is the assumption that the agent will always have this
> information?
>
> Sue:  (this next few paragraphs are explanation – I still need to
> determine if I need to fix something).
>
> The paragraph deals with interactions between the Local Configuration
> (yang model) and the
>
> I2RS-Agent (yang model).   Yes, the I2RS agent needs to have both sets
> of state (config and I2RS agent)
>
> for any model where the two overlap in some meaningful way.   The I2RS
> Agent should always have the information about the two panes [I2RS and
> Config] and the merged result.
>
> For example,  I2RS RIB and ietf-netmod-routing-cfg – will overlap in
> some static routes.  The two models should know what intersection there
> is and the I2RS RIB could overlap.  By default, the I2RS Ephemeral state
> should take precedence over the config.  The operator-applied policy,
> could alter this precedence for all routes or a single route.    As
> another example, the I2RS Topology model gathers information but does
> not configure over existing models.  The I2RS Topology model has
> precedence, but there is no intersecting topology model.
>
> ===
>
> There is another potential case, as well -- the ephemeral state
> currently wins, but a user locally configures something that should
> override the ephemeral state. This seems to add a lot of the same
> complexity the "single pane of glass" is trying to avoid. Perhaps it
> should be called out in the draft that locally configured state is never
> allowed to overwrite ephemeral state once the ephemeral state is written
> -- IE, once the agent wins over the locally configured state, this can
> never be changed (?), if we're really to avoid the complexity?
>
> =====
>
> pane.  The single pane of glass is just the idea that the I2RS panes
> reduce to a single view for I2RS.
>
> The priority of the two planes needs to stay constant once established.
>   If the ephemeral state is by general rule and/or operator-priority the
> highest precedence (meaning it overwrites then config pane), then it
> stays overwritten.   The changes going on to the configuration pane
> occur in the background, and the changes to the ephemeral stay in the
> fore-ground.   In this case, when the ephemeral state disappears – the
> current configuration pane must be re-asserted as the state.
>
> If the configuration pane has the highest priority, the ephemeral state
> only changes what the configuration state does not have.   If the
> configuration writes over an ephemeral state, the state is lost and the
> I2RS agent sends a notification to the I2RS Client.
>
>  > overwritten, how is  this more complex or harder than restoring the
> state written by
>
>  > multiple clients?
>
> Actually, I don't think the complexity has been avoided at all -- it
> still exists in the interaction between the local configured state and
> the ephemeral state managed by the agent. Complexity is like that -- it
> crops up when you don't expect it. Once the local state/agent state is
> resolved, multiple panes of glass will already be solved.
>
> Here’s the text for this section:
>
>  > makes it seem like we are . Let me describe it and then let us work
> on language.
>
> Or maybe just say, "a transport protocol?" I don't know what a "higher
> level protocol" means -- does it mean the protocol is higher up the OSI
> protocol stack, more abstract, lower on the OSI stack, or... ??
>
> Sue:
>
> /old:
>
> All such
>
> [email-masked] <mailto:[email-masked]>
>
> [email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 17 Feb 2016 07:53:21 -0500

Joel: 

Let me resetting the discussion without working on text. I may have text
that does not represent my true beliefs.   

Assumptions: 

#1) We are discussing Local Configuration and I2RS Configuration.  We are
not discussing I2RS operational state. 

#2) I believe the general rules for resolving conflict are per architecture,
per system, and per I2RS protocol.  By this I specifically mean per I2RS
architecture document, per system's policy (proprietary configuration +
operator-applied policy with knobs by either standards or proprietary
configuration), and per I2rs protocol  (netconf/restconf/x for
configuration,  data reporting (E.g. IPFiX).

#3) After working with Local Configuration and I2RS Configuration,  you must
combine these if I2RS is going to work.  For example,  I2RS RIB route
depends on interfaces and the interface being up to install the route as
active.  

[Hopefully, we agree on #1 +#2, and are discussing #3] 

A an example, you would have at this point for a route associated with an
interface: 

a) general I2RS rules from architecture and protocol - (default local
configuration wins) 

b) system state that says the Local Configuration Wins (by default),  

c) local configuration of system for the interface (configured and
administratively up)    

d) local operational state of interface (UP) 

e) I2RS configuration for the I2RS RIB data model.  

   [Data model rule] 

   The data model does not allow 

    the route to be active unless it can be installed 

    in the FIB.  It is installed. 

Then the local configuration (which always wins) administratively

configures the Interface down  

a) general I2RS rules - default Local configuration wins, 

b) system state - local configuration wins

c) local configuration of system for interface: down administratively 

d) local operational state down. 

e) I2RS system detects the local configuration change,  [Data model] 

   notifies I2RS RIB process which checks the dependent state 

   in I2RS RIB for interface.   

f) I2RS RIB code transitions route from active to inactive,  [Data model]  

g) I2RS agent send notification to the I2RS client regarding

    data in the I2RS RIB

================= 

Therefore, I included the last sentence in the paragraph:  that indicates

Rules associated with the data with the I2RS Data model.  

   "Changes may originate from either Local Configuration or from I2RS.

   The modifications and data stored by I2RS are separate from the local

   in a deterministic manner that respects operator-applied policy.  The

   deterministic model must be clearly indicated by each I2RS data model

   based on a combination of the general I2RS rules, rules associated

   with the data model, and knobs for adjusted by operator-applied

   policy."

Are you concerned about this statement?   Or text below this statement in
section 6.3. 

I would like to make sure the architecture and the I2RS only data models are
aligned. 

Sue 

-----Original Message-----

From: Joel M. Halpern [mailto:[email-masked]] 

Sent: Monday, February 15, 2016 12:21 PM

To: Susan Hares; 'Russ White'; [email-masked]

Cc: ''Alia Atlas''

The policy for resolving the conflict is NOT per-model.  It is defined by
the architecture, system, and protocol.  Declaring that the resolution must
be indicated by each data model seems flat wrong.

Yours,

Joel

On 2/15/16 8:51 AM, Susan Hares wrote:

> Focusing on the remaining two remaining items - I've suggested text 

> below.  I've attached a difference for just these last two changes.

> Changes may originate from either Local Configuration or from I2RS. 

> The

> For the case when the I2RS ephemeral state always wins for a data 

> model,

> When the Local Configuration always wins, some communication between 

> that

> All such communication channels will use the same higher-layer I2RS 

> protocol

>  > The I2RS provides a framework for registering and for requesting 

> the

> I think the question I had when reading this is "who is registering 

> and requesting the streams?" Maybe just: "a framework for 

>                    controller applications) to register and to request 

> the

>  > "Dynamically determined" seemed like the best way to say this in 

> the

>  > Static System State: An I2RS agent needs access to static state on 

>  > element beyond what is contained in the routing subsystem.  An 

> example

>  > runs in.  How the I2RS agent modifies or obtains this information 

> is

>  > Old:/ This notification identifies that the associated I2RS Agent 

> I2RS

> are known in some way after a reboot. The agent-boot-count MUST 

> survive the reboot process.

> agent going away, though -- it implies the withdrawal of ephemeral 

> data by a client. Your answer implies this is handled by the model, 

> rather than the agent -- but I'm not certain how this would work. Is 

> the assumption that the subsystem the agent is controlling will have 

> both of the two sets of state, and will always choose the ephemeral 

> over the configured? Or is the assumption that the agent will always 

> have this information?

> Sue:  (this next few paragraphs are explanation - I still need to 

> For example,  I2RS RIB and ietf-netmod-routing-cfg - will overlap in 

> some static routes.  The two models should know what intersection 

> there is and the I2RS RIB could overlap.  By default, the I2RS 

> Ephemeral state should take precedence over the config.  The
operator-applied policy,

> should be called out in the draft that locally configured state is 

> never allowed to overwrite ephemeral state once the ephemeral state is 

> written

> We are still dealing with 2 panes of glass:  I2RS pane and 

> Configuration pane.  The single pane of glass is just the idea that 

> the I2RS panes reduce to a single view for I2RS.

>   If the ephemeral state is by general rule and/or operator-priority 

> the highest precedence (meaning it overwrites then config pane), then it

> fore-ground.   In this case, when the ephemeral state disappears - the

> configuration writes over an ephemeral state, the state is lost and 

> the I2RS agent sends a notification to the I2RS Client.

> the ephemeral state managed by the agent. Complexity is like that -- 

> it crops up when you don't expect it. Once the local state/agent state 

> is resolved, multiple panes of glass will already be solved.

> Sue:  I agree the complexity is now between two panes of glass

> (config/I2RS)

> Changes may originate from either Local Configuration or from I2RS. 

> The

> For the case when the I2RS ephemeral state always wins for a data 

> model,

> When the Local Configuration always wins, some communication between 

> that

>  > I'm struggling with what this might mean -- transport protocol? 

> YANG

>  > model (marshalling protocol)? If there's a specific protocol in 

> mind

>  > Sue:  The challenge is that I2RS goals were not to create a 

> protocol

>  > even though the language from the bottom up even though the 

> language

> level protocol" means -- does it mean the protocol is higher up the 

> OSI protocol stack, more abstract, lower on the OSI stack, or... ??

> All such communication channels will use the same higher-layer I2RS 

> protocol

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 17 Feb 2016 11:32:21 -0500

Yoru point 3 is not what the text you quoted covers.
Your point three is described by the use of clauses like MUST and WHEN 
in the data model.  Those conditions have little or nothing to do with 
the relationship in terms of priority of information between local 
configuration and I2RS configuration.  Rather, they represent data model 
requirements that may point at other ephemeral data, or at local config 
data, or anything else that MUST and WHEN are allowed to point at.
Such conditions exist even within local configuration.  That is why YANG 
has MUST and WHEN clauses.
Including the text you have proposed in that section, and then again 
later in another change you made confuses the reader.  For the issue you 
describe in point 3, there is nothing you need to say.

If there is anything to be added, it would be a completely different 
statement that notes that I2RS ephemeral configuration may reference 
existing data on the routing system, including local configuration.  I 
thought we said taht, but maybe we didn't.  (We had that topic come up 
in conversations about how to make ephemeral configuration work, and 
agreed that such references were necessary.)

Yours,
Joel

On 2/17/16 7:53 AM, Susan Hares wrote:
> #1) We are discussing Local Configuration and I2RS Configuration.  We
> are not discussing I2RS operational state.
>
> #2) I believe the general rules for resolving conflict are per
> architecture, per system, and per I2RS protocol.  By this I specifically
> mean per I2RS architecture document, per system's policy (proprietary
> configuration + operator-applied policy with knobs by either standards
> or proprietary configuration), and per I2rs protocol
> (netconf/restconf/x for configuration,  data reporting (E.g. IPFiX).
>
> #3) After working with Local Configuration and I2RS Configuration,  you
> must combine these if I2RS is going to work.  For example,  I2RS RIB
> route depends on interfaces and the interface being up to install the
> route as active.
>
> A an example, you would have at this point for a route associated with
> an interface:
>
>     “Changes may originate from either Local Configuration or from I2RS.
>
>     policy.”
> Are you concerned about this statement?   Or text below this statement
> in section 6.3.
>
> I would like to make sure the architecture and the I2RS only data models
> are aligned.
>
> Sue
>
> To: Susan Hares; 'Russ White'; [email-masked] <mailto:[email-masked]>
>
> Cc: ''Alia Atlas''
>
>  > To: 'Susan Hares'; [email-masked] <mailto:[email-masked]>
>
>  > Cc: ''Alia Atlas''
>
>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>
>  >
>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 17 Feb 2016 14:04:03 -0500

Joel: 

I'm glad we agree up to point #3, and that yang clauses "MUST" and "WHEN"
should be used order for the models to work.  Per
ietf-netmod-rfc6020bis-09.txt, the "MUST" constrains the data, and the
"WHEN" indicates code that occurs when some constraint happens.   These
statements allow Yang to indicate rules for the Data model.  It is these
statements I mean by data-model rules. 

It is the combination of rules that impact the how the local-configurations
actions impact each model.   I suggest that some combinations where I2RS
depends on the local configuration (E.g. I2RS RIB depending on the
interface), some settings of global rules, system rules, and
operator-applied rules will not make sense based on the model.   For some
cases, such as two routes being configured (local configuration) and I2RS
configuration referencing the same interface - all combinations will work.  

Perhaps this says it better: 
[starting at the last sentence of the first paragraph] 
The deterministic model is the result of general I2RS rules, system rules,
knobs adjust by operator-applied policy, and the rules associated with the
yang data model (often in MUST and WHEN clauses for dependencies).  

This operator-applied policy can determine whether Local Configuration
overrides a particular I2RS client's request or vice versa.  To achieve this
end, the I2RS architecture has a general rule that by default the Local
Configuration always wins. Optionally, an I2RS data model may allow an
operator-applied policy  to permit a priority to be configured on the device
for the Local Configuration mechanism interaction with the I2RS agent's data
model(s).  This policy  mechanism would compare the I2RS client's priority
with that priority
assigned to the Local Configuration in order to determine which wins for
this data model(s). 

[Not sure if you wanted the policy knob to be per model or per models. ]
An example that undergirds my proposal is below. 

Thanks again for reviewing this work.  It helps me with the I2RS protocol
strawman. 

Sue 

=========
Here's more detail on the example that undergirds these statements: 
 
If we go back to my example, 
a) general I2RS rules from architecture and protocol - (default local
configuration wins) 
b) system state that says the Local Configuration Wins (by default),  
c) Operator-applied priority - is (local configuration wins) 
d) local configuration of system for the interface (configured and
administratively up)    
e) local operational state of interface (UP) 
f) I2RS configuration for the I2RS RIB data model.  
      I2RS RIB MUST have valid IETF Yang model
      I2RS RIB has the cases:  
           f-1)WHEN interface is not configured  [I2RS route is inactive] 
           f-2) WHEN interface exists and status up  [install I2RS route as
active] 
           f-3) WHEN interface status down [I2RS route is inactive] 
           f-4) WHEN interface changes configuration [I2RS route policy must
be tested]

f-1: 
If the local configuration changes to not configured (aka removes
configuration),  the case is f-1.   f-1 case rules are:  architecture,
default I2RS system priority (Local-Config wins), Operator-applied priority
(Local-Config wins), data model rule (MUST/WHEN e-3)

F-3: If the local configuration changes to interface down,  the when in case
f-3 is engaged.  f-3 case rules are: architecture, default I2RS system
priority (Local-Config wins), Operator-applied priority (Local-Config wins),
data-model rule (MUST/WHEN f-3). 

F-4: If the local configuration changes the configuration of the interface,
I2RS must test to see if the policy was the interface address or the
interface itself.  The current I2RS RIB has policy for:  egress Interface
with v4 address, interface with v6 address, or 
Egress Interface with MAC address.  WHEN (policy) = valid, then the route
stays installed, else route is not installed. 

F-4 rules:  architecture (default local configuration wins), system (local
configurations), operator-policy (Local-configuration wins) [same as past]
F-4: I2RS RIB model When clauses: 
- When (interface policy(new-interface)=valid), then keep route. 
- When (interface-policy(new-interface)=invalid, route status = inactive,
notification to client. 

I do not see how the WHEN Clauses for F-1, F-3, F-4 do not constitute I2RS
RIB yang model related rules.  Are we struggling over the concept of "I2RS
Yang model rules"? If so, please let me know what you'd like to call these
cases 

==============
Case for I2RS wins by operator-applied policy  - going from F-2 to F-1, F-3,
and F-4  does work. 

a) general I2RS rules from architecture and protocol - (default local
configuration wins) 
b) system state that says the Local Configuration Wins (by default),
c) operator applied priority states:  I2RS Wins   
d) local configuration of system for the interface (configured and
administratively up)    
e) local operational state of interface (UP)  
f) I2RS configuration for the I2RS RIB data model.  
      I2RS RIB MUST have valid IETF Yang model
      I2RS RIB has the cases:  
           f-1)WHEN interface is not configured  [I2RS route is inactive] 
           f-2) WHEN interface exists and status up  [install I2RS route as
active] 
           f-3) WHEN interface status down [I2RS route is inactive]
           f-4) WHEN interface configuration changes [I2RS route may no
longer match]  

Case f-1: going from interface up to not-configure with the "I2RS MUST wins"
does not work.  The I2RS interface going not configured no longer allows
I2RS routes to function reliability.  This case must not be allowed in the
data model's logic. 

Case f-3: When going from interface up to status down, the I2RS MUST Win -
does not work.  The interface cannot be held up. 
Case F-4: When the interface configuration changes, the I2RS MUST win - does
not work.  If the configuration changes, the system cannot forward the
packet. 
 
====================================

The deterministic model must be clearly indicated by each I2RS data 
 model

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, February 17, 2016 11:32 AM
To: Susan Hares; 'Russ White'; [email-masked]
Cc: ''Alia Atlas''
Subject: Re: [i2rs] Comments on draft-ietf-i2rs-architecture

Yoru point 3 is not what the text you quoted covers.
Your point three is described by the use of clauses like MUST and WHEN in
the data model.  Those conditions have little or nothing to do with the
relationship in terms of priority of information between local configuration
and I2RS configuration.  Rather, they represent data model requirements that
may point at other ephemeral data, or at local config data, or anything else
that MUST and WHEN are allowed to point at.
Such conditions exist even within local configuration.  That is why YANG has
MUST and WHEN clauses.
Including the text you have proposed in that section, and then again later
in another change you made confuses the reader.  For the issue you describe
in point 3, there is nothing you need to say.

If there is anything to be added, it would be a completely different
statement that notes that I2RS ephemeral configuration may reference
existing data on the routing system, including local configuration.  I
thought we said taht, but maybe we didn't.  (We had that topic come up in
conversations about how to make ephemeral configuration work, and agreed
that such references were necessary.)

Yours,
Joel

On 2/17/16 7:53 AM, Susan Hares wrote:
> Joel:
>
> Let me resetting the discussion without working on text. I may have 
> text that does not represent my true beliefs.
>
> Assumptions:
>
> architecture, per system, and per I2RS protocol.  By this I 
> specifically mean per I2RS architecture document, per system's policy 
> (proprietary configuration + operator-applied policy with knobs by 
> either standards or proprietary configuration), and per I2rs protocol 
> #3) After working with Local Configuration and I2RS Configuration,  
> you must combine these if I2RS is going to work.  For example,  I2RS 
> RIB route depends on interfaces and the interface being up to install 
> the route as active.
>
> I would like to make sure the architecture and the I2RS only data 
> models are aligned.
>
> Sue
>
> survive

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 17 Feb 2016 14:17:04 -0500

The first emendation is fine.
The second paragraph you provide below strts by saying things that are 
accurate but misleading.  Yes, MUST and WHEN clauses in the ephemeral 
model will affect when the ephemeral changes can take place.  They are 
thus indirectly about when ephemeral can over-ride local-config.  But 
only indirectly.

When you say "Optional, an I2RS data model may allow an operator-applied 
policy to permit priority to be configured ..." you are saying something 
that I believe is wrong.
The working group has agreed that such priority can always be applied. 
An operator can choose to not to.  But an individual model can not say 
"priority does not apply to this model."  If you want to propose that we 
change the current statements to have a per-model flag that says whether 
priority is applied, we could have that discussion.  I consider it a 
VERy bad idea, and a source of additional complexity and confusion.

Yours,
Joel

---

From: "Russ White" <[email-masked]>
Date: Wed, 17 Feb 2016 21:31:02 -0500

> "priority does not apply to this model."  

I read what Sue has proposed in the opposite way -- that there is a per
model flag that says the operator may not override the priority on this
particular model through local configuration. I suppose the result might be
the same, but the wording implies this is something to be used sparingly, or
rather in the truly exceptional case where overriding the policy with local
configuration could cause major problems.

The only real question comes down to this -- should the agent always be able
to override the local configuration, or the local configuration should
always be able to override what the agent installs. Adding a bit here or
there isn't going to make this any more or less complex, it's just going to
mean either interpreting equal priorities as not truly equal, or having an
explicit bit that indicates intent. The functionality needs to be there
either so, so the complexity seems to be there either way (?).

:-)

Russ