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

From: Jim Boyle <[email-masked]>
Date: Tue, 27 Feb 2001 10:07:46 -0700 (MST)

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.

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?

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)

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

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

---

From: Sudheer Dharanikota <[email-masked]>
Date: Wed, 28 Feb 2001 13:46:31 -0800

Jim:

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

> I do think that this mib reaches too far, and replicates information that

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

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

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

> 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