Subject: RE: draft-ietf-mpls-lsr-mib-01.txt Released

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 03 Mar 2000 17:43:40 -0500

Hi Adrian,

         We were able to follow up on the remainder of your questions.
The responses are contained inline.

         --Tom

>9. Scope of Statistics
>
> >>It is good to add a sysUpTime stamp to show the scope of the
> >>counters returned.
>
> >We refer you to the ifMIB and MIB II for this. There is guidance in
> >the MIB which refers you to this, I believe.
>
>OK, I can't find the guidance or reference, but that doesn't matter.
>
>RFC2233 seems to support what I'm saying. It uses a "discontinuity time" to
>stamp the counters and show their relevance.  I quote...

         Since MPLS interfaces are derived interfaces from RFC2233,
the 2233 Discontinuity timer should apply here as well, so there is no
need to add these to the Perf tables.

>I suggest you add similar discontinuity times alongside each of your
>perfTables.
>
>10. Something Else to Count
>
> >>In addition to the counters you already have, I think you need to
> >>count the number of labeled packets that have been received on an
> >>interface/in-segment and were discarded because there was no
> >>cross-connect.  Or is this covered by one of your existing counts?
>
> >mplsInterfaceFailedLabelLookup
>
>Well, the text for this count says...
>
>        "This value indicates the number of labeled packets
>         that have been received on this interface and were
>         discarded because there were no matching entries
>         found for them in mplsInSegmentTable."
>
>I'm asking where we count the case that the inSegment _does_ exist, but that
>there is no cross-connect.

         Why do you want to count this case? Please explain
the situation where you would want to count this.

>20. mplsXCAdminStatus
>
> >>I think this would benefit from a DEFVAL.
>
> >The other adminStatus values do not have DEFVALS so
> >we would prefer to leave this one alone.
>
>See mplsInterfaceAdminStatus which has...
>    DEFVAL        { down }

         We left the DEFVAL out on the other adminStatus values
because each has a rowStatus associated with it.

         With respect to the pending comments from Arun, here they
are.

         1) The modifications to the XcEntry which you suggested have
been made as follows:
Special labels:
Entries indexed by reserved MPLS label values 0 through 15 imply 
terminating LSPs and MUST have mplsOutSegmentIndex = 0. Note that 
situations where LSPs are terminated with incomming label equal to 0, 
should have mplsInSegmentIndex = 0 as well, but can distinguished from 
originating LSPs because the mplsOutSegmentIndex = 0. The 
mplsOutSegmentIndex MUST only be set to 0 in cases of terminating LSPs.

An entry can be created by a network administrator or by an SNMP agent as 
instructed by CR-LDP or RSVP.

         2) The comment you made with regard to the BitRate textual
convention has been made to comply with that defined in RFC2233,
and will appear in the new draft as:

BitRate ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS      current
DESCRIPTION
"An estimate of bandwidth in units of 1,000 bits per second.  If this 
object reports a value of 'n' then the rate of the object is somewhere in 
the range of 'n-500' to 'n+499'. For objects which do not vary in bitrate, 
or for those where no accurate estimation can be made, this object should 
contain the nominal bitrate."
SYNTAX      INTEGER (0..'7FFFFFFF'h)

         --Tom