Subject: [i2rs] Benoit Claise's Abstain on draft-ietf-i2rs-architecture-14: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Fri, 22 Apr 2016 03:38:02 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-i2rs-architecture-14: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The discrepancy between the architecture document description in the
charter and the draft previous abstract is now fixed. This is an
improvement. However, I don't see how this document is actually useful.
It's a mix of: "we could use X, Y, Z", but at the same time "we MUST
support very detailed notifications" and we must integrate the outcome of
the various requirement documents.

I don't see how the document could be salvaged. Anyway, I will not stand
in the way of this publication, and will abstain.
It's probably my fault: I should have paid more attention at the charter
discussion time.

===========================================================================

A couple of points, not all of them are minor (I've been wondering:
COMMENT or DISCUSS. Let's go for a COMMENT)

- "Second is the access to structured information and state that is
frequently not directly configurable".
I have a hard time reconciling the NETMOD state definition, for example
from https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04
It would be good if the terminology were aligned.

- 
   This I2RS architecture assumes a data-model driven protocol where the
   data-models are defined in Yang 1.1 ([RFC6020]), Yang 1.1
   ([I-D.ietf-netmod-rfc6020bis]), and associated Yang based model
   drafts ([RFC6991], [RFC7223], [RFC7224], [RFC7277], [RFC7317]). "

RFC 6020 is YANG 1.0, not YANG 1.1
I2RS is YANG 1.0 or YANG 1.1? I hope YANG 1.1
btw, this "YANG" not "Yang"

- Are the two sentences redundant?
   As can be seen in Figure 1, an I2RS client can communicate with
   multiple I2RS agents.  An I2RS client may connect to one or more I2RS
   agents based upon its needs.

-  
   There are several key benefits for I2RS in using model-driven
   architecture and protocol(s).  First, it allows for transferring
   data-models whose content is not explicitly implemented or understood.

Reading that second sentence multiple times, I still fail to understand.
Model-driven on one side, but you want data-models whose content is not
explicitly implemented or understood.
Really confused.

-
   Two of the existing protocols which the
   which may be re-used are NETCONF [RFC6241] and RESTCONF
   [I-D.ietf-netconf-restconf].

"may be reused". What does it mean? I was hoping that an architecture
documents would at least tell me which protocols are used.
On my side this architecture is flexible (NETCONF or RESTCONF), on the
other side unclear (YANG 1.0 or YANG1.1), and in some cases, a complete
specification (for example the notification)

    To handle I2RS Agent failure, the I2RS Agent must
       use two different notifications.

       NOTIFICATION_I2RS_AGENT_STARTING:   This notification signals to
the
          I2RS Client(s) that the associated I2RS Agent has started.  It
          includes an agent-boot-count that indicates how many times the
          I2RS Agent has restarted since the associated routing element
          restarted.  The agent-boot-count allows an I2RS Client to
          determine if the I2RS Agent has restarted.  (Note: This
          notification will be only transmitted to I2RS clients which
are
          know in some way after a reboot.)

- editorial:
   Optionally, a routing element may permit a priority to be to be

-
   For the case when the I2RS ephemeral state always wins for a data
   model, if there is an I2RS ephemeral state value it is installed
   instead of the local configuration state. 

Again, I read that sentence multiple times, and could not understand it

- figure 2. "The initial services included in the I2RS architecture are
as follows."
Are these really the initial services for I2RS. I2RS is really dealing
with all these: interfaces, policy, QoS, ...
Maybe I should review the I2RS charter? 

-     
   The I2RS
   protocol may need to use several underlying transports (TCP, SCTP
   (stream control transport protocol), DCCP (Datagram Congestion
   Control Protocol)), with suitable authentication and integrity
   protection mechanisms

Do you really want to have define transports?

And below is Fred Baker's OPS DIR review:

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.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 22 Apr 2016 10:10:43 -0400

Benoit: 

I'm sorry the document does not met your expectations.  I have attempted to fix the text to the rest of your comments in draft-ietf-i2rs-architecture-14.txt.  

The only issue I believe that is major is the alignment with the netmod-opstate-reqs-04 terms. Every time I have used the terms in netmod-opstate-reqws-04.txt in an I2RS presentation there has been a debate on the terms.  This debate occurs whether I quote RFC6244 or the netmod-opstate-reqs-04.terms.  I will be glad to change any specific text to align to this draft, but I would ask for specific textual changes. 

Sue 

-----Original Message-----
From: Benoit Claise [mailto:[email-masked]] 
Sent: Friday, April 22, 2016 6:38 AM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Benoit Claise's Abstain on draft-ietf-i2rs-architecture-14: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

The discrepancy between the architecture document description in the charter and the draft previous abstract is now fixed. This is an improvement. However, I don't see how this document is actually useful.
It's a mix of: "we could use X, Y, Z", but at the same time "we MUST support very detailed notifications" and we must integrate the outcome of the various requirement documents.

I don't see how the document could be salvaged. Anyway, I will not stand in the way of this publication, and will abstain.
It's probably my fault: I should have paid more attention at the charter discussion time.

- "Second is the access to structured information and state that is frequently not directly configurable".
I have a hard time reconciling the NETMOD state definition, for example from https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04
It would be good if the terminology were aligned.

- 

RFC 6020 is YANG 1.0, not YANG 1.1
I2RS is YANG 1.0 or YANG 1.1? I hope YANG 1.1 btw, this "YANG" not "Yang"

-  

Reading that second sentence multiple times, I still fail to understand.
Model-driven on one side, but you want data-models whose content is not explicitly implemented or understood.
Really confused.

-

"may be reused". What does it mean? I was hoping that an architecture documents would at least tell me which protocols are used.
On my side this architecture is flexible (NETCONF or RESTCONF), on the other side unclear (YANG 1.0 or YANG1.1), and in some cases, a complete specification (for example the notification)

          notification will be only transmitted to I2RS clients which are

- editorial:

-

- figure 2. "The initial services included in the I2RS architecture are as follows."
Are these really the initial services for I2RS. I2RS is really dealing with all these: interfaces, policy, QoS, ...
Maybe I should review the I2RS charter? 

-     
   The I2RS

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.

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

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

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.