[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: more on de-coupling
Bobby Krupczak wrote:
My reading of the draft, leads me to believe it is very cisco-centric.
(However, it may be because I know you and know you're from Cisco
. . .) Its been a while since I've configured routers, and while most
routers have some sort of running vs standby config, the concepts
embedded in this set of drafts do seem to mirror cisco-style
configuration awefully closely.
A bit of a diversion- Cisco as a company is a lot more than just
routers. We nearly every type of device that Weijing mentioned. We
have Windows boxes and we have stuff that is based on other operating
systems as well. So, what it means to me at least, is that a
"Cisco-centric" view is umm... somewhat broad, we hope.
If someone on the list from some non-cisco network-gear company would
comment, that would be awesome. My ascend P75 (OK, I'm dating myself)
didnt exactly have a running vs. candidate-config, and many of the
smaller router boxes you can now buy hide any of this via those
dreaded web-interfaces. However, I suspect underneath they dont have
this. If this WG only focuses data models on the larger more complex
routers, would this be a mistake?
Indeed this was one of the design considerations for the group. We
wanted to support a broad collection of network devices that run the
gambit from a very small hub to a very large
gigahuge-does-everything-but-eat piece of gear.
Non-routers (e.g. workstations, etc.) dont necessarily have a
running-config vs candidate config either. In fact, their "config" is
so much more elaborately complex as to not fit this model very well.
Firewalls, dhcp servers, and other "network" devices may also be
troublesome to this model.
Well, it should surprise you not at all that Cisco has firewalls, dhcp
servers, and other "network" devices. Where the model breaks down is
precisely in one place: can you contain the configuration as a discrete
object? No? Well, for that we're not there yet.
All of this is aside from the model argument that the SBC folk raise.
Eliot
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>