[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: INET-Addresses not used in MPLS MIB Modules
Thanks Mike. How I can stand it?
I do not know. I have been struggling with these MPLS MIB
authors for... Oh I guess a year now. Oh well.
Good to see it is not me.
In your comments, when you say
> These look a lot like clones of InetAddressIPv4 and
> InetAddressIPv6 from from RFC 3291.
Do you mean that we do no understand why they would not just use
those TCs instead? So in my view, they would only define:
TeHopAddress ::= TEXTUAL-CONVENTION
TeHopAddressAS2 ::= TEXTUAL-CONVENTION
TeHopAddressAS4 ::= TEXTUAL-CONVENTION
TeHopAddressLspID ::= TEXTUAL-CONVENTION
TeHopAddressType ::= TEXTUAL-CONVENTION
TeHopAddressUnnum ::= TEXTUAL-CONVENTION
And the properly and correctly of course.
Do you agree?
Other comments from other people?
Thanks,
Bert
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: vrijdag 31 januari 2003 19:01
> To: Mreview (E-mail)
> Subject: Re: INET-Addresses not used in MPLS MIB Modules
>
>
> 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
>
>