The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Feb> msg00409



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

comments on draft-dubuc-mpls-bundle-mib-00.txt

  • From: Sudheer Dharanikota <sudheer@nayna.com>
  • Date: Wed, 28 Feb 2001 13:46:31 -0800
  • CC: mpls@UU.NET
  • Organization: Nayna Networks, Inc.
  • User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108 Netscape6/6.0

Jim:

Thank you for the interest in the work. My comments inline.

Jim Boyle wrote:

> Martin, good idea, if we're going to start thinking about having link
> bundles, we should probably think about mibs to get relevant information
> out of network (for nms) or into network (if that is one's manner).
> 
> I do think that this mib reaches too far, and replicates information that
> is available elsewhere.
> 

The goal is to not replicate the information. If it is
overlapping with other work, we will correct it.

> You mention an example of grouping 3 component links into 1 bundled
> link.  For some reason you mention 2 primary and 1 secondary, is this 1:N
> protection, and if so, is there a relevant APS/Sonet/SDH mib where this
> assocation of the secondary to the protected links should be made?

This association in my opinion should be independent of the
physical layer MIB, because this MIB is not restricted to
SONET itself.

> 
> In general, the mib should be able to grab interfaces and group them
> together, however it's my view that these become standard interfaces, seen
> in ifTable, in relevant OSPF mibs, TE mibs, etc...  The bundled mib keeps
> track of the relationship only (e.g. id 10 really is a composite of 1,2,3)
> 

We realized this problem while writing this MIB. There are
two approaches to this. One, extend the other protocol MIBs,
which makes our life difficult to approach the protocol MIBs
that are in the final stages (also with pre-ietf concepts).
Two, keep the relevant protocol extensions in the same MIB
but keep them as independent as possible for putting them
in the future protocol MIBs. We took the second approach.

> Why would one want to be able to not only get the OSPF TE metric from the
> bundled mib, and from the TEMIB?
> 

There are few ovrlaps. We have to refine the work. Thank you
for pointing us to this.


Cheers,

sudheer

> Anyways, my comment would be that the bundle mib should stick to a core
> business, and leverage information that exist (rightfully) in other
> places.
> 
> regards,
> 
> Jim