An Architecture for the Interface to the Routing System
RFC 7921

Note: This ballot was opened for revision 13 and is now closed.

Deborah Brungard Yes

(Jari Arkko) No Objection

Comment (2016-03-17 for -13)
No email
send info
Russ Housley's Gen-ART review raised the following question and editorial comments. I believe it would be useful for the authors to think about the question at least, but I have not seen a response yet:

---

Minor Concerns:

Section 4.2 talks about authorization.  I would expect policy to
dictate that some writes come from a specific source, but it is
unclear to me whether I2RS can require that a particular write
request arrive on a particular channel.  Is this desirable?  If so,
please expand the discussion of authorization to cover this point.


Nits:

Sometimes you say "i2rs architecture", but it should say "I2RS
architecture" to be consistent throughout the document.

Sometimes you say "I2RS Agent" and other times you say "I2RS agent".
Please pick one and use it consistently.

Sometimes you say "I2RS Client" and other times you say "I2RS client".
Please pick one and use it consistently.

Section 3: s/ may may vary based / may vary based /

Section 6.3: s/ the yang data model / the YANG data model /

Section 6.4.2: some bullets have periods, but others do not.

Section 7.1: s/ Yang / YANG / (more than one place)

(Ben Campbell) No Objection

(Spencer Dawkins) No Objection

Comment (2016-03-16 for -13)
No email
send info
In this text:

7.1.  One Control and Data Exchange Protocol

   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.  These different transports can support
   different types of communication (e.g. control, reading,
   notifications, and information collection) and different sets of
   data.  Whatever transport is used for the data exchange, it must also
   support suitable congestion control mechanisms.  The transports
   chosen should be operator and implementor friendly to ease adoption.
   
I echo Benoit's question about defining multiple underlying transports. I suspect you'll need to pick one mandatory-to-implement transport protocol, and when everyone has to support that one, I'd be surprised to see implementations that support more than one transport protocol unless the mandatory-to-implement transport protocol is seriously broken in some scenarios.

(Stephen Farrell) No Objection

Comment (2016-03-17 for -13)
No email
send info
- If i2rs were used to control home networks, then that would
raise more privacy issues, e.g. the agent's IP address can be
privacy sensitive. Would it be useful to rule that out of
scope? E.g. to say that i2rs SHOULD NOT be used where the
agent/router in question is specific to one person or home?

- section 2: security role, hmm..... Do netconf/restconf have
the concept of mapping identifiers to roles? If not, that
might be tricky to graft on. Not sure.

- section 4: "Mutual authentication between the I2RS Client
and I2RS Agent is required. " yay! thanks:-) Even better if
you did s/Mutual/Strong mutual/ to prevent someone saying that
TCP-MD5 is good enough.

- section 4: "The primary communication channel that is used
for client authentication and then used by the client to write
data requires integrity, confidentiality and replay
protection." yay! again! :-)

- section 4: "Other communications via I2RS may not require
integrity, confidentiality, and replay protection.  For
instance, if an I2RS Client subscribes to an information
stream of prefix announcements from OSPF, those may require
integrity but probably not confidentiality or replay
protection." sorry, boo! :-) 

It's often unsafe to mix and match differently protected sets
of data between the same sets of entities. I think you'd be
better off there saying that the requirements may
*exceptionnally* differ but usually only because of e.g. some
level of broadcast or multicast being part of the story, where
we don't have good usable security solutions today. (This is
not a DISCUSS because I think the protocol work will end up
saying "just use TLS always" as that'll be simpler and better,
so I hope this'll be a non-issue. If you know already that
there's some other plan in place, then please say so we can
chat now and avoid a trickier discussion later.) 

- section 4: I think you're heading here towards use of TLS
and not object level security. Is that right? If so, would it
be useful to say so? (Just so as to correctly set expectations
for later.)

- 7.7: Would it be useful to say that the relevant information
here is only about network state and stastics and not about
connections (e.g. who spoke to whom) or payloads?  That might
save some discussions about RFC2804 later on.

(Joel Jaeggli) No Objection

Comment (2016-03-17 for -13)
No email
send info
fred and benoit did quite a good job on this one.

Barry Leiba No Objection

Comment (2016-03-16 for -13)
No email
send info
I'm happy to leave this to the INT and RTG ADs.  I have no objection after a quick run-through.

(Terry Manderson) No Objection

Comment (2016-03-15 for -13)
No email
send info
Hi there,

Firstly, I support Alvaro's two significant comments, especially with regards to the outcomes of the I2RS initiated change. My reading of the draft is that the resulting architecture espouses to judge intent, or the very least the outcome of the intent, as safe. How? Apologies if I read more into this than intended, please help clarify.

I only saw one nit that hadn't been noticed in other comments.
Section 3: para, last sentence. "may may"

Thanks

Alvaro Retana No Objection

Comment (2016-03-15 for -13)
No email
send info
I have some comments; I would consider the first two as significant/major, while the others are minor comments and nits that came up as I was reading (not always linearly).

A. There are a couple of places where operations are characterized as "safe" (1.1 and 6.4.1 — see below), but no explanation as to what "safe" means.  It seems to me that these mentions of "safe" go beyond authentication and even authorization to perform a specific operation, to the content of the operation itself.  I would like to see some discussion about how to achieve it, and/or (at least) what the impact may be.

- 1.1: "I2RS will only permit modification of state that would be safe, conceptually, to modify via local configuration; no direct manipulation of protocol-internal dynamically determined data is envisioned."

- 6.4.1: "Routing elements may maintain one or more Information Bases. Examples include Routing Information Bases such as IPv4/IPv6 Unicast or IPv4/IPv6 Multicast.  Another such example includes the MPLS Label Information Bases, per-platform or per-interface or per-context.  This functionality, exposed via an I2RS Service, must interact smoothly with the same mechanisms that the routing element already uses to handle RIB input from multiple sources, so as to safely change the system state.  Conceptually, this can be handled by having the I2RS Agent communicate with a RIB Manager as a separate routing source."

B. Section 3. (Key Architectural Properties) says that "some architecture properties such as performance and scaling are not described below because they are discussed in [I-D.ietf-i2rs-problem-statement]".  However, as I mentioned in my review of I-D.ietf-i2rs-problem-statement [1], that document has a very, very sparse treatment of performance and scalability to even attempt to call it a "Key Architectural Property".

C. Section 1.1. (Drivers for the I2RS Architecture) says: "I2RS is described as an asynchronous programmatic interface, the key properties of which are described in Section 5 of [I-D.ietf-i2rs-problem-statement]."  Why isn't I-D.ietf-i2rs-problem-statement a Normative Reference?   It is considered to define the properties of the I2RS which are used in building the architecture.

D. Section 4 (Security Considerations) mentions the "I2RS security requirements", but there is no reference to draft-ietf-i2rs-protocol-security-requirements.

E. s/I2RSS/I2RS

F. There's a orphan "In addition, the" in 1.2.

G. Systems and sub-systems.  The text mentions "routing system", "Internet routing system" and "routing subsystem" many times (obviously!), but there is no description of what these terms mean — I'm sure many/most of the readers have an opinion of what these are, but I think it might be good to add something to the terminology section specially because statements like this are made: "state on a routing element beyond what is contained in the routing subsystem"; that way there is no questions as to what is in the routing system, or sub-system and what is not (at least for this document).

H. 3.2. (Extensibility) talks about the initial scope of I2RS (without references).  To extend the usability of this document, I would suggest that the statements of this section be made independent of the fact that the initial scope may be narrow.  IOW, I think you may want the protocol/data model to be extensible regardless of the size of the initial scope (even if boiling the ocean to start with, there will always be opportunities for extensions later).

I. s/an definition/a definition

J. If out of scope, I don't really see the value of 5.1. (Example Network Application: Topology Manager).  However, Section 5 does say that these types of "models are, at least initially, out of scope for I2RS" -- as I mentioned above, if this architecture is meant for the long run (not just the initial scope of the i2rs WG), then the 3rd architecture is valuable to illustrate.  IOW, the WG charter can control the scope, the architecture should be thought out for the long term.

K. s/to be to be/to be

L. Many protocols (routing-related and otherwise) are mentioned without references.

M. I don't think you need both of these references: "Yang 1.1 ([RFC6020]), Yang 1.1 ([I-D.ietf-netmod-rfc6020bis])".


[1] https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ballot/#alvaro-retana

(Martin Stiemerling) No Objection

(Benoît Claise) (was No Objection) Abstain

Comment (2016-04-22 for -14)
No email
send info
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.

(Alia Atlas) Recuse