RE: netconf and working "on the box"

["Faye Ly" <faye@pedestalnetworks.com>]

Ran,

To continue on this topic, I don't think any network engineer with a
green field deployment scenario will purposely design a 'single point of
failure' management network.  This is more of retro fit into a legacy
network, let's say DSL or APON.  Either case doesn't really have any OOB
management except driving all the way to the curb and plug the laptop
into the console port.  I guess we can argue in this case what is the
point of using XML then because they also have the legacy OSS to deal
with?  But shouldn't we say that out front that we are not addressing
the network management scenario where the in-band is the only means? 

Also the problem with SNMP, XML over a bunch of stuff plus FTP/TFTP will
probably not do well with a low bandwidth management interface.  Has
anybody look into the wireless management yet?  They are much worse than
DSL last time I looked.  Also I have a question regarding low bandwidth
management interface: Does this mean we need an ACK for critical
management traffic or we definitely DON'T need a ACK to stress out the
interface even more?  Very interested in finding out what is your
experience with this?  I certainly don't know the answer.

-faye
 
-----Original Message-----
From: RJ Atkinson [mailto:rja@extremenetworks.com] 
Sent: Thursday, March 13, 2003 9:33 AM
To: Faye Ly
Cc: xmlconf
Subject: Re: netconf and working "on the box"


On Thursday, Mar 13, 2003, at 00:55 America/Montreal, Faye Ly wrote:
> When the in-band is lost a lot of time the box becomes totally
> un-manageable and thus requires a trunk roll.

This was not true for any commercial-grade operational network I've
worked on.  In all the networks I've worked on, there was a quite
separate out-of-band access channel that could be used to access the
console (and hence the vendor's CLI) for any device (e.g. router,
switch, terminal server) in the network itself.  And I've worked
on US DoD networks, enterprise networks, and commercial ISP networks
(so far).

I would never intentionally to deploy a network with XMLconf, SNMP,
or any other in-band mechanism as the *only* way to configure/manage
the network's own devices.  This concept of not relying on any
in-band mechanism as the only mechanism is a very old one, long
predating my arrival on the scene.

> 1. The protocol may have to take redundant or secondary path to the
> network element into consideration so that when the primary route to 
> the
> NE is lost, the secondary kicks in.  OOB interface typically doesn't
> have this requirement.

In the Internet, IP routing is performed dynamically within the network,
so the application that is moving XMLconf around does not know anything
about the path taken by its IP packets between the application's
host and the device being managed.  So it should never be the case
that the "protocol may have to take redundant or secondary path to the
network element into consideration".

> 2. It is absolutely required to have the network element to be able to
> recover the in-band management channel when it is the only means that
> this NE can be managed.  This translates to some small set of
> configuration is required (such as IP address and route to the agent
on
> NE) to keep the box manageable and they may require different security
> level. Sometimes this also requires pre-provisioning or OOB only
> provisioning.  Also the requirement of notification on this small set 
> of
> configuration parameter.

I would never willingly deploy any "network element" that could only
be managed in-band.  If necessary, I'd redesign the network to avoid
suffering from that constraint (in fact, I have done such at least 
once).

If folks think that it is usual/normal/common to be forced to deploy
the network's own equipment with that "critical single-point of failure"
of in-band-management-only, then I'd sure love to get educated about
the kinds of networks where that is the case.  Details would help a lot.

Ran
rja@extremenetworks.com


--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>