[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:kireeti@juniper.net]
> Sent: woensdag 3 september 2003 5:46
> To: Adrian Farrel
> Cc: te-wg@ops.ietf.org
> 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.
>