Re: [i2rs] Alvaro Retana's Abstain on draft-ietf-i2rs-problem-statement-10: (with COMMENT)

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

Alvaro: 

Responses to your comments are offered below.  I appreciate your comments and your careful thought.  I am responding to this today as I just realized Alia was out on vacation this week.  Three high level comments to you and Benoit that seem to have been lost between 2012 and 2016:   

1) I2RS - is interface to the routing system.   It is not a protocol, but an management interface which involves both protocol and data models.  Since there seems to be confusion in your mind, it seems more important to emphasize this in short broad scope problem statement.  

2) I2RS - was founded and chartered with a novel idea - "Do not create new management protocols - but extend current protocols and create new data models".    IMO - due to Benoit and NETMOD/NETCONF this has led to an intellectually challenging, but a very personally enriching collaboration across many areas.  

3) If these broad summarizes of the industry trends are not sufficient as needs, please provide some example of a forum or an research studies that you will consider valid.  Specifically, do you want the forums such as ETSI NFV NM or Cablelabs or NANOG/RIPE/LACNIC?  Or can we extend this to ONS or 4G/5G work or OPNFV?    

Thank you for engaging in this discussion. 

Sue Hares 
  
-----Original Message-----
From: i2rs [mailto:[e-mail]] On Behalf Of Alvaro Retana
Sent: Monday, February 15, 2016 12:40 PM
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: [i2rs] Alvaro Retana's Abstain on draft-ietf-i2rs-problem-statement-10: (with COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-i2rs-problem-statement-10: 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-problem-statement/



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

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

Sue:  In reality, the WG chair and the Reviewing AD debated the value of publishing this document.  We have placed the requirements of section 5 in the midst of the architecture document and the requirements documents.  However, in looking at combined architecture and the requirements document the problem we were trying to solve got lost.  Therefore, we decided a short (10 page) document on the problem this new interface provided a clear context. 

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

Sue:  The document is intended to be a broad scope document on the needs and requirements.  The architecture and the requirements documents should make this more specific. 

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

Sue: You are correct.  In all these places the needs are specified without specific justification.  
I have seen these requirements in ETSI NFV NM and Cable-labs or operators forums.  Would referencing these documents have made the document stronger?  Discussions with the AD and the WG felt it would have diffused the broad industry trends.  If these sources are sufficient, I think we could reference something for each of these specific cases. 

Alvaro: 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?)?

Sue: Two points: 1) I2RS = interface not just protocol.   2) Needs - scope from broad to specific 

1) The I2RS work is not just a protocol but interface to routing system.   
I2RS = I2RS ephemeral Yang Data Models + I2RS-higher-level protocol 
I2RS-higher-level protocol = Config (NETCONF/RESTCONF with I2RS extensions) + data transfer protocols (E.g. IPFIX, BGP-LS with I2RS extensions) 

2) Needs - have a scope from broad to specific. 

The broad needs - are what we are trying to summarize.  The WG did not initially agree on the broad needs so this is a document of these pieces (We can tie this to operator forums if you wish.)  
The broad needs are focus to a framework in the architecture.  The architecture is focus to specific protocol + information models, which are in turn focus to extensions to existing protocols (straw-man), + yang data models.  This focus is because I2RS was charter not to invent whole new protocols, but whenever possible to utilize and extend.  
 

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

Sue: This is by design.  The document leads the reader to section 5 as a short way to provide the background for the next wave of documents: Architecture, requirements, informational models. 

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

Sue: I think your question actually points out why we need something to introduce the fact the I2RS is not a protocol but an interface.   An interface (unlike the BGP protocol) is a combination of protocols + yang model + defined actions of the agent/client.   See my comment above. 

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

Sue:  This text in section 2 can be changed.  However, your very questions in this AD review indicate confusion that this text is trying address.  I2RS = Interface and not just a protocol. Would the following text work for you? 

/new: To leverage existing management work, the I2RS (interface to routing system) seeks to extend existing management protocols and data models.   The I2RS work must define the framework and requirements for both suitable protocol(s) to extend to carry messages between I2RS Client(s) and I2RS Agent(s).  The protocol should provide the key features specific in Section 6.  

The I2RS work must also identify or define a meaningful set of data models for information in the routing system and in a topology database. /

Alvaro: 
* "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…"

Sue: As my comment above indicates, this indicates what the I2RS interface indicates. 


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

Sue:  There are two parts to your argument: 

1) do not let one document depend too heavily on another 
2) performance needs to be clearly specified. 

On 1) - the documents in the I2RS stream are carefully built to stack on each other in order not to repeat text from one document to another.  IMO this is a better way theoretically - because it leads to less text.  

On 2) It is important here to state the need for the key architecture of scale.  We can work on additions to the document, but we need to build this in the following way:

1) What is the source you will accept as "authoritative"  - as you do not agree with the documents stating industry trends, 
2) Where would you suggest this scaling points get added. 

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