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
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 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 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.
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 protected]] On Behalf Of Russ White
Sent: Friday, February 12, 2016 9:49 PM
To: 'Susan Hares'; [email protected]
Cc: ''Alia Atlas''
Subject: Re: [i2rs] Comments on draft-ietf-i2rs-architecture
> 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.
> 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.
/new:
The I2RS provides a framework for applications (including
controller applications) to register and to request the
appropriate information for each particular application.
> ...manipulation of protocol-internal dynamically determined data is
> envisioned.
> "Dynamically determined" seemed like the best way to say this in the
> 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. :-)
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
> scope, but the standardized information and data models for what is
> exposed are part of I2RS.
This is fine...
Sue: Thanks
> 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./
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 --
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.
> 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./
This is good.
Sue: Thanks
> 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?
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 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?
=====
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.
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.
Sue: I agree the complexity is now between two panes of glass
(config/I2RS)
Here’s the text for this section:
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 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 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.
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.
===================
> 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.
> 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?
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
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
