Thank you for the careful reading and comments. I am going to have to
look at the document carefully to be able to propose good clarifying
text (maybe some of the other authors will be able to do so sooner).
Yours,
Joel
On 3/19/14, 7:53 PM, Kent Watsen wrote:
Per the request made at the meeting in London, I read
draft-ietf-i2rs-architecture-02 with the following comments.
Thanks,
Kent
Section 1:
The last paragraph doesn't flow nicely:
"Although the I2RS architecture is general enough to support
information and data models for a variety of data, the I2RS,
and therefore this document, are specifically focused on an
interface for routing data."
Perhaps rephrase as the following?
"Aspects of the I2RS solution may be useful in domains other
than routing, however this possibility is out of scope for
I2RS and hence not considered in this document."
Section 1.1:
The 4 key drivers are stated to be:
1) a protocol (programmatic, asynchronous, fast, interactive)
2) access to and modification of info previously inaccessible
3) ability to subscribe to structured, filterable events
4) data-model driven for extensibility and use by network apps
The last two seem to be "properties" more so than "drivers" -
would they better belong in Section 3?
Section 1.2
Pg 6. The diagram shows a line between the Agents and Static System
State having the annotation "scoped" - what does this mean?
is it per the definition provided in section 2? If so, why
isn't it also specified on the dynamic state?
Pg 8. Regrading this:
"In order to keep the protocol simple, the current view
is that two clients should not be attempting to write
(modify) the same piece of information. Such collisions
may happen, but are considered error cases that should
be resolved by the network applications and management
systems."
But then there is a reference to section 7.8 that essentially
says that collisions are resolved through a combination of
"priority" and "first-in". Setting aside the first-in issue,
what remains to be resolved by the apps? - just cleaning
up their state? - if so, then maybe update this paragraph to
say that instead? Also, be sure to say that I2RS provides
mechanisms to alert clients when they're preempted. Why is
implied that collisions are rare? - it seems to me that they
could be rather common, but does it matter how often so long
as I2RS requires collision detection and notification? Lastly,
remove the "the current view is" fragment, as an arch doc
needs to be definitive.
And this:
"In contrast, although multiple I2RS clients may need to
supply data into the same list (e.g. a prefix or filter
list), this is not considered an error and must be
correctly handled. The nuances so that writers do not
normally collide should be handled in the information
models."
Do you mean data model? Can you provide an example for how
this can be handled in an info/data model? - are lists
expected to be sorted-by-system to prevent shadowing?
And this:
"The details of the associated policy is discussed in
Section 7.8. The same policy mechanism (simple priority
per I2RS client) applies to interactions between the
I2RS agent and the CLI/SNMP/NETCONF as described in
Section 6.3."
Section 7.8 says it's a combo of "priority" and "first-in"
(not just "priority") - which is it?
And lastly:
"In addition it must be noted that there may be indirect
interactions between write operations. A tivial example
of this is when two different but overlapping prefixes
are written with different forwarding behavior. Detection
and avoidance of such interactions is outside the scope
of the I2RS work and is left to agent design and
implementation."
I don't know, I'm not a routing expert, but it seems to me
that a client having its forwarding behavior preempted is
*worse* than having its whole write operation fail, as an
error-notification is expected. Also, how is this a
"trivial" (misspelled, btw) example, is it because the
collision was on the "action" (not the "match") part of
the rule? - should the text say that more explicitly?
Section 3
Key Arch Properties:
1) Simplicity
2) Extensibility
3) Model-driven programmatic interface
At first this reads like motherhood and apple pie, but then
one wonders if it's the protocol or data-models that are to
be simple and extensible (answer: both) and why other things
aren't listed, like scalability or performance.
Section 4
First paragraph: what are the "pull" and "push" models?
Such things are not defined anywhere in the draft...
Last paragraph: what do you mean "an I2RS Agent may open a
new communication channel"? - is it referring to I2RS's
authentication and authorization channel or something like
Syslog and SNMP traps?
Section 4.2
2nd paragraph: this might be the only place where it's
mentioned that the Agent's permissions to the underlying
system might be restricted (not root). Of course the Agent
needs to enforce client authorization, but that's different.
Should the Agent being limited by the system be mentioned
at all - is it within I2RS scope?
Section 5
2nd paragraph: s/The the broker/The broker/
Last paragraph: s/In the third/In a third/
Section 6.1: "As currently envisioned, a given
I2RS agent would have only one locus per I2RS service for
manipulation of routing element state." - locus?
Section 6.2 last three sentences should be restructured so
that it flows more naturally without the word "reboot"
showing up so many times.
Section 6.2.1:
Regarding this:
"If failure of the I2RS agent causes the ephemeral I2RS
state to be removed, then this should be indicated via
a capability."
This is the first time "capabilities" are mentioned in
this draft, and thus should have a forward reference
to section 7.3.
Also, regarding this:
"First, the I2RS Agent can optionally notify all its
clients that their state is being torn down; if no such
notification is sent, then that ephemeral state is not
torn down. Second, the I2RS Agent must notify all its
cached clients that the agent is going down."
I'm confused, the notification is optional, but if not sent
the ephemeral state can't be torn down, yet the agent is
going down. How can ephemeral any state persist if agent
goes down? Perhaps the solution only needs to send the
second notification, since it implies the first?
Section 6.2.3:
The first two sentences should be put together, as two ways
state may be removed. Right now, as two separate sentences, it
doesn't read that way...
Regarding the rest of the paragraph and considering the sequence:
T1: ephemeral state set by client-1 with "low" priority
- e.g., overwrites default CLI/SNMP/NETCONF state
T2: ephemeral state set by client-2 with "high" priority
- e.g., overwrites client-1's state
T3: client-2 goes away and it's state removed
Do you mean that client-1's state isn't reinstated? That the
I2RS Agent at time T2 threw-out client-1's state ?
Section 6.3, 2nd paragraph:
Replace:
"the I2RS agent must notify the affected I2RS agents"
^^^^^^
With:
"the I2RS agent must notify the affected I2RS clients"
^^^^^^^
Section 6.4.2: s/MUST NOT allowed/MUST NOT be allowed/
^^
Section 6.4.5:
The numbering must be wrong on the sub-sections. Is it suppose
to be this?
6.4.5.1.1 --> 6.4.5.2
6.4.5.1.2 --> 6.4.5.3
Also, maybe s/Optionality/Optional Features/ for the section
title?
Section 6.4.5.1: s/parent?/parent/
- at least I think it's a statement more than a question
Section 6.4.5.1.1 (Optionality):
I can understand how default values and conditionals can be used
to indicate a node is optional. I don't understand why the first
paragraph has so many question-marks in it. I was expecting a
statement stating that the I2RS data-model language needed to
support flagging defaults and optional-features and that there
must exist a mechanism a client can use to determine which of
the optional features a particular I2RS Agent supports
(e.g., capabilities)
In the second paragraph, "optionality" is extended to include
field-level validations (e.g. string-length, regex-match?).
Field-level validations are great, but I don't believe that
they're a form or "Optionality" or a means for "managing
variation", so I suggest removing them. Additionally, I don't
understand what "the existence of particular events, and other
aspects of information" means within the context of Optionality
and Managing Variation.
Section 6.4.5.1.2 (Templating)
s/scheme may that some of/scheme may enable some of/ ???
^^^^ ^^^^^^
Section 6.4.5.1.3. Object Relationships
Is this section now suppose to be 6.4.6?
Section 6.4.5.1.3.1. (Initialization)
s/one object instances is/one object instance is/
^
FWIW, YANG doesn't currently have a way to indicate that one
object should pull values from another. The text does say
"it is often not formally represented in modeling", so I
guess this is fine, but still noteworthy.
Section 6.4.5.1.3.2. Correlation Identification
YANG does have the "instance-idenitier" type and the
"require-instance" MAY be applied to it to toggle if the
referenced instance must exist. But I'm unsure if it is
sufficient for what's being described here.
Section 7.8
The 2nd paragraph says "This architecture does not attempt to
determine what the right state of data should be when such a
collision happens.". But then it goes on to define a priority
based mechanism. The quoted sentence seems either misleading
or wrong.
The 2nd paragraph also says "In the case of priority ties, the
first client whose attribution is associated with the data will
keep control." Does this conflict with the sentiment made in
section 6.3 that time-based policies could cause race conditions
where the final state is not repeatably deterministic?
Thanks again,
Kent
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
