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

From: "Russ White" <[email-masked]>
Date: Sat, 30 Jan 2016 20:22:39 -0500

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.

==
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. 

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

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

"Determined" doesn't seem right here -- maybe "learned and/or calculated"
would be better?

==
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.

==
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).

==
This notification identifies that the associated I2RS Agent has started.

Maybe --

Notifies clients that this agent is starting.

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)?

==
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.

==
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.

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?

==
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.