Re: INET-Addresses not used in MPLS MIB Modules

["C. M. Heard" <heard@pobox.com>]

On Fri, 31 Jan 2003, Wijnen, Bert (Bert) wrote:

> For various cases, they cannot use the INET-ADDRESS-MIB
> definitions. They were using different mechanisms at
> different places, which is not good. So I suggested that
> if they can indeeed not use the INET-ADRESS-MIB TCs, that
> they define their own TCs that every MPLS mib module can
> re-use. It is actually more TE (Traffic Engineering)
> related than pure MPLS... but ok...
> 
> Seems they too RFC2851 as an example, and maybe not 3291.

That's not good.  We went through a long discussion on the
mibs@ops.ietf.org list why the "registered immediately before"
stuff was not a good idea (if I recall correctly, it came up
in the context of the review of the MALLOC-MIB, which would
have been seriously hobbled by that constraint).

> This is what they came up with. Any further comments?
> 
>           TeHopAddress ::= TEXTUAL-CONVENTION
>              STATUS     current
>              DESCRIPTION
>                 "Denotes a generic Tunnel hop address.
> 
>                  A TeHopAddress value is always interpreted within the
>                  context of an TeHopAddressType value.  The
>                  TeHopAddressType object which defines the context must
>                  be registered immediately before the object which uses
>                  the TeHopAddress textual convention.  In other words,
>                  the object identifiers for the TeHopAddressType object
>                  and the TeHopAddress object MUST have the same length
>                  and the last sub-identifier of the TeHopAddressType
>                  object MUST be 1 less than the last sub-identifier of
>                  the TeHopAddress object."
>              SYNTAX     OCTET STRING (SIZE (0..16))
> 
>           TeHopAddressAS2 ::= TEXTUAL-CONVENTION
>              DISPLAY-HINT "d"
>              STATUS      current
>              DESCRIPTION
>                 "Represents a two octet AS number."
>              SYNTAX      Integer32 (0..65535)
> 
>           TeHopAddressAS4 ::= TEXTUAL-CONVENTION
>              DISPLAY-HINT "d"
>              STATUS      current
>              DESCRIPTION
>                 "Represents a four octet AS number."
>              SYNTAX      Unsigned32

Hello?  Do they really intend to mix Integer32, Unsigned32,
and OCTET STRING in a single object?  If so, have they
specified the encodings?  (If they really want to do this,
the SMI has a way ... it's called Opaque ... not politically
correct, but IMHO the right thing to do if you are going to
be mising types like this.)

>           TeHopAddressIPv4 ::= TEXTUAL-CONVENTION
>              DISPLAY-HINT "1d.1d.1d.1d"
>              STATUS      current
>              DESCRIPTION
>                 "Represents an IPv4 network address."
>              SYNTAX      OCTET STRING (SIZE (4))
> 
>           TeHopAddressIPv6 ::= TEXTUAL-CONVENTION
>              DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d"
>              STATUS      current
>              DESCRIPTION
>                 "Represents an IPv6 network address."
>              SYNTAX      OCTET STRING (SIZE (16))

These look a lot like clones of InetAddressIPv4 and
InetAddressIPv6 from from RFC 3291.

>           TeHopAddressLspID ::= TEXTUAL-CONVENTION
>              DISPLAY-HINT "1d.1d.1d.1d:2d"
>              STATUS        current
>              DESCRIPTION
>                 "Represents a unique ID for a CR-LDP LSP.  This ID is
>                  assigned by the head end LSR, and consists of an IPv4
>                  address belonging to the head end followed by a two
>                  octet unsigned integer that is unique for each LSP that
>                  starts at this head end."
>              SYNTAX  OCTET STRING (SIZE (6))
> 
>           TeHopAddressType ::= TEXTUAL-CONVENTION
>              STATUS     current
>              DESCRIPTION
>                   "A value that represents an address type for a Tunnel
>                    hop, taken from the following list:
> 
>                    unknown(1)   An unknown address type.
>                    ipv4(2)      An IPv4 network address.
>                    ipv6(3)      An IPv6 network address.
>                    asnumber2(4) A two octet Autonomous System number.
>                    asnumber4(5) A four octet Autonomous System number.
>                    unnum(6)     An unnumbered interface index.
>                    lspid(7)     An LSP ID, for CR-LDP Tunnels [RFC3212].
> 
>                    Each definition of a concrete TeHopAddress value must
>                    be accompanied by a definition of a textual convention
>                    for use with that TeHopAddressType."
>              SYNTAX     INTEGER {
>                            unknown(1),
>                            ipv4(2),
>                            ipv6(3),
>                            asnumber2(4),
>                            asnumber4(5),
>                            unnum(6),
>                            lspid(7)
>                         }
> 
>           TeHopAddressUnnum ::= TEXTUAL-CONVENTION
>              DISPLAY-HINT "d"
>              STATUS      current
>              DESCRIPTION
>                 "Represents a 32bit unnumbered interface index."
>              SYNTAX      Unsigned32

Presented out of order, and another Unsigned32 mixed with OCTET STRING.

> Thanks,
> Bert 

How can you stand it?

//cmh