Subject: Re: Last Call MPLS-TC-MIB #6

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 03 Apr 2003 11:05:52 -0500

Mike, thanks for the review. I suggest cross-posting
the MPLS mailing list since these are last-call comments.

>This version is generally much better. Some concerns below:
>
>1) There are some enums like
>MplsLabelDistributionMethod,
>MplsLdpIdentifier,
>MplsRetentionMode
>that do not have an "unknown/other/unconfigured" category.
>I assume this is on purpose.

         These are straight out of the protocol spec; no more
no less.

>3) Missing REFERENCE clauses?
>MplsLsrIdentifier,
>MplsLdpIdentifier,
>MplsLdpLabelType,

         RFC3031 is referenced in the references section.
I think it is obvious to MPLS folks where these came
from -- RFC3031.  I suggest we leave these as-is
since readers should be familiar with RFC3031.

>4) MplsLdpLabelType: the description does not add any semantic
>of value, it just repeats the SYNTAX stuff.

         We can shorten to just, "The Layer 2 label types which are
defined for MPLS LDP and/or CR-LDP."

>5) TeHopAddressType: enum starts with 0 while all other
>enums start with 1, is this on purpose or just an
>inconsistency?
>6) TeHopAddressAS will most likely be a duplicate of
>whatever Jeffrey Haas does on the updates to the BGP mib modules.
>Should probably consult on this before we end up with TWO TCs
>that can be used to represent a 2 or 4 byte ASN.
>7) TeHopAddressUnnum doesn't seem to be described well enough
>and am not sure that we get any consistent results
>across vendor products. Consider adding some pointer or verbage
>to usage so that these opaque octet strings are better defined.

         The current state of these objects were as strongly
suggested by Bert and after numerous iterations including
the review from Atlanta. I hesitate to change them further unless
there is a serious flaw that you can identify. On the issue of
consistency with the BGP TCs, if the BGP guys want to reference
our TC,  then that is cool but we are not in a position at this
point to wait around to see what they want to do before we
change these TCs.

         --Tom

http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X

---

From: Mike MacFaden <[email-masked]>
Date: Fri, 4 Apr 2003 21:03:45 -0800

>point to wait around to see what they want to do before we

The new BGP MIB module draft-ietf-idr-bgp4-mibv2-03.txt uses
the following TC from *RFC 3291* 

InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "Represents an autonomous system number which identifies an
         Autonomous System (AS). An AS is a set of routers under a
         single technical administration, using an interior gateway
         protocol and common metrics to route packets within the AS,
         and using an exterior gateway protocol to route packets to
         other ASs'. IANA maintains the AS number space and has
         delegated large parts to the regional registries.
 
         Autonomous system numbers are currently limited to 16 bits
         (0..65535). There is however work in progress to enlarge the
         autonomous system number space to 32 bits. This textual
         convention therefore uses an Unsigned32 value without a
         range restriction in order to support a larger autonomous
         system number space."
    REFERENCE  "RFC 1771, RFC 1930"
    SYNTAX      Unsigned32

versus

  TeHopAddressAS ::= TEXTUAL-CONVENTION
             STATUS      current
             DESCRIPTION
                "Represents a two or four octet AS number.
                 The AS number is represented in network byte
                 order (MSB first).  A two-octet AS number has
                 the two MSB octets set to zero."
             SYNTAX      OCTET STRING (SIZE (4))

I contend you can remove TeHopAddressAS. 

InetAutonomousSystemNumber
a) Is much better described 
b) Is easily imported from an existing RFC (bgp mib modules use it)

Thanks,
Mike MacFaden