The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

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

         The reason for not putting this stuff in the MPLS-TE-MIB for
example, was because it was seen that information from ISIS, OSPF,
SONET, etc... might have to be included too. Doing this in the MPLS-TE
MIB (or TE-MIB) would pollute the generic model there.

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

         I think that part of the motivation for putting all of this
stuff in one place was to make things easier for those managing the
bundles. Having to scramble between many different MIBs to collect the
information provided might be cumbersome. Having this MIB essentially
"point" at the other ifIndexes involved in the bundle seems to be
a more general/flexible approach, although I do see your point in
re-using what is already out there. We will go back and examine
the other relevant MIBs and see if there is any overlap.

         --Tom




>regards,
>
>Jim