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
On 3/15/16 3:20 PM, Susan Hares wrote:
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.
...
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].
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]
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]
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,
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]
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.
[ 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]
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.
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]
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.
[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]
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.
...
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
