Problem Statement for the Interface to the Routing System
draft-ietf-i2rs-problem-statement-11

Agree with Brian.

I had a hard time deciding on the value of this document as a standalone RFC.  I came to the conclusion that the valuable pieces (specifically Section 5) would serve a better purpose as part of the i2rs Architecture document (draft-ietf-i2rs-architecture).  If this document is to be published I won't stand in the way, I'm ABSTAINing instead.  I put more specific comments below.


The document contains a mixture of what I think are broad and vague requirements ("needs" and "key aspects") for an I2RS Protocol, along with a general picture of what an i2rs can/should be (which seems to step into the WG's charter in some places).

Maybe I can't see it, but the document expresses "needs" without explicit justification (e.g. "the need…real-time security threat responsiveness…more dynamically manage and program routing systems…support rapid control and analytics…automate even the simplest operations…support real-time, asynchronous interactions using efficient data models and encodings that are based on and extend those previously defined…learn topology, network analytics, and existing state from the network as well as to create or modify routing information and network paths…feedback loop…data-model driven interface to the routing system…precisely control routing and signaling state based upon policy or external measures…dynamically configure policies and parameter values for the various routing and signaling protocols based upon application-level policy decisions…detailed topological state that provides more information than the current functional status…") or details of what is expected, or a clear comparison to the current state (the Appendix is not referenced in the main text, nor is it comprehensive).

It is unclear to me whether all those "needs" are requirements, or how they are translated into them.  The last "need" mentioned above does present the current state of the art (BGP-LS) and it provides examples of missing information, but without indicating if anything is required.  Other requirement-like statements not associated with "needs" are equally unclear: "…providing the ability for an application to dynamically request that measurements be taken and data delivered is important."  I think everyone can agree that it is important, but is it a necessary characteristic of the I2RS protocol (or maybe something else?)?

Section 5 seems to spell out requirements for an I2RS Protocol, but the aspects listed/discussed I think fall short of providing strict guidance.


The term "I2RS" is sometimes used without a modifier (client, agent, protocol, etc.), not making it clear what the term is referring to.  Some of the missing modifiers seem obvious, but others seem to be potentially referring to the WG itself and trying to define what the scope or charter should be — that is obviously better served in the charter itself.  For example:

* "…the I2RS scope…"  Is that within the scope of the I2RS protocol, the WG, ??   One piece of text mentions "…outside the I2RS scope for standardization."   That makes me think that the answer is the i2rs WG, but then it makes me wonder why we need this document to clarify the WG's charter.

Then there are also explicit references to what the WG should do; again, better served by the charter itself.

* "The I2RS Working Group must select the suitable protocol(s) to carry messages between the I2RS Clients and I2RS Agent."  Even though it may be implicit, there's no explicit action in the i2rs WG charter to select a protocol, and of course no mention of clients/agents (as those are described in the Architecture).

* "The I2RS Working Group must identify or define a set of meaningful data-models for information in the routing system and in a topology database."  I think this is already part of the charter.

* "One set of data-models that I2RS should focus on is for interacting with the RIB layer…"   The charter mentions something similar.

* "At a minimum, within the I2RS scope…"  The scope of the WG, or are you talking about something else that hasn't been defined?

* "I2RS will define needed information and data models…"


Finally, it also worries me that other documents put too much stock in this one, relying on it to provide guidance in places where it falls short.  For example:  draft-ietf-i2rs-architecture says in Section 3. (Key Architectural Properties) that "some architecture properties such as performance and scaling are not described below because they are discussed in [I-D.ietf-i2rs-problem-statement]".  

* The word "performance" doesn't exist in draft-ietf-i2rs-problem-statement, but there are aspects (in Section 5) that resemble it: "should be able to handle a considerable number of operations per second", "within a sub-second time-scale, it should be possible to complete simple operations"…  I wouldn't call those Key Architectural Properties.

* There is some sparse treatment of scaling: "For example, for scaling, some exported data or events may be better sent directly from the forwarding plane…", or "Scalable, Filterable Information Access:  To extract information in a scalable fashion that is more easily used by applications, the ability to specify filtering constructs…is very valuable."  Again, not what I would call Key Architectural Properties.

I basically agree with Alvaro's points. On top of that, a problem statement in 2016 when the charter was done in 2012 ... hmm ... 
If (parts of) the content needs be published, it should be in the arch document. Figure 1 is architecture anyway, right?
And ... a problem statement with a normative reference to an architecture. Really?

My position on these types of documents should be pretty clear at this point. The parts that do have archival value should be published as a part of a protocol specification or architecture document.

I'm not going to stand in the way of this document being published.

I am taking an abstain position as it is my preference that the informative rationale which guides the i2rs solution space should be in the Architecture document and what remains can exist as a living WG document for participants to reflect upon - that in itself need not be published as an RFC.