Two difficulties with this diagram for our purposes:
1) We are (sooner or later, assuming we succeed) going to also be
manipulating many other properties that are not shown (Queues, marking,
firewalls, ...
2) I think it is important to show processes, because I think that there
is significant confusion as to which processes are the consumers of what
information.
Thank you or drawing this to help clarify the situation.
Yours,
Joel
PS: While not a big deal, I would like to try to be careful to focus on
the information models, not the data models, when we go forward from this.
On 2/25/2013 5:59 PM, Russ White wrote:
Y'all:
Because of a long and protracted exchange off list with a number of
folks, I've come to the conclusion that we can't (really) start with a
data model --even working from the use cases to a data model seems to be
difficult. I think we need to come to agreement on what a router looks
like first.
No, not blue, grey, green, or... :-)
Look at the attached (hopefully the attachment works --if not, I've
stashed a copy here, as well: http://www.riw.us/temp/router%20model.jpg).
Let's ignore the question of whether or not there is some sort of I2RS
local process --more on this in a sec.
Note I'm not claiming:
- This is the only possible model for a router's operation
- This is a model that is widely used and deployed
- This is a model that contains every piece of a possible router
What I am claiming is this is a useful model that will help us
understand what we want to do, and what we don't want to do --and, I
hope, it will lead to a better understanding of the difference between
policy, forwarding information, and configuration.
IMHO:
- If a process wants to inject information at A, then it can simply
participate in the routing protocol in question --so I2RS doesn't really
need to do anything there. In fact, I would argue that injecting
information at A without participating in the protocol could be very
dangerous, and we don't want to go there.
- I2RS should be in the business of injecting information at B. We can
discuss whether that should be through configuration or not (IMHO, it
should be).
- I2RS should be in the business of injecting information at C (because
the current use cases demand it). In fact, C should be a bidirectional
interface that looks, to the RIB, just like an on-box routing process
(like either of the other two routing processes shown in the diagram).
- I2RS should not mess with D. This is bad juju.
- I2RS should not mess with E, this is FORCES.
- I2RS should not mess with F, this is OpenFlow.
Now, to return to the idea of a "local process." There are several
issues to assuming a "local I2RS process." The first is that it
restricts implementation in a way that might be unacceptable in all
situations. Smaller devices with only partial I2RS interfaces might find
it painful to build a separate process, with all that entails, just to
support some simple commands from an I2RS controller. The second is that
assuming a local process really doesn't help us in any material way to
define anything. When we're in the process of building a data model for
interacting with BGP policy, for instance, how does saying, "well, the
local I2RS process has a data model that looks like x, which it
translates into data model y to talk through some local interface to the
BGP process," really help? The only thing I can see assuming a "local
process," does is add complexity.
So, thoughts...
- Is this a reasonable model of a controlled device?
- What would you add?
- What would you subtract?
- What specific operation can you think of that doesn't quite fit into
the model as it's shown?
Hopefully, this will kick off some discussion here, and bring us to a
place where we can go back to the two use cases the WG originally agreed
to restrict itself to, and make some progress in understanding how to
build the right pieces to support those use cases.
:-)
Russ
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
