Subject: Re: [rbridge] draft-ietf-trill-rbridge-mib

From: Anil Rijhsinghani <[email-masked]>
Date: Wed, 26 Jan 2011 11:59:28 -0500

Hi Vishwas,

> 1. I think we should have a seperate tree for the Rbridge. I notice 
> some of the tables are the same as IS-IS. It will be very confusing to 
> code a MBI which is half IS-IS and half TRILL IS-IS.

IETF convention is to leverage pre-existing MIBs for pre-defined protocols.
Otherwise, we would end up with bloated MIBs and duplicated work.
In this MIB we have re-used management work done for IS-IS as well as Bridges,
and added new objects defined by the TRILL protocol.

> 2. There is no information for MultiTopology.

We do not yet have multi-topology in TRILL.

> 3. Another thing that needs to be kept is the MTU table. Which has MTU 
> information received from all the devices in the network. I know we 
> have MTU objects at a link and neighbor basis.

What would be the management benefit of adding such a (potentially
huge) table? It seems to me that it would suffice for a manager to know
the configurable Desired MTU per Rbridge, its neighbors, and the agreed MTU for
the campus. For information regarding other Rbridges, it can visit those Rbridges.

> 4. We probably need tohave Multicast Address listner  table too.

The group rbridgeSnooping contains a minimal level of multicast listener and snooping information necessary to support TRILL. Adding all objects necessary for
IPv4 and IPv6 snooping is a non-goal and belongs in an independent Snooping/Listener MIB, as this is not functionality defined by TRILL. If there
are additional objects you believe are necessary specifically to support TRILL,
please list.

> 5. We will need a table for the the information in the system for 
> distribution trees, and information advertized by each system, or 
> atleast a way to change the values to be configured for a system.

There is a group and table for distribution trees, rbridgeDtree and rbridgeDtreeTable. If you believe there are useful configurable objects
missing, could you please list them?

Regards,
Anil

-----Original Message-----
From: Vishwas Manral [mailto:[email-masked]]
Sent: Monday, January 17, 2011 1:17 PM
To: [email-masked]
Cc: Rijhsinghani, Anil; [email-masked]
Subject: draft-ietf-trill-rbridge-mib

Hi Anil/ Kate,

I briefly looked at the TRILL MIB and had the following top level comments:

1. I think we should have a seperate tree for the Rbridge. I notice some of the tables are the same as IS-IS. It will be very confusing to code a MBI which is half IS-IS and half TRILL IS-IS.
2. There is no information for MultiTopology.
3. Another thing that needs to be kept is the MTU table. Which has MTU information received from all the devices in the network. I know we have MTU objects at a link and neighbor basis.
4. We probably need tohave Multicast Address listner  table too.
5. We will need a table for the the information in the system for distribution trees, and information advertized by each system, or atleast a way to change the values to be configured for a system.

Thanks,
Vishwas

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 26 Jan 2011 12:38:22 -0800

Hi Anil,

> and added new objects defined by the TRILL protocol.
No the MIB's will not be bloated.

By having control protocols for 2 different layers use the same MIB,
you are forcing to have the entire functionality in one address space,
or having to have an unnecessary middle layer which will have to probe
two different protocol modules.

Note using the same protocol machine does not mean we reuse the same
MIB. A similar example is OSPFv2 and OSPFv3. They share protocol
mechansims and not all OSPFv2 mechanisms are duplicated in OSPFv3,
however the MIB's have to be different.

> We do not yet have multi-topology in TRILL.
May be you want to see the Layer-2 IS-IS and TRILL IS-IS draft.

> the campus. For information regarding other Rbridges, it can visit those Rbridges.

Note a MIB is a logical way of manipulating data. You do not need to
have special tables for them. The data I am talking about is already
present in IS-IS. The idea here is to let management access to it.

We can discuss the other smaller points later.

Thanks,
Vishwas