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

From: Kireeti Kompella <[email-masked]>
Date: Tue, 2 Sep 2003 20:45:59 -0700 (PDT)

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.

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 4 Sep 2003 11:52:47 +0200

FYI, I had copied Dave Thaler (author/editor for IP Tunnel
MIB) on my questions regaringd overlap/conflict/relationships.

I think it is good that the WG knows

Thanks,
Bert 

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: donderdag 4 september 2003 1:56
To: Dave Thaler
Cc: Wijnen, Bert (Bert); Adrian Farrel
Subject: RE: WG Last Call: draft-ietf-tewg-mib-05.txt 

Hi Dave,

On Wed, 3 Sep 2003, Dave Thaler wrote:

> I will review the MIB this week.
> We know we need an IPv6 Tunnel MIB (this fact is even mentioned in RFC
> 2667), or perhaps an Inet Tunnel MIB if we want only one.

> Just from the below, it sounds like the te-link MIB should logically
> extend the IP Tunnel MIB, just like the L2TP MIB does.

There are two different MIBs here -- the TE Tunnel MIB (filename
draft-ietf-tewg-mib-06.txt) and the te link MIB (filename
draft-ietf-mpls-telink-mib-03.txt).

> That is, it shouldn't define its own ifType or its own local or
> remote address objects, and it's probably missing the other things the
> IP Tunnel MIB has (which would be moot if it extended the MIB like L2TP
> does).

As I said, the local and remote address objects for TE Tunnels are
quite different, and a TE tunnel is not necessarily an interface (or
even an IP tunnel).

But you might find that the TE Tunnel MIB performance stats are worth
stealing for the Inet MIB.

> Or I could be wrong... I'll know more once I go through it.

Look forward to your comments.

Kireeti.