Re: INET-Addresses not used in MPLS MIB Modules

[Mike MacFaden <mrm@riverstonenet.com>]

On Mon, Feb 03, 2003 at 02:54:05PM +0100, Wijnen, Bert (Bert) wrote:
>The best place to look at is draft-ietf-tewg-mib-03.txt
>which was Kireeti's work and which he suggested to the MPLS
>folk to adopt so that they could use similar thing in the
>mpls-te-mib. So since they are getting ready to do so, I
>started checking with the mreviewers team what would be the 
>issues we need to raise.
>  
>> Anyway, if I assume that draft-ietf-mpls-te-mib-09.txt is not totally
>> off wrt. what is on the table, then it looks like they want to
>> identify an MPLS tunnel hop and such a hop can be identified by
>> various things (IP addresses, AS numbers, ...). If this understanding
>> is correct, then they should introduce a naming space for tunnel hops,
>> e.g. MplsTunnelHopIndex and MplsTunnelHopIndexOrZero TCs and have
>> sparse mapping table indexed by an MplsTunnelHopIndex object which
>> uses multiple objects of various types to indicate how the tunnel is
>> identified. Once this in in place, they can simply refer to tunnel
>> hops by using MplsTunnelHopIndex or MplsTunnelHopIndexOrZero.
>> 
>I can try to present this solution to them (unless you want to do so
>yourself). By the way, Mike KacFaden, are you reading? 

Ya Bert.  

>You are their MIB doctor, remember?

We've have both done at least four reviews now. Not yet have
all the MIB modules checked out clean with smicng/smilint.
Each time you and I send detailed notes to the authors.
Some of my prior comments may be found here: 
   http://www.macfaden.com/ietf

My last review of these modules occured at the 
interim meeting July 2002 (Saturday before IETF). 
Loa Andersson sent out the official minutes. 
At that meeting Tom Nadeau presented a radical change 
to the indexing to the LSR MIB module for GMPLS to 
support longer labels. At that meeting there wasn't
agreement for this change.

I'd haven't seen any new drafts based on the last 
round of your comments.
 
>> Anyway, how many MPLS MIBs are there? I found:
>> draft-ietf-mpls-bundle-mib-04.txt.gz
>> draft-ietf-mpls-fastreroute-mib-01.txt.gz
>> draft-ietf-mpls-ftn-mib-05.txt.gz
>> draft-ietf-mpls-ldp-mib-09.txt.gz
>> draft-ietf-mpls-lsr-mib-09.txt.gz
>> draft-ietf-mpls-tc-mib-05.txt.gz
>> draft-ietf-mpls-te-mib-09.txt.gz
>> 
>> Perhaps the first thing would be to post which MIBs have a problem
>> with the INET-ADDRESS-MIB to get a picture where to start. ;-)

Here is an earlier presentation Chris and I did NANOG21 presents  
view of how the mpls modules fit together:
http://www.nanog.org/mtg-0102/ppt/mibs/sld078.htm 

The draft-ietf-mpls-* modules are modelled after a fashion
on the ATM Forum MIB Modules.

>I think the two that have a problem right now are:
>
>   draft-ietf-tewg-mib-03.txt
>   draft-ietf-mpls-te-mib-09.txt

FWIW, these two MIB modules overlap in what they manage.
Neither has really looked at RFC2667/TUNNEL-MIB either it seems.
At first I hoped they'd collapse into one MIB module.

Yet it was clear at the last meeting that there isn't going to 
be any consolidation. The former can stand on its own and 
the latter requires the framework above (lsr/ftn modules).

In terms of real products: cisco will implement the former 
and Juniper the latter.

Yet there should be some harmonization of these two MIB modules.
So I asked Kireeti that things like the descriptive name of a 
tunnel should at least be the same type/length if not the same TC.

Regards,
Mike MacFaden