Subject: [i2rs] I-D Action: draft-ietf-i2rs-architecture-01.txt

From: [email-masked]
Date: Mon, 10 Feb 2014 12:19:14 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Interface to the Routing System Working Group of the IETF.

        Title           : An Architecture for the Interface to the Routing System
        Authors         : Alia Atlas
                          Joel Halpern
                          Susan Hares
                          Dave Ward
                          Thomas D. Nadeau
	Filename        : draft-ietf-i2rs-architecture-01.txt
	Pages           : 29
	Date            : 2014-02-10

Abstract:
   This document describes an architecture for a standard, programmatic
   interface for state transfer in and out of the Internet's routing
   system.  It describes the basic architecture, the components, and
   their interfaces with particular focus on those to be standardized as
   part of I2RS.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-i2rs-architecture-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-architecture-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 13 Feb 2014 00:39:58 -0500

On 2/10/14, 3:19 PM, [email-masked] wrote:

In going through the -01/-02 draft, I have a few comments.

In section 1.1, the first paragraph states:

...Second is the access to structured information and state that is 
frequently not directly configurable...

Then in paragraph four:

...I2RS will only permit modification of state that would be safe, 
conceptually, to modify via local configuration...

While you do use the word "conceptually," it's hard to conceive of 
something that is at the same time safe to modify via the configuration 
but is not exposed via the configuration.  That is, how would one know 
what is safe?  This might benefit from an early example to clarify what 
is meant and perhaps it is good enough to drop the bit about modifiable 
via local configuration and just say that modification of protocol 
internal state is out of scope.

===

In section 1.2, the new text helps to show how App, Client, and Agent 
fit together, but I wonder if this same new text wouldn't benefit from a 
statement that App to Client communication is out of scope.  That is, 
you state that the Client and Agent communicate via an asynchronous 
protocol, but nothing is said about, for example, how apps C, D, E 
communicate with Client P.  You do mention this further down in the doc, 
so it's a minor thing, but perhaps worth a sentence here.

===

Section 2, in the I2RS Client paragraph, I can't get my head around this 
text:

Based on the information and the policy oriented interactions, the	I2RS 
client may also interact with I2RS agents to modify the state	
of the routing system the client interacts with to achieve	
operational goals.

The first part makes sense, but then it starts to sound muddled, at 
least to me.  Maybe you want to say:

Based on the information and the policy oriented interactions, the	I2RS 
client may also interact with I2RS agents to modify the state	
of the routing system in order to achieve operational goals.

===

Section 4.  While streaming OSPF prefix announcements MAY NOT require 
confidentiality, some users may want it.  Paragraph 4 starts out, Other 
communications via I2RS will not...  I think this should say may not 
just to make it clear that this can be optional based on specific 
environmental requirements.

===

Section 6.2.1.  Minor nit:

OLD text:

...that an I2RS Agent has unexpected failed...

NEW text:

...that an I2RS Agent has unexpectedly failed...

===

Section 6.2.1.  I don't know if this needs to be said in the document or 
left to an implementor, but if the I2RS Agent can ensure state is 
preserved until the routing element reboots, then a cache of state may 
need to be kept by the Agent.  If it dies and restarts, then it can read 
that cache and restore state.  I bring this up because if you think of 
something like OSPF as an I2RS Agent, if the OSPF process dies, you 
wouldn't expect its routes to stick around.  However, when it restarts, 
it could restore the last known set of routes back into the routing 
element.

In this manner it might be safer if the Agent dies and cannot restart 
for whatever reason.  That would prevent a potentially bad route from 
getting stuck in the routing element until a reboot.

Just a thought.  I think the new text is good in that you account for 
the case where an Agent failure will cause ephemeral state to disappear, 
but the "should" case is for this state to remain.  Clarifying how that 
could work might be a nice thing.

===

Section 6.4.5.1.3.1 (ASN.1 anyone?).  Minor nit:

OLD text:

...The simplest relationship is that one object instances is initialized...

NEW text:

...The simplest relationship is that one object instance is initialized...

===

Section 7.1.  This is mainly an editorial, but in looking back at things 
like NETCONF over BEEP, one goal might be to make sure the transport 
chosen is both operator and implementor friendly in terms of ease of 
adoption.

===

Section 7.5.  Would a supervisory application work in this case?  I 
suppose it could if it shared the same ID, but that wouldn't work for 
multiple applications.  Likely a better approach would be to allow the 
Client to accept some meta-instructions at the beginning of a session as 
to what to do if the app goes away (as you state in paragraph 4).

Joe

> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Russell Harrison <[email-masked]>
Date: Thu, 13 Feb 2014 00:31:37 -0600

Joe - few comments in response...

While you do use the word "conceptually," it's hard to conceive of
something that is at the same time safe to modify via the configuration but
is not exposed via the configuration.  That is, how would one know what is
safe?  This might benefit from an early example to clarify what is meant
and perhaps it is good enough to drop the bit about modifiable via local
configuration and just say that modification of protocol internal state is
out of scope.

:: It seems pretty clear that this calls for intermediating routing data
(for instance, through an RR) to ensure that certain adjustments can be met
without manipulating protocol internal state directly. That definition may
remain insufficient, however, as there are certain cases where operations
which do modify protocol internal state could be demonstrably safe...

===

Section 4.  While streaming OSPF prefix announcements MAY NOT require
confidentiality, some users may want it.  Paragraph 4 starts out, Other
communications via I2RS will not...  I think this should say may not just
to make it clear that this can be optional based on specific environmental
requirements.

===

:: "Streaming OSPF prefix announcements" is a ... interesting way to look
at this. If we were only referring to externals and summaries... maybe. But
add the intra-area and TE LSAs into the mix; this is something that few if
any operators would want to share publicly. If we didn't try to carry data
other than link state changes in OSPF the LSDB really ought to be pretty
static over time...

It seems to me that integrity of the view of the topology is very
important, and notification of link-state changes from a known starting
point may be an efficient way to doing that.

Anyway ... back to work for me. Thanks y'all.

-RH

On Wed, Feb 12, 2014 at 11:39 PM, Joe Marcus Clarke <[email-masked]>wrote:

> something that is at the same time safe to modify via the configuration but
> is not exposed via the configuration.  That is, how would one know what is
> safe?  This might benefit from an early example to clarify what is meant
> and perhaps it is good enough to drop the bit about modifiable via local
> configuration and just say that modification of protocol internal state is
> out of scope.
>
> ===
>
> In section 1.2, the new text helps to show how App, Client, and Agent fit
> together, but I wonder if this same new text wouldn't benefit from a
> statement that App to Client communication is out of scope.  That is, you
> state that the Client and Agent communicate via an asynchronous protocol,
> but nothing is said about, for example, how apps C, D, E communicate with
> Client P.  You do mention this further down in the doc, so it's a minor
> thing, but perhaps worth a sentence here.
>
> ===
>
> Based on the information and the policy oriented interactions, the
>  I2RS client may also interact with I2RS agents to modify the state
> The first part makes sense, but then it starts to sound muddled, at least
> to me.  Maybe you want to say:
>
> Based on the information and the policy oriented interactions, the
>  I2RS client may also interact with I2RS agents to modify the state
> communications via I2RS will not...  I think this should say may not just
> to make it clear that this can be optional based on specific environmental
> requirements.
>
> ===
>
> left to an implementor, but if the I2RS Agent can ensure state is preserved
> until the routing element reboots, then a cache of state may need to be
> kept by the Agent.  If it dies and restarts, then it can read that cache
> and restore state.  I bring this up because if you think of something like
> OSPF as an I2RS Agent, if the OSPF process dies, you wouldn't expect its
> routes to stick around.  However, when it restarts, it could restore the
> last known set of routes back into the routing element.
>
> In this manner it might be safer if the Agent dies and cannot restart for
> whatever reason.  That would prevent a potentially bad route from getting
> stuck in the routing element until a reboot.
>
> Just a thought.  I think the new text is good in that you account for the
> case where an Agent failure will cause ephemeral state to disappear, but
> the "should" case is for this state to remain.  Clarifying how that could
> work might be a nice thing.
>
> ===
>
> like NETCONF over BEEP, one goal might be to make sure the transport chosen
> is both operator and implementor friendly in terms of ease of adoption.
>
> ===
>
> Client to accept some meta-instructions at the beginning of a session as to
> what to do if the app goes away (as you state in paragraph 4).
>
> Joe
>
>
>