The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Apr> msg00065



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Last Call MPLS-TC-MIB #6

  • From: "Thomas D. Nadeau" <tnadeau@cisco.com>
  • 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