Re: INET-Addresses not used in MPLS MIB Modules

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Wijnen, Bert (Bert) writes:

>> I would like to know the reasons why they can't use the
>> INET-ADDRESS-MIB definitions. Except that they broke several
>> things, the definitions are not that much different. OK, it looks
>> like they want to treat AS numbers the same as addresses. But since
>> you can't do unions of a arbitrary SNMP base types, this won't work
>> anyway. If they need such a union, they have to use multiple
>> objects anyway and in this case the INET-ADDRESS-MIB definitions
>> should be OK.
>> 

Bert> I don't get this... are you saying they cannot do this with
Bert> their proposed TeHopAddressType and TeHopAddress ??

TeHopAddressAS2 is an INTEGER not an OCTET STRING as someone else
already noted.

>> (And it somehow strikes me to consider an AS number an address
>> anyway.)

Bert> Well, same for Unnum and LSPID... so the use of term "Address"
Bert> is maybe not the best choice. Maybe it is just TeHopIdentifier
Bert> and sometimes that is an address, sometimes it is something
Bert> else?

Bert> What would be your recommendation to them?

Looking at draft-ietf-mpls-te-mib-09.txt, I do not see the TCs
responsible for this thread. Perhaps I have no clue where to look at.

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.

Bert> They have been struggling with this for a while. I believe you
Bert> have been discussing some of this with Kireeti in the past. 

We had some email exchanges - not sure how much this was discussion in
the sense that we managed to understand each other.

Bert> I have them convinced that they should use a common
Bert> mechanism/approach for all of their MPLS related MIBs (as
Bert> opposed to doing things different in every MIB Module). But they
Bert> want to move forward, so if we have an issue, can we then
Bert> recommend something better. I am not sure I have a better
Bert> solution for them. Do you?

We have the typical communication problem here. I am not an MPLS
expert and becoming one is not high on my agenda this week. 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. ;-)

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>