Subject: [i2rs] Call for feedback - I2RS protocol requirements [3 weeks

From: "Susan Hares" <[email-masked]>
Date: Tue, 15 Mar 2016 15:20:55 -0400

Hi all: 

While working on the I2RS protocol strawman, some of the design team and
early reviewers have disagreed on requirements for the data streams.
Therefore, the chairs need input on the requirements for the data streams. 

Currently the approved requirements have the following types of inbound or
outbound streams: 

1)      Read/writes - simple read/writes or rpc requests, 

2)      Publication/subscription - via the pub-sub requirements (outbound
data stream, inbound control)  

3)      Actions  - via rpc requests (rpc, rpc-response) 

4)      Some unsecured outbound stream (TBD) 

As chair, I reviewed the use case requirements and found 11 requirements for
I2RS data flow in the (IC) in charter requirements in the I2RS use case
requirements document (draft-ietf-i2rs-usecase-reqs-summary
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase-reqs-summary> ).
These requirements suggest adding:  1) IPFIX as an outbound data stream for
traffic monitoring data, and 2) outbound data streams which are data form
agnostic (Any of XML, JSON, MTL, protobufs, etc.) over any transport.   I've
placed the details on these data flow requirements in
(draft-hares-i2rs-dataflow-req-01.txt), and I've listed these requirements
below. 

We plan to do I2RS work in phases so we can include a wide scope of outbound
protocols (DF-REQ-02/03/09), IPFIX as outbound stream from I2RS ephemeral
statistics (DF-REQ-04/05), handling of large data flows outside of pub/sub
push (DF-REQ 06).  We also have run into request to make sure OAM/ephemeral
actions are tailored to work during the network congestion or high resource
requirements for routing system (DF-REQ-07/08/09), and that batch uploads of
routes work effectively.   The only ones I personal (chair hat off) strongly
recommend is DF-REQ-01 and DF-REQ-10 so we can vary the level of checking on
large batch uploads of routes for certain applications.  

Jeff and I would like your feedback.   To aid this, Sue will present the
issues of this topic at the Interim on 10/16/2016 and IETF along with
thoughts on the protocol strawman.   

Sue Hares 

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

 DF-REQ-01: Support writing to the ephemeral copy of the Local RIB with
three different types of checks: 

minimal data reception checks (TLVs of data valid), all non-referential
checks (e.g. do not do leafref, MUST, 

instance identifiers), and do referential checks via three different rpcs.
[Added due to practical consideration with I2RS RIB uploads].

[any form data and transport]

DF-REQ-02: The support of large data transfers in a data format agnostic
format.  This the I2RS protocol should

support transport of data in any format including: XML, JSON,  MTL
(ALias/Waveformat, .mtl), protobufs, and ascii text.  

DF-REQ-03: Support of any transport [any data form], 

[/any form data and transport]

[IPFIX] 

DF-REQ-04: Support for the ability to send traffic monitoring information
using IPFIX protocol and IPFIX templates,  

DF-REQ-05: Support of transmitting traffic statistics for filter-based
policies (BGP-FS, I2RS FB-RIB, policy routing), IPPM, SFLOW, and others in
yang data model format or IPFIX templates formats over XML or JSON.  

 [/IPFIX] 

[ large data flows outside pub/sub] 

 DF-REQ-06: I2RS should be able to support an action which allocates
internal resources for the I2RS agent

(memory, processing time, interrupts) and outbound data flow bandwidth.  It
is expected that an action would be

included in a data model in an "rpc"-like format in yang. 

[/data flows outside of pub-sub -  pub-sub already has this restriction] 

[OAM and outage flows] 

 DF-REQ-07: The I2RS should be able to support an action that interacts with
routing OAM functions. 

 DF-REQ-08: The I2RS Agent must be able signals that it will be using
different protocol with different constraints (security, priority of data,
or transport) or different constraints on the  existing protocol (smaller
message sizes, different priorities on data carried, or different security
levels).   (UDP + security vs. TCP + security) 

[/OAM and outage flows]  

[yang] 

DF-REQ-09: Yang MUST have a way to  indicate in a data model has actions
which allow: 

different transports, different resource constraints, or different security.

DF-REQ-10: Yang MUST have a way to indicate a data model has different
levels of checking where: 

lowest level is message form only, medium level checks message format plus
data syntax, and highest level uses the

message format, data syntax and referential check netconf configuration
does.  The default level for I2RS is message format plus data syntax. 

[/yang]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Mar 2016 15:40:31 -0400

Thank you for your work on this Sue.  I disagree with some of the 
requirements.  I will comment on them in-line below, eliding you summary.

I hope and expect to be on the call tomorrow to participate in the 
discussion.

Yours,
Joel

> Therefore, the chairs need input on the requirements for the data streams.
...
> instance identifiers), and do referential checks via three different
> rpcs.   [Added due to practical consideration with I2RS RIB uploads].

I don't know that we have clarity on the details of this requirement, 
but there clearly is a need here.  Expecting a device to handle absolute 
nonsense without checking is clearly unacceptable.  On the other hand, 
folks have repeatedly indicated that the full sent of YANG integrity 
checks are a significant source of the time it takes to do NetConf / YANG.
To a significant degree, I would think that be careful to NOT specify 
MUST clauses we don't want checked in ephemeral models would seem to help.

> [/any form data and transport]
I understand that these two requirements come from the old large data 
set document.  However, I do not believe that they are appropraite or 
necessary.  Whatever protocol we adopt will have format or formats. 
Those will be the ones used.  The solution will not be agnostic.  There 
is no requirement to ship ascii, except as  side-effect of shipping XML 
in RestConf or NetConf.  We should not elevate an effect into a requirement.

Also, being format agnostic means that there is no way to drive the 
existence of a common format between a range of clients and a range of 
agens.  A multiplicity of optional formats is a recipe for failures of 
interoperability.

>
> [IPFIX]
>
> DF-REQ-04: Support for the ability to send traffic monitoring
> information using IPFIX protocol and IPFIX templates,
>
> policies (BGP-FS, I2RS FB-RIB, policy routing), IPPM, SFLOW, and others
> in yang data model format or IPFIX templates formats over XML or JSON.
>
>   [/IPFIX]

There is clearly information that is well suited to transfer using 
IPFIX.  And an operating solution using I2RS is likely to use IPFIX as 
well.  I do not see any reason why the I2RS component should include, 
mandate, or reference IPFIX.  I am trying to imagine an I2RS subscribe 
request trying to set up an IPFIX reporting flow without having it go 
through the proper IPFIX setup stages.

So, this looks like a description of a good idea that is not a 
requirement on I2RS.

> (memory, processing time, interrupts) and outbound data flow bandwidth.
> It is expected that an action would be
>
I can not parse what this requirement is outside of pub-sub.  While some 
actions may be large, I do not know what the protocol expectation, or 
system expectation, is that would meet this requirement.

>
> [OAM and outage flows]
>
>   DF-REQ-07: The I2RS should be able to support an action that interacts
> with routing OAM functions.
>
> different protocol with different constraints (security, priority of
> data, or transport) or different constraints on the  existing protocol
> (smaller message sizes, different priorities on data carried, or
> different security levels).   (UDP + security vs. TCP + security)
>
> [/OAM and outage flows]

This seems to mix several different things.  Support for interacting 
with routing OAM is a models issue.  As far as I can tell, it has 
nothing to do with the data exchange being discussed here.

Then there is a discussion of signaling what protocol is being used. 
The description is confusing.  with some of the protocol models we are 
proposing, there is a capability negotiation phase, which I am happy to 
utilize.  But I would hate to rule out using RestConf because it does 
not alow us to negotiate the use of something else.  We are supposed to 
pick the protocol.

> lowest level is message form only, medium level checks message format
> plus data syntax, and highest level uses the
>

The first of these two I flat disagree with.  Trying to define, on a 
per-model basis, the transport or security requirements of the model 
simply does not work.  The model describes something to be manipulates. 
  The transport and security requriements derive from the environment 
and operational practices of the operator in question.  This came up 
earlier in the context of conflict handling.  The model is simply the 
wrong place to define this.

The second requirement is about what level of checking the I2RS agent 
will perform.  It is not clear to me how much range of choices we will 
really have.  Assuming there are choices, for the same reasons as above, 
it is not at all obvious to me that the decision resides at a per-model 
level.

...