The MPLS WG Archive

[Toby Smith <tob@laurelnetworks.com>]

Giles Heron <giles@packetexchange.net> writes:

> > ...which I think is the correct approach, and I think that's best
> > served by simply maintaining the received mapping with the mismatched
> > MTU and reconfiguring one of the boxes based on the information that
> > the user can see in the sent & received label mappings show commands,
> > instead of having an LSR send a release as soon as it receives a
> > mapping with an MTU it doesn't expect, and then having to figure out a
> > way to get the released mappings back again later.
> 
> but if you retain the received mapping then presumably the circuit will
> start "working"?

No, not at all.  Luca is very sage, and accounts for this in the trans
draft:

     - Interface MTU

       A 2 octet value indicating the MTU in octets. This is the Maximum
       Transmission Unit, excluding encapsulation overhead, of the
       egress packet interface that will be transmitting the
       decapsulated PDU that is received from the MPLS network. This
       parameter is applicable only to VC types 1, 2, 4, 5, 6, and 7,
       and is REQUIRED for these VC types. If this parameter does not
       match in both directions of a specific VC, that VC MUST NOT be
       enabled.


So, we can happily retain the mismatched label mapping without fear of
any forwarding taking place, and still have the information available
for the user to perform diagnosis.  As a benefit, when the problem's
resolved, one of the LSRs will issue a withdraw/mapping to convey the
modified MTU, and things will start working.

Regards,
Tob