Subject: Re: MIB Question

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 05 Aug 2002 15:50:50 -0400

[Cross-posting as this discussion has applicability to all three WGs.]

At 02:37 PM 8/2/2002 -0400, David Allan wrote:

>I've been rummaging through MTU related stuff and not that there is 
>no-where that record MTU discards (either MPLS MIBs or Interfaces group 
>MIB). Agree that for IP, it's a big yawn and probably means someone is 
>doing MTU discovery and is a non-problem.
>
>Issues is PWs where there is no payload fragmentation and VPNs where the 
>packet payload has no provider routable addresses in it (no ICMP reply 
>possible). IMHO the "use a big MTU" stipulation won't hold up forever, and 
>some token effort to prepare for the future may be in order.
>
>Seems to me that it would be useful to have a counter in the LSR MIB for 
>non-IP MTU discards (maybe with a threshold trap although I'll let my 
>betters comment further) so that at least some indication of a problem was 
>possible as currently packets simply "black hole". I'd suggest that the 
>non-IP category would also include stack depth > 1 (e.g. 2547) as ideally 
>path MTU handling for a VPN should be a PE problem.

         Dave,

         The MPLS-LSR MIB does contain counters that an implementation
may count MTU errors:  mplsInSegmentErrors,  mplsInSegmentDiscards,
  mplsOutSegmentErrors, and mplsOutSegmentDiscards.  However, I do
agree that MTU discards are not explicitly counted.   In the non-PW and
non-VPN cases, I have not seen any requirements to-date to add such
counters from providers, thus we have not added any.

         One question, you mention this within the context of PW/VPN. In 
the case
of PWE3, wouldn't it be  more appropriate to include MTU discards in the 
generic
PW VC counters into the PW-MIB?  For VPN, we could certainly add them into the
PPVPN-MPLS-VPN MIB explicitly as well. The only hesitation I have for adding
these to the PPVPN MIB is that to-date have not had such a requirement from 
any
providers, so I would like to get some more input from that group first.

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.

---

From: "David Allan" <[email-masked]>
Date: Thu, 8 Aug 2002 09:36:30 -0400

Hi Tom:

<snipped>
> agree that MTU discards are not explicitly counted.   

Yep, and IMHO MTU is a different thing than either true errors or
congestion. Lumping it into another category may not be useful as path MTU
discovery is really not an error. 

> In the non-PW and

Agreed and not surprising, although in the VPN case I think you do have a
problem or anytime stack depth > 1. For TE, RSVP advertises the MTU to the
ingress, so you would expect infrequent issues if ever (perhaps FRR when
running MTU on the edge). For LDP there is the MTU draft coming up, so the
error may fall into the category of S/W bug if happening in a fully
converged network although I'd presume configuration errors can creep in as
well.

> One question, you mention this within the context of 
> PW/VPN. In the case of PWE3, wouldn't it be  more appropriate to include
MTU 
> discards in the generic PW VC counters into the PW-MIB?  

What do non-PEs do? PEs in theory can fragment.

> For VPN, we could certainly add them into the
> PPVPN-MPLS-VPN MIB explicitly as well. 

IMHO this is a transport problem, and may happen with the PEs never knowing
about it. So I don't think a VPN MIB is the right spot to fix this.

> The only hesitation I 
> have for adding these to the PPVPN MIB is that to-date have not had such a

> requirement from any providers, so I would like to get some more input
from that 
> group first.

Fine

cheers
Dave