Greetings Russ,
Some thoughts in line...
On 25Feb2013, at 14.59, Russ White <[email protected]> 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.
Agreed
>
> - 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).
In principal, agreed - however, a standardized way of driving that (e.g. via
NETCONF) would be quite useful (and we are not there yet), but not in scope
here.
>
> - 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).
Agreed
>
> - I2RS should not mess with D. This is bad juju.
As above with the other policy insertion point.
>
> - I2RS should not mess with E, this is FORCES.
Agnostic, here
>
> - I2RS should not mess with F, this is OpenFlow.
I assume F (which is not on the diagram) is between the FIB and the local
processor, in which case, I agree
>
> 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.
The goal of I2RS should be to support an external interface to the RIB process
of a routing element. If a system designer wants to use I2RS internally within
a single routing element instance, that would be valid, but is not the target
of the protocol. My feeling is that most routing system developers/platforms
already have that link sorted out :)
>
> 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?
I do believe that it would be useful for I2RS to get the full candidate
database from the various protocols (maybe as they feed in from the routing
processes), before best path winnowing is done. I assume that is in scope
here, but is not completely clear.
>
> 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
> <router model.jpg>_______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
--
李柯睿
Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc
Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf
Check my calendar availability: https://tungle.me/cdl
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
