Subject: RE: MPLS-TE and MPLS-LSR MIB - Failed Label lookup suggestions/qu estions

From: David Zelig <[email-masked]>
Date: Tue, 29 May 2001 10:48:43 +0200

Thomas,
 
To detect configuration error all the H/W needs is a one buffer space toward
the S/W to report the last failed lookup, I agree that "any fault any rate
of fault" is not feasible to implelemnt, and it is not realy required.

While many implementations cannot support it, this feature may be added as
optional MIB for ones that can support it.

David

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 4:06 PM
To: Dave Danenberg; Cheenu Srinivasan
Cc: [email-masked]; [email-masked]
Subject: Re: MPLS-TE and MPLS-LSR MIB - Failed Label lookup
suggestions/questions

[Note: Cheenu's new coordinates]

>1) The MPLS-LSR-MIB has a means of counting failed label lookup
>questions (via mplsInterfaceFailedLookup). I would think it handy to
>also supply the actual label that failed. This could be a new (optional)
>object: mplsInterfaceLastFailedLookup (SYNTAX MplsLabel).

         While sounding like a good idea, in practice this is
actually quite difficult (or impossible) when one
considers that most implementations would count and
find the failed label in hardware. The addition of
a time stamp and the actual label in the logic, and
then having to report it up to software is probably
just not going to happen. Further, several of the
implementations I know of don't actually count this
variable due to the fact that labeled packets which are
received for no installed label are simply discarded
before the MPLS logic even looks at the packet.

>2) Let's say a packet arrives at an MPLS interface. The top label lookup
>is OK and the packet is destined for this node so the label is popped.
>Now there is one more label which directs the exposed packet to a
>specific local port. This inner label fails the lookup. So I would think
>it handy to have  two new (optional) objects in the MPLS-TE-MIB
>MplsTunnelPerf table: mplsTunnelPerfFailedLookup and
>mplsTunnelPerfLastFailedLookup.
>
>What do you think?

         Since the switching is going to happen at the LSP
level, this situation would be reported on the LSP as described
above (if even implemented).  The NMS can associate the
LSP errors with the tunnel if need be.

         --Tom