At the IETF I2RS interim meeting, I raised the concern about conflicting
set
operations by I2RS clients to different I2RS agents,
Which may end up causing micro-loop or far-side loop.
There's no way, in this sort of architecture, to prevent people from tying a
noose in the rope. :-)
OTOH,
The problem with enforcing consistency in this environment is it would be just
as impossible to attain as it is with a distributed control plane in real time.
It seems, to me, that we can provide an interface, but the controller/software
doing the controlling must do the consistency insurance,
On 10/21/13, 5:02 PM, Scott Whyte wrote:
We've submitted a draft of what we believe to be interesting bulk data
collection use cases for I2RS, and the concomitant functionality
missing from existing solutions. Please read and comment.
Normative and informative references are still to be added,
Wouldn't this be a stumbling block for I2RS architecture? (sorry for having
missed the discussion on mailing list on this issue).
In distributed control plane, transient inconsistencies are repaired eventually
(once every node has updated topo info).
I am not sure I2RS mechanisms has built-in
Himanshu,
It seems like you are comparing apples to oranges when you compare a
distributed routing protocol to the interface to the routing system.
If it helps any, take a look at Fig 1. of
draft-ietf-i2rs-rib-info-model. The distributed routing protocol would
be a client. The I2RS agent (not
I don't think so (apples vs oranges).
Not sure if you got the point I made.
It is not about client - agent transaction integrity.
It is about different clients talking to different agents and making sure about
the network wide consistency.
If there is only one client talking to all agents, then
I2RS does not provide a single transaction spanning multiple I2RS
agents. Though a client may use I2RS to read state from an I2RS-agent
that was installed by another client via I2RS, ensuring consistency of
that state network-wide is completely up to the clients and is outside
the scope of I2RS
May be I2RS clients need to get ‘permission’ from an orchestrator or
“an I2RS-coordinator” before issuing ‘set’ operations to I2RS agent?
Backing up a little in the thread --this, specifically, is what we want to
avoid. We don't want a lock/release, or a transaction oriented protocol to
i2rs is basically an API into the router. I think what you're looking for is
an api into the network as a whole. I have yet to grok all the i2rs docs but
something like that seems very clearly Somebody Else's Problem - that is, out
of scope.
eric
-Original Message-
From:
Scott,
In addition RIB, there are much more data on router.
draft-jxf-i2rs-im-architecture-01 has identified many layers of information
on routers, as shown below. Do you need to get data on every layer?
P
| Network Service
I'd really like to start a conversation about the differences between a
topology IM model that is network-centric vs. device-centric. Clearly the
WG has strong and different opinions about it.
Since many people are here in Vancouver, focused on IETF and not their
day-jobs, this seems like a good
Hi,
I might be completely wrong but from a brief overview of the Topology API
Use Cases my guess would be.
The topology data model will be an undirected graph with nodes, edges with
certain properties representing part of the network topology and the
device centric model will be something
12 matches
Mail list logo
