Subject: Re: MTU for tag/MPLS packets

From: Vasu Vuppala <[email-masked]>
Date: Fri, 21 Jan 2000 11:31:02 -0500

Ajiaz,

draft-ietf-mpls-label-encaps-07.txt discusses this issue.

Path MTU discovery is explained in RFC1191 and RFC1435.

Long, long time ago we had briefly discussed adding MTU TLV to LDP
but it was not pursued due to the amount of control traffic it would
generate with MTU changes.

- vasu

--- Aijaz Pathan <[email-masked]> wrote:
> Hi All,
>
> I was wondering if anyone had info/pointers to how a Tag/MPLS edge
> node should handle change in the MTU size
> because of addition of 4 bytes of tag header for Ethernet interfaces.
> For example, if the incoming Ethernet packet is already of MTU
> length, addition of the 4 bytes will cause it to be dropped when sent
> out another Ethernet interface.
>
> In the book "Switching in IP networks" ( By Davie, Doolan, and
> Rekhter ), section 5.3 says:
> "Tag switching uses the IP Path MTU Dsicovery procedures to ensure
> that even after the shim layer is added to the packet, the resulting
> packet size doesn't exceed the maximum packet size that could be
> transmitted without fragmentation."
>
> What exactly are these "IP Path MTU Discovery procedures"? Is there
> any other way of avoiding fragmentation?
>
> Thanks in advance.
>

---

From: Danny McPherson <[email-masked]>
Date: Fri, 21 Jan 2000 11:00:41 -0700

> generate with MTU changes.

The amount of MTU changes?   How often did folks envision actually 
expereincing "MTU changes"?

It does seem a bit kludgey to include the MTU and the PMTU stuff
does seems a better solution, but I really don't see MTU changes 
much (at all) in production networks.

-danny

---

From: Vasu Vuppala <[email-masked]>
Date: Fri, 21 Jan 2000 13:44:02 -0500

Danny,

> expereincing "MTU changes"?

My wording was off.
By that, I did not mean changes to the MTU of a link, but the "MTU"
of the path i.e. LSP, which would change with the topology.

> much (at all) in production networks.

The problem with "PMTU stuff" is that it is specific to IP. There
seems to be an interest in (directly) carrying other protocols over MPLS

for bridging, LLC/SNAP, voice etc, and it does not work there.

Another subtle and remote problem which had been discussed:
PMTU is generally associated with a destination (on the source node)
and not a "path", which makes sense for IP paths. With MPLS, there
can be multiple paths between a source and a destination, and this may
lead to problems (imagine two applications using the different paths).

but  the PMTU solution is good enough for the time being.

- vasu