Early Review of draft-ietf-i2rs-architecture-07
review-ietf-i2rs-architecture-07-opsdir-early-baker-2016-03-23-00

Thanks Fred,

great review. I think the subject escaped, adjusted so we can find it.

joel

On 3/15/16 2:41 PM, Fred Baker (fred) wrote:
> I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments. > > I think the
draft is ready with nits and some changes. I don't believe that any of these
issues are showstoppers, but I do believe they require addressing. > > > The
first nit is a statement in section 1.1: > >    Such an interface also
facilitates the injection of ephemeral state >    into the routing system. 
Ephemeral state on a router is the state >    which does not survive a the
reboot of a routing device or the reboot >    of the software handling the I2RS
software on a routing device. > > Ephemeral state is state that is "ephemeral",
which my dictionary tells me means that it is "short-lived, transitory, lasting
a short time". This comes to mind because of a paper I discovered I was a
co-author on (story in the presence of adult beverages) last year, which
suggested that congested links in a network could be offloaded by directing a
subset of the routes, or a subset of the traffic using those routes, using them
to other links that a routing protocol might contend were below par but which
provided a non-looping path and had available capacity. The issue was that when
routing changed for any reason, these SDN changes had to be undone and redone,
a process that could take (in the network of interest) on the order of 40
minutes. My suggestion to my "co-authors" was that they simply change the FIB
(which is by definition ephemeral), so that should routing change the FIB would
became predictably correct (e.g., with no such optimizations added to it) after
having re-converged, and they could now re-optimize the FIB as they saw fit
without incurring a potential outage. > > I would suggest that the above
reference to a reboot be changed to "Ephemeral state on a router is state that
changes from time to time". A reboot is only one of those times. > > > At the
top of page 6, the first paragraph reads: > >    The I2RS agent provides read
and write access to selected data on the >    routing element that are
organized into I2RS Services. Section 4 >    describes how access is mediated
by authentication and access control >    mechanisms.  Figure 1 shows I2RS
agents being able to write ephemeral >    static state (e.g.  RIB entries), and
to read from dynamic static >    (e.g.  MPLS LSP-ID or number of active BGP
peers).  In addition, the > > I have a hunch the authors intended to complete
the final sentence. > > > In section 3.1, which comments on "simplicity", I am
very much in favor of simplicity in the sense described by RFC 3439. That said,
I think the paper misses the mark by a few millimeters. It says > >    Thus,
one of the key aims for I2RS is the keep the protocol and >    modeling
architecture simple.  So for each architectural component or >    aspect, we
ask ourselves "do we need this complexity, or is the >    behavior merely nice
to have?" > > Often, simplicity is not about whether a feature is itself
complex, but about whether what is externalized is complex. Theorists dealing
with complexity use a swimming duck as an example: viewed from above the water
line, the duck is a picture of placidity in motion, while when viewed from
below its paddle feet are madly beating the water. A communication example is
in TCP; heaven only knows what is really happening in the network, but TCP
narrows the entire discussion into two signal classes - in this RTT, it has
received a congestion signal, or it has not, and it has either received
acknowledgements indicating forward progress in the session, or it has not.
From the application's perspective, there is sufficient forward progress to
merit continuing the session at whatever rate it is able to proceed, or
progress is inadequate. Within TCP, there is actually a fair bit of complexity.
However, what it externalizes to a client application is dead simple. > > So I
would go beyond "do I need this complexity" to "do I need for this complexity
to be externalized, do I need it at all, and if I need it, is there a way to
meet the need with a simpler external API?" > > > In section 4 and 4.2, I'm
concerned about the issues of authorization "for classes of statements", which
are mentioned obliquely but not really gone into. My personal bugaboo in this
context is the router I use at my home, which is functionally equivalent to two
separate routers coexisting in a single chassis. One router connects my home
office to my employer using a VPN, and the other is a very typical residential
CPE. We have similar issues whenever a router has multiple routing tables or
contains multiple virtual routers. When I read > >    An I2RS Client is not
automatically trustworthy.  Each I2RS Client is >    associated with identity
with a set of scope limitations. > > I read "scope limitations" as a reference
to "authorization", but I think this concept needs to be fleshed out more. An
I2RS client (or the server it serves), perhaps on an interface, has a set of
information, which may be complete, null, or anywhere in between, for which it
is trustworthy, and it is not trustworthy for anything else. In a network like
my home, I could imagine a route controller operated by my employer's IT
organization and another operated by me or by my ISP on my behalf. If a single
system contains multiple clients or serves multiple servers, that difference of
authorization can be important. We understand that in some detail in BGP; it
needs to be handled in I2RS as well. > > > > > >
_______________________________________________ > OPS-DIR mailing list >
OPS-DIR at ietf.org >

https://www.ietf.org/mailman/listinfo/ops-dir

>

Attachment:

signature.asc

Description:

 OpenPGP digital signature