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
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.”
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 protected]]
Sent: Monday, February 15, 2016 12:21 PM
To: Susan Hares; 'Russ White'; [email protected] <mailto:[email protected]>
Cc: ''Alia Atlas''
Subject: Re: [i2rs] Comments on draft-ietf-i2rs-architecture
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] <mailto:[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]> <mailto:[email protected]>
>
> https://www.ietf.org/mailman/listinfo/i2rs
>
>
>
> _______________________________________________
> i2rs mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/i2rs
>
