RE: netconf and working "on the box"

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

Ran,

The deployment scenario still exists but I can see that it is not a
problem in the enterprise or a ISP network.  Definitely in the broad
band and access network though.  You might want to check with the broad
band or access network providers.

-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/>