[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: netconf and working "on the box"



Randy,

When the in-band is lost a lot of time the box becomes totally
un-manageable and thus requires a trunk roll.  A trunk roll is very
expensive and the following requirements are observed:

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.

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.  

On a side note, both OOB and in-band typically have lower bandwidth so
both require certain filtering mechanism especially for the NE->manager
direction.  But I think you have this covered?

-faye 



-----Original Message-----
From: Randy Bush [mailto:randy@psg.com] 
Sent: Wednesday, March 12, 2003 2:47 PM
To: George Jones
Cc: xmlconf
Subject: Re: netconf and working "on the box"

> Because it's concievable, especially during a DoS attack, that you
> can't get to the box in-band and it is precicely under those
> circumstances that you need to be able to poke around and
> change configurations.

i understand why i use an oob interface.  what i am not getting is
in what way the oob interface differs from an in-band interface that
would change the syntax or semantics of how i configure.

randy


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

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