The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Nov> msg00075



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Updated MTU Signalling Extensions for LDP

  • From: "David Allan" <dallan@nortelnetworks.com>
  • Date: Fri, 9 Nov 2001 09:37:51 -0500
  • X-Orig: <dallan@americasm01.nt.com>

Title: RE: Updated MTU Signalling Extensions for LDP

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