Subject: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Wed, 16 Mar 2016 18:36:24 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-i2rs-architecture-13: No Objection

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:
----------------------------------------------------------------------

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: Wed, 16 Mar 2016 22:33:48 -0400

Benoit: 

Great comments - see below.  Thanks for finding additional typos/unclear
text.   You some good questions - I hope my answers were as good.

Cheerily, 
Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Wednesday, March 16, 2016 9:36 PM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: [i2rs] Benoit Claise's No Objection on
draft-ietf-i2rs-architecture-13: (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.)

>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.

Sue: You are so right.  The ietf-netmod-opstate-reqs-04 was not approved
when I started the process - but I will do this in -14.txt 

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

Sue:  On Yang --> YANG (Ack - will fix in -14.txt).   Will change error on
RFC6020 to 1.0.  Due to all the features we need for pub/sub  - I2RS will be
Yang 1.1.  

> Are the two sentences redundant?

Sue:  Sigh.  Other reviewers felt that we needed the second sentence to 
Indicate that is was 1-n I2RS Agents.  

> Really confused.

Sue: I see your point on the editorial issue, and I will try to fix it.
(see -14.txt) 

>editorial "may be reused".  / I will check with RFC editor (some people say
reused /re-used). 

>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)

Sue: NETCONF and RESTCONF will be supported as part of the I2RS protocols.
The architecture does out rule out other data transfer protocols, but says
the WG will design I2RS as a higher level protocol that combines other
protocols (NETCONF/RESTCONF + x).  The I2RS requirements documents and
protocol strawman will state is if any other protocols will be used for a
particular version of I2RS with a particular scope for data modules. 

I am sorry if this is not what you excepted, but it was my direction from my
AD on how to approach this work. 

At this time, we are closing in on the last of the requirements documents -
the requirements for other data flows. 
draft-hares-i2rs-dataflow-req-02 that gives the potential scope of data
flows, but IMO the first version of the I2RS is likely to stay with just
NETCONF/RESTCONF with ephemeral state, push pub/sub support, syslog module
library, and some yang changes. 

>    To handle I2RS Agent failure, the I2RS Agent must  use two different
notifications.
>      NOTIFICATION_I2RS_AGENT_STARTING:   This notification signals to the
>          notification will be only transmitted to I2RS clients which are

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

Sue: Reasonable editorial comment.  This was added to address another
comment, 
But it looks like we broken something.  Text change below. 
 
 Old/  Optionally, a routing element may permit a priority to be to be
   configured on the device for the Local Configuration mechanism
   interaction with the I2RS model.  The policy mechanism would compare
   the I2RS client's priority with that priority assigned to the Local
   Configuration in order to determine whether Local Configuration or
   I2RS wins.

   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.  The local configuration
   information is stored so that if/when I2RS client removes I2RS
   ephemeral state the local configuration state can be restored.
/ 
New: 
Optionally, a routing element may permit a priority to be to be
   configured on the device for the Local Configuration mechanism
   interaction with the I2RS model.  The policy mechanism would compare
   the I2RS client's priority with that priority assigned to the Local
   Configuration in order to determine whether Local Configuration or
   I2RS wins.

   For the case when the configured priority of the I2RS ephemeral
   Is higher than the Local Configuration's policy, the  
   The I2RS ephemeral state value it is installed
   instead of the local configuration state.  The local configuration
   information is stored so that if/when I2RS client removes I2RS
   ephemeral state the local configuration state can be restored.
/ 

> figure 2. "The initial services included in the I2RS architecture are as
follows."
> Maybe I should review the I2RS charter? 

Sue:  Our charter is wide, but only ephemeral layer deep.  Due to the
excellent people in the NETCONF/NETMOD, routing area (rtgwg) and TEAS - we
are focusing on allowing ephemeral to be added to any data model.  I2RS WG
is focused first on the I2RS protocol and protocol independent modules.
After this, I2RS purpose is to simply support other WGs in creating data
modules with ephemeral state. 
    
>   The I2RS  protocol may need to use several underlying transports (TCP,
SCTP
>  Do you really want to have define transports?

Sue: We indicate that I2RS will use these protocols.  Each protocol we
mention has to be then validated with requirements (see protocol security
requirement and security environment requirements). 

>And below is Fred Baker's OPS DIR review:

Sue:  Responded to Fred on another channel - before I got your message. I
will not repeat it here. 

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

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.

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.

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.

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

---

From: Benoit Claise <[email-masked]>
Date: Thu, 24 Mar 2016 07:53:46 -0300

Sue,

> protocols (NETCONF/RESTCONF + x).
This is what I could not understand with the draft sentence: "Two of the 
existing protocols which the which may _be re-used_ are NETCONF 
[RFC6241] and RESTCONF > [I-D.ietf-netconf-restconf]."
Sure many things could be reused. I'm expecting from an architecture 
document to explain which pieces are used and how they are used.
> The I2RS requirements documents and
Probably, my issue stems from the fact that I2RS produces an 
architecture before fixing requirements.
>>           know in some way after a reboot.)
No comment on "the I2RS Agent _must _use two different notifications"?
This one is clear spec.
> Optionally, a routing element may permit a priority to be to be
to be to be
>     The I2RS ephemeral state value it is installed
remove "it"
> requirement and security environment requirements).
So I2RS will publish a second architecture doc when the requirements are 
validated and the protocols (transport, config, notifications) are 
finally selected?

Regards, Benoit

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 24 Mar 2016 08:16:51 -0400

Benoit, you seem to be looking for a level of specificity in the 
architecture that the working group never intended.  The charter calls 
for a high level architecture.

I believe your comment calls out an interesting gap in the charter, as 
there is no document called out which actually says "we are using pieces 
X, Y, and Z, in ways A, B, and C, to solve the I2RS problem."

We could have tried to use the architecture document for that, but the 
intention was to use the architecture document to guide the selection of 
protocol and mechanisms.

Yours,
Joel

---

From: Benoit Claise <[email-masked]>
Date: Thu, 24 Mar 2016 10:03:20 -0300

Joel,

Thanks, that's helpful.

1. Let's look at the charter

    The I2RS working group works to develop a high-level architecture that
    describes the basic building-blocks necessary to enable the specific
    use
    cases, and that will lead to an understanding of the abstract
    informational models and requirements for encodings and protocols
    for the I2RS interfaces.

2. Let's review the draft abstract

        This document describes the IETF architecture for a standard,
        programmatic interface for state transfer in and out of the Internet
        routing system.  It describes the basic architecture, the components,
        and their interfaces with particular focus on those to be
        standardized as part of the Interface to Routing System (I2RS).

Reading 1., I understand your point of view.
However, I read 2. as this draft is about "we are using pieces X, Y, and 
Z, in ways A, B, and C, to solve the I2RS problem."
I reviewed the draft content looking for 1., and could not find it.

Do you understand my confusion?

Regards, Benoit
> architecture that the working group never intended. 
> The charter calls for a high level architecture.
>
> there is no document called out which actually says "we are using 
> pieces X, Y, and Z, in ways A, B, and C, to solve the I2RS problem."
>
> intention was to use the architecture document to guide the selection 
> of protocol and mechanisms.
>
> Yours,
> Joel
>
> .

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 24 Mar 2016 09:07:04 -0400

Now I understand your confusion.
Putting aside the abstract, I thought we were focused om task 1 (from 
the charter) in writing.  I think we probably crept into task 2, 
resulting in a document which is confusing about its scope.

Not sure how to resolve this.
Yours,
Joel

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 24 Mar 2016 20:18:29 -0400

On Thu, Mar 24, 2016 at 09:07:04AM -0400, Joel M. Halpern wrote:
> Putting aside the abstract, I thought we were focused om task 1
> (from the charter) in writing.  I think we probably crept into task
> 2, resulting in a document which is confusing about its scope.

In general, we should avoid trying to say "we're re-using <foo>" too much in
the architecture draft.  As we've seen from the long (very long) discussions
on potential protocol tweaks to enable I2RS applications on existing IETF
protocols, we know this is tricky to bring to some sort of consensus.

Benoit, I think the other half of this challenge is in many cases we mention
other IETF technologies because they provide example components of things we
might be able to use.  By their example, we get a huge amount of semantic
help with what is covered, with the downfall of some amount of "you probably
don't want this component".  I think the advantages of drawing analogies to
existing techs outweighs the issues of saying "we *are* (re-)using this
technology".

Given the above, are there specific changes you'd recommend that allow us to
continue to get semantic leverage out of any references we have to existing
techs?

-- Jeff