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

Kireeti, have you also considered if there is andy
relationship or redundancy or overlap or such with
RFC 2667. Maybe all is OK, but I just want to make sure we
check. I had asked same question on MPLS list for te-link MIB.

Thanks,
Bert 

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email protected]]
> Sent: woensdag 3 september 2003 5:46
> To: Adrian Farrel
> Cc: [email protected]
> Subject: Re: WG Last Call: draft-ietf-tewg-mib-05.txt 
> 
> 
> 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.
>