The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Dec> msg00238



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

MPLS and fragmentation...

  • From: Eric Gray <ewgray@mindspring.com>
  • Date: Thu, 14 Dec 2000 13:38:34 -0500
  • CC: "Andre N. Fredette" <fredette@photonex.com>, Serge Maskalik <serge@ivmg.net>, mpls@UU.NET

Ben,

        I disagree with your assertion that this is a good
reason to modify the LDP draft(s) before they become
RFCs.

        No one has shown compelling evidence that MTU
sizes will result in a need for additional fragmentation.
No one has shown a really good reason why IP MTU
size discovery will not be sufficient.  I do not believe that
we need to iron out every scenario that _might_ arise in
order to move an IETF protocol specification to proposed
standard.

Ben Black wrote:

> On Wed, Dec 13, 2000 at 01:38:45PM -0500, Andre N. Fredette wrote:
> > LDP, and therefore CR-LDP, does not provide an LSP MTU discovery
> > mechanism.  The thinking (perhaps flawed) was that:
> >
> > (a) Fragmentation is not usually an issue in the core of the network due to
> > the large MTUs on typical interfaces, and
> >
> > (b) If it is an issue in a particular domain, the MTU can be configured on
> > the MPLS edge routers.  Note, I am aware that this is somewhat problematic
> > because the MTU is not necessarily related to the local router, but is the
> > minimum of all MTUs in the MPLS domain.
> >
>
> It is exactly for reason (b) above that this must be in the draft (one
> would hope before they move to RFCs).  Although it is often the case that
> the core MTU is larger than the edge MTU, this is not always the case
> and may not stay the case (for example, consider jumbo frames from gigabit
> ethernet edge devices pushing packets which must be sent across POS links
> with an MTU half the size (9216 vs 4470).  I am rather surprised that
> this issue was not raised earlier, but now that it has been, it should
> be addressed promptly.
>
> ben