On 25/01/17 09:30, Giles Heron wrote:
Hi Benoit
agreed - the model should be independent of the protocol used to
access it.
As mentioned earlier on the thread, OpenDaylight has implemented older
versions of the model. Over time I’d expect each service in
OpenDaylight that uses the models to upgrade to the upcoming RFC. In
general OpenDaylight implements the models as read-only (i.e. in its
operational data-store), though as Robert Varga has noted there’s a
case where we use the config data-store for device inventory (longer
term that will move to the ietf-network model but not
ietf-network-topology - though there might be use cases where you’d
have read-write access to ietf-network-topology, e.g when using it to
express intent.)
OpenDaylight enables access to topology data using NETCONF and
RESTCONF as the north-bound protocoIs are independent of the models
accessed. I believe there has also been some work on using AMQP as a
north-bound protocol, and that the Kafka plug-in could be used to send
data change notifications for the operational models (so you’d get a
message when a link went up or down etc.) South-bound we have also
used ODL to read topology data from a device using NETCONF/YANG (IIRC
we showed a demo of this using Homenet running on OpenWrt at IETF a
couple of years back).
I’m also working with other groups such as MEF and OpenROADM to
leverage the I2RS topology models for their YANG efforts. So
clearly the models need to be used in a non-I2RS environment.
+1.
I am working on JSON RPC ODL southbound into non-ODL systems. For some
of the use cases you may need to build topologies out of the information
you receive from it.
So from my extremely selfish implementer perspective having topology
models which is stapled to a particular protocol and are not allowed to
be used in a more generic way, namely in a non-I2RS environment, is a
definitive NO GO.
A.
Giles
On 24 Jan 2017, at 22:04, Benoit Claise <[email protected]
<mailto:[email protected]>> wrote:
Dear all,
The thread that grows faster than you can read...
Let me repeat what I mentioned already on the I2RS mailing list:
This document contains a YANG model, a generic YANG model that could be
accessed by NETCONF, RESTCONF, or the future I2RS protocol.
This document doesn't say (and that would be a mistake IMO if it would)
that this YANG model can only be accessed by the I2RS protocol.
Hence I'm advocating that the security considerations diligently
followhttps://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that
they don't go in the I2RS protocol specific details.
This comment was made for draft-ietf-i2rs-yang-network-topo, but is
equally applicable to this draft-ietf-i2rs-yang-l3-topology draft.
I still maintain this point of view: it would be a mistake to limit a
data model usage to a particular protocol. These topology documents
are not I2RS YANG models, these are YANG models, which can be used in
different contexts. I'm very concerned if we start having per-WG or
per context data models in the IETF.
Btw, I haven't seen a RFC specifying what the I2RS protocol is, only
the requirements.
We can't modify the current generic YANG security considerations for
an I2RS control plane and a new datastore that are not yet specified.
If you want to describe how I2RS will be using those topology YANG
models (and any YANG models btw), then it's suitable to include this
part of the I2RS protocol spec or part of an I2RS applicability
statement. This is typically where you would describe some protocol
specific information such as "write contention for two clients
writing a node using I2RS priority (linked to I2RS User-ID)".
Let me make my point differently. Let's assume for a moment that I2RS
needs to use the IETF interface YANG model, does it mean that you
will require RFC 7223bis with an updated security considerations?
This can't be.
I still think the generic YANG security guidelines is suitable, as it
relates to IETF specified protocols NETCONF and RESTCONF. Addition of
some generic information about the data model (not I2RS protocol)
might be useful though. For example, text around "there is a risk
that a write to a topology may create a looping topology or overload
a particular node". Note that I don't think the the security
considerations is the best section for this though.
Regards, Benoit
Sue:
The implication of that statement is that actual implementations (like
ODL etc) now
need to copy/paste this model without the I2RS text to use them in other ways.
This seems
strange and just about the most inefficient way to use these that I can think
of.
—Tom
On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares<[email protected]> wrote:
Anton:
See earlier message to Martin. Topology models are I2RS YANG Models
designed for ephemeral state with specific security concerns. This is not
your basic YANG model no matter which data store ephemeral gets linked to.
Where is ephemeral state? By IESG Design of charter, I2RS is not in charge
of defining ephemeral state solution. NETMOD/NETCONF are. Go ask them.
Do not blame the messenger echoing NETMOD results,
Sue
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Anton Ivanov
Sent: Tuesday, January 24, 2017 8:30 AM
To:[email protected]
Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
On 24/01/17 11:52, Juergen Schoenwaelder wrote:
Susan,
so are these YANG models regular YANG models or are these YANG models
specific to the yet to be defined I2RS protocol and yet to be defined
datastores?
I think this is the core of Martin's and my question. A simple clear
and concise answer would be nice.
+1.
A.
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
