Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

["Susan Hares" <[e-mail]>]

Alvaro: 

 

I have released a -14 of the architecture document.  The only one I did not really address is #j.  Comments on changes are in red. 

 

 

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.

 

Did not change.  The example is useful for the first set of data models. By the way, many of the IESG comments are looking for specific examples for version 1.   

 

Let me know if this is a major issue. 

 

Sue 

 

-----Original Message-----
From: i2rs [mailto:[e-mail]] On Behalf Of Alvaro Retana
Sent: Tuesday, March 15, 2016 9:01 AM
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

 

Alvaro Retana 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> 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/> https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/

 

 

 

----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------

 

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

 

Resolution:  see addition of Safe modification of routing state via I2RS

 

 

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

 

 

Resolution:  Will talk to Alia about problem statement or architectural statement.   If Alia’s revision of the protocol problem statement is not sufficient, I can add a new sub-section in section 3. 

 

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.

 

Resolution:  I changed the problem statement to a normative reference.  

 

 

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

 

Added: 

 

The I2RS protocol security requirements for I2RS protocol version 1 are contained in

[draft-iietf-i2rs-protocol-security-requirements] and I2RS security environment requirements for protocol version 1 are contained draft-ietf.i2rs-protocol-security-environment].

 

 

E. s/I2RSS/I2RS – fixed 

 

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

 

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

 

Added definition: 

routing system/subsystem:  is a set of software and hardware

that handles determining where packets are forwarded to which the I2RS system connects. 

The term "packets" may be qualified to be layer 1 frames, layer 2 frames or layer 3 packets. 

The phrase "Internet routing system" implies the packets which have IP as layer 3. 

A routing "subsystem" indicates that the routing software/hardware is only the subsystem of

another larger system.

 

 

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

 

Changed/Added to the following (I may have edited this a bit more in the final version). 

 

The scope of I2RS work is being designed in phases to provide

deliverable and deployable results at every phase.   Each

phase will have a specific set of requirements, and

the I2RS protocol and data models will progress toward these 

requirements. Therefore, it is clearly desirable for the I2RS data models

to be easily and highly extensible to represent additional 

aspects of the network elements or network systems.   It should be

easy to integrate data models from the I2RS with other data.  This reinforces the 

criticality of designing the data models to be highly extensible, preferably in a

regular and simple fashion. 

 

 

I. s/an definition/a definition  fixed

 

 

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.

 

Did not change.  The example is useful.  Should I refer the example to version 1 of the protocol? 

 

K. s/to be to be/to be

fixed

 

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

All references are I the abbreviation.   Please let me know if you find ones that are not. 

 

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

 

Removed Yang 1.0 [RFC6020] 

 

[1]

 <https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ballot/#alvaro-retana> https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ballot/#alvaro-retana

 

 

_______________________________________________

i2rs mailing list

 <mailto:[e-mail]> [e-mail]

 <https://www.ietf.org/mailman/listinfo/i2rs> https://www.ietf.org/mailman/listinfo/i2rs