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
based on a combination of the general I2RS rules, rules associated
with the data model, and knobs for adjusted by operator-applied
policy."
-----Original Message-----
From: Joel M. Halpern [mailto:[email protected]]
Sent: Wednesday, February 17, 2016 11:32 AM
To: Susan Hares; 'Russ White'; [email protected]
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:
#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
>
