Subject: [i2rs] comments on draft-ietf-i2rs-architecture-02

From: Kent Watsen <[email-masked]>
Date: Wed, 19 Mar 2014 23:53:22 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 19 Mar 2014 20:11:04 -0400

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:
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: t.petch <[email-masked]>
Date: Fri, 28 Mar 2014 10:48:13 +0000

I see the term 'Operational State' in use in I2RS, but from the context,
get the impression that this is not being used in the same way as in the
Ops Area.

It could be that the I2RS uses the same term to mean something
different, or a different term to mean the same, or some combination
thereof, but I think that that should be done knowingly so that the IETF
at large can know whether the term is being used in its Ops Area sense
or not.

The term has been around since at least RFC3535 (2002) when the
operators told the IAB why SNMP was no use to them.  The sort of feature
that was missing was the ability to read the config from a box, replace
the box, write the config back to a replacement box and carry on as if
nothing had changed (give or take a few flaps and Graceless Restarts).
Crucially, config here is the changes made from
the default state by CLI (or some such).  The rest of the data in a box
is then divided into read-only statistics (the only kind thereof) and -
Operational State, which is everything else that the box has acquired,
be it from BGP or OSPF, from DHCP or NTP or parameters set up by the box
itself in response to detecting the insertion of a new blade.

Thus entries in a routing table learnt from BGP are Operational State; a
static entry put in by CLI (or some such) is config.  The parameters for
a hot-plugged interface card are Operational State; turning on passive
ospf on that interface is config.

This tri-partite split has been the norm for Ops Area for many years
now.
It may or may not be appropriate for I2RS but I do think that I2RS
should
at least take cognizance of this in deciding what terms to use

 Tom Petch