Re: [rbridge] Rbridge Management

Hi Eric,

The suggested paragraph wasn't actually intended to "address management
of RBridges generally" and I would agree that it fails to do that.  I
think that should be done in a separate document. The paragraph was just
intended to reduce possible complaints that the document completely
ignored management or zero configuration management.

RFC 3410 seems to be the standard general SNMP reference when you just
want to mention just one RFC. As you say, RFC 3410 points to many
additional SNMP RFCs. If there is a better RFC to point to, the draft
should be changed to use that.

The text in protocol draft -06 was modified in response to your comment
to mention management via Layer 3.

Donald

> -----Original Message-----
> From: Eric Gray [mailto:eric.gray@ericsson.com] 
> Sent: Wednesday, November 14, 2007 7:21 AM
> To: Eastlake III Donald-LDE008; Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Rbridge Management
> 
> Donald,
> 
> 	Assuming that we can accept that RFC 3410 is the appropriate 
> reference for SNMP generally (it seems to be an informational RFC
> that talks about the relative advantages of different versions of
> SNMP), this assertion is technically correct.  One can use SNMP in
> the way it is described in RFC 4789 to manage RBridges.
> 
> 	However, there are probably at least 3 management models that
> may apply to RBridges, where there are issues/concerns with whether 
> SNMP/L2 would be sufficient (e.g. - from a security perspective,
> from a management platform support perspective, etc.).  The 3 models
> I can quickly imagine - where SNMP/L2 may be either inadequate or 
> not particularly useful - are:
> 
> 1) litteral plug-and-play - no management is anticipated and what 
>    small amount of management that may apply would most likely be
>    done via web-access (IP address required, probably configured
>    via DHCP) or direct connection to a computer;
> 2) some management anticipated (minimal VLAN configuration, or a
>    deployment involving/expecting use of non-default behavior in
>    one or more aspects (out-of-band, or console, management may
>    be sufficient, SNMP/L2 may provide inadequate or incompatible
>    security);
> 3) extensive management is the rule (plug and play is a non-goal,
>    avoidance of address configuration is explicitly a non-goal,
>    use of device interactive security access - requiring dialog
>    via IP - is unavoidable, etc.).
> 
> 	Considering (at least) these cases, while the paragraph you
> propose may be technically correct, it may also be insufficient to 
> address management of RBridges generally.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: rbridge-bounces@postel.org 
> > [mailto:rbridge-bounces@postel.org] On Behalf Of Eastlake III 
> > Donald-LDE008
> > Sent: Tuesday, November 13, 2007 5:11 PM
> > To: Developing a hybrid router/bridge.
> > Subject: [rbridge] Rbridge Management
> > 
> > Judging from the experience of previous documents in the 
> > IESG, I believe
> > it would be wise for the base protocol document to say 
> something about
> > management.
> > 
> > So I think that something like the following should be added, 
> > perhaps as
> > a paragraph just before the 2.1 Section heading.
> > 
> > "Rbridges can be managed with SNMP [RFC3410]. The Rbridge 
> MIB will be
> > specified in a separate document. SNMP can be transported 
> directly by
> > Layer 2 (see [RFC4789]) so its use within the bounds of an Rbridge
> > campus does not require that Rbridges be configured with Layer 3
> > addresses such as IP addresses."
> > 
> > Any comments?
> > 
> > Donald
> > 
> > _______________________________________________
> > rbridge mailing list
> > rbridge@postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 

_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge