The MPLS WG Archive

[Ben Black <ben@layer8.net>]

Certainly, if it was desired by an operator, the MTU for the network could
be the global minimum, but there is a lot of room for policy in the draft.
As long as the resultant MTU is valid for the path in question, it really
doesn't matter how nodes pick their MTU.  


Ben

On Fri, Nov 09, 2001 at 09:37:51AM -0500, David Allan wrote:
> Ben:
> 
> (long winded comment)
> 
> I agree that there is potentially a problem, and you have a solution, but
> (and first to conceed there is no real data to back up my suspicion) that in
> any heterogeneous network, routing changes will result in a signicant load
> of advertisments of MTU changes. For example, in a liberal label retention
> network, previously on a routing change there would be no or minimal
> additional label advertisments on a routing change. I merely query my IGP
> and select the best label.
> 
> Now I have the potential of requiring a refresh of MTU size on those
> advertisments I already have, which is a lot of transactions I would not
> normally have received. And further, I may not care as the new MTU may still
> exceed my service requirement.
> 
> I discussed the problem with a few people and in general observed/concluded:
> 
> - stuff in general punts today (note Martini/kompella L2VPN caveats)
> - I only really care if the MTU drops below my service requirement (or
> whatever Ive picked as my network MTU). I don;t want a lot of messages
> telling me the MTU changed from "humungous value x" to "humungous value y"
> - adding MTU to CSPF is overkill
> 
> and stuff considered was:
> - an LDP notification of packet discard occurring, e.g. only radiate out an
> MTU advertisment when it's a problem.
> 
> Somthing not entirely satisfactory as stuff is breaking before you know to
> fix it.
> 
> So to me a real solution is your advertisment, coupled with some means of
> establishing a network wide cut off value (above which no-one cares and
> changes will not be radiated). Section 2.2 partially addresses this, but I
> am still going to generate a load of messages as FECs are incrementally
> discovered (and potentially new lowest values are found).  Again with no
> real data to back me up, I suspect the network will naturally converge on
> the lowest MTU available, which I could have saved a lot of time and
> messages by merely set all ingresses to fragement to that value anyway. IMHO
> I may force a lot of unnecessary framentation with this approach.
> 
> So I think this is a corner case problem, and network scalability could be
> enhannced if the MTU advertisment was only generated if the path MTU dropped
> below some provisioned value.
> 
> cheers
> Dave
> 
> 
> 
> > -----Original Message-----
> > From: Ben Black [mailto:ben@layer8.net]
> > Sent: Thursday, November 08, 2001 9:02 PM
> > To: mpls@UU.NET
> > Subject: Updated MTU Signalling Extensions for LDP
> > 
> > 
> > This has been submitted, but not yet posted.
> > 
> > http://www.layer8.net/~ben/drafts/draft-black-ldp-mtu-extensio
> > ns-01.txt
> > 
> > I've integrated a number of suggested changes from the original (now
> > expired) version.  Please comment as appropriate so this draft can be
> > moved ahead.
> > 
> > 
> > Ben
> > 
> >