Re: WG Last Call: draft-ietf-tewg-mib-05.txt

[Kireeti Kompella <kireeti@juniper.net>]

Hi Adrian,

On Fri, 22 Aug 2003, Adrian Farrel wrote:

> Good job.

You remember when you submit a composition to your third grade teacher
and it comes back gory with multiple stab wounds from a red pen?  Bert's
and your reviews bring back those memories!  But I do appreciate your
detailed review!

Since the Last Call has ended, I have addressed all your comments in
the -06 version, just now sent to the repository.  The new MIB module
passes the laugh test I call a compiler.

> 1. Could you explicitly clarify in the introduction that the MIB applies
>     only at the ingress of tunnels. That is that it cannot be used to
>     monitor tunnels at transit nodes or at their egresses.

Okay.

> 2. The introduction makes (correctly) much of the fact that the MIB
>     module can be used to model and manage any tunnel. Yet when
>     we get to teSignalingProto we discover that the options are only
>     'other', rsvpte' and 'crldp'. This seems to make it very MPLS-centric.
>
>     I appreciate that 'other' covers a lot of possibilities, but aren't there
>     some other tunneling protocols/techniques you'd like to list here?
>
>     In particular, I'd like to see 'none' added to the list to cover statically
>     configured (unsignaled) tunnels.

I added 'static' to the list.

> 3. teNextPathIndex seems to be in contradiction with the indexes to
>     tePathTable.
>
>     tePathTable has paths listed under the primary index of
>     teTunnelIndex so that you can find all of the paths for a given
>     tunnel. The secondary index is tePathIndex and is described as
>     being unique within the context of a tunnel. The use of
>     teNextPathIndex would give a tePathIndex value that was unique
>     across the whole table.
>
>     Admitedly one of these statements is a subset of the other, but
>     it is not immediately clear how you expect teNextPathIndex to be
>     used.

I'm impressed by your unfailing politeness ("not immediately clear").
This is a boo-boo.  teNextPathIndex belongs within teTunnelEntry, not
global.  I'll fix.

> 4.  Could you supply a means to enable/disable notifications?
>      Something like...
>      teNotificationEnable OBJECT-TYPE

Okay.

> 5. It is not clear (to me) how you activate a tunnel (i.e. cause it to begin to be
>     signaled). I presume you use are using the rowStatus transitions to active
>     event. Could you clarify this (and how to initiate tear-down) either in the
>     description of teTunnelEntry or in the descriptive text before the MIB module
>     definition.

Will do.

>    teAdminGroupTable OBJECT-TYPE
>        SYNTAX       SEQUENCE OF TeAdminGroupEntry
>        MAX-ACCESS   not-accessible
>        STATUS       current
>        DESCRIPTION "A mapping of configured administrative groups.  Each
>                     entry represents an Administrative Group, and
>                     provides a name and index for the group.
>                     Administrative groups are used to label links in the
>                     Traffic Engineering topology in order to place
>                     constraints (include and exclude) on Tunnel paths.
>
>                     A groupName can only be linked to one group number.
>                     The groupNumber is the number assigned to the
> <                   administrative group which are used in constraints,
> >                   administrative group which is used in constraints,
>                     like tePathIncludeAny, tePathIncludeAll, etc.
>                    "
>        ::= { teInfo 9 }

Is I wrong to think that group are plural?

>    teTunnelIndex    OBJECT-TYPE
>        SYNTAX       Unsigned32 (1..4294967295)
>        MAX-ACCESS   not-accessible
>        STATUS       current
>        DESCRIPTION "A unique index that identifies a Tunnel.  This
>                     index MUST be unique across Tunnels and interfaces
>                     on this host.
> # Unclear. Are you saying that a tunnel index must not have the same value as
> # an interface index? Or are you saying "MUST be unique across Tunnels on all
> # interfaces on this host"

The former (think unnumbered FAs).  Will clarify.

(Rest okay, will be incorporated.)

>    tePathBandwidth  OBJECT-TYPE
>        SYNTAX       Unsigned32
> # You could use the MPLS TC MplsBitRate
>        UNITS       "Kilobits per second"
>        MAX-ACCESS   read-create
>        STATUS       current
>        DESCRIPTION "The configured bandwidth for this Tunnel,
>                     in units of thousands of bits per second (Kbps).
>                    "
>        DEFVAL      { 0 }
>        ::= { tePathEntry 7 }

Thanks, I will.

BTW, the -12 version of the MPLS TE MIB says "bits per second" (rather
than "Kilobits per second") for MplsBitRate (haven't checked the other
docs).  Dunno if -12 is the latest ....

Kireeti.