The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Title: RE: MIB Question

Hi Tom:

<snipped>
>          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.  

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
> non-VPN cases, I have not seen any requirements to-date to add such
> counters from providers, thus we have not added any.

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