- Original Message -----
From: "Jeffrey Haas" <[email protected]>
To: "Andy Bierman" <[email protected]>
Cc: "t.petch" <[email protected]>; "Jeffrey Haas" <[email protected]>;
<[email protected]>
Sent: Friday, May 02, 2014 4:40 PM
> On Fri, May 02, 2014 at 08:29:00AM -0700, Andy Bierman wrote:
> > I picture the operational state as the mixing bowl for the 2 config
sources
> > and data learned from protocols and system events. It seems
> > both NETCONF and I2RS would be able to pick the data is cares about
> > out of that.
>
> I think this is what I'd like to see personally.
>
> > This is a weakness in YANG that may get improved in YANG 1.1.
> > Since it is officially just for NETCONF, there are no mechanisms
> > (other than vendor extensions) to tag the data as specific to
> > some subset of protocols.
>
> As I mentioned elsewhere, I'm hoping we don't go down the path of
"editable
> operational state", instead configuration semantics for our purposes.
>
> > > I think that we will, that is the set of YANG leafs etc that I2RS
will
> > > want to edit and the sets of leafs that I2RS will want to get in a
> > > straightforward manne will not be the same (eg the latter will
include
> > > read-only statistics and 'config true'). And yes, it could all be
done
> > > with filters, which could be a nightmare.
> > >
> > >
> > Examples of read-only data that only I2RS would want to get would
help.
>
> I believe that it would largely overlap config false state desired for
> normal module purposes in many cases. For example, interface
statistics
> would likely be part of the standard interface module. Where things
get
> interesting are specific augmentations that tie different information
> domains together - interface stats correlated against routing, for
example.
> (For prefix X, traffic is seen - similar to IPFIX exports.)
Using my usual terminology, of read only statistics as being the part of
state (YANG leafs etc with a substatement of 'config false') that is not
operational state, and turning to the I2RS use case documents, I see:
in -keyupdate
" There are a variety of statistics related to the operation of BGP
that are invaluable to network operators. These statistics generally
help operators, and developers, understand the present state and
future scalability of BGP."
or in draft-white
" o The ability to interact with traffic flow and other network
traffic level measurement protocols and systems, in order to
determine path performance, top talkers, and other information
required to make an informed path decision based on locally
configured policy."
or in -mbb
" The I2RS architecture (client-agent) should solve the two problems
mentioned above naturally by enabling the use of centralized
controllers, which control and manage the entire network's devices
and store the whole routing and service information directly.
Meanwhile, the outages and traffic congestion or discards can be
detected real-time with I2RS Client(s) connected to the I2RS agents
in each node which provide real-time status via notification service.
An I2RS client with this ability will allow the I2RS clients to keep
optimal state dynamically all the time."
while I would expect it to be required for anything to do with ECMP/SRLG
etc so yes, I see a need for I2RS to access read-only statistics.
Tom Petch
> -- Jeff
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
