The MPLS WG Archive

[Ben Black <ben@layer8.net>]

Doing anything but silently discarding would require either a change
to draft-ietf-mpls-label-encaps-08.txt or taking the slow path through
the LSR.  Note that RSVP now has 2 mechanisms for reporting path MTU.
This is not a new idea.  

Quite simply, PMTUD is _easily_ broken without an MTU reporting mechanism,
and since LDP is a protocol for IP, it should support fundamental IP
requirements.


ben

On Thu, Dec 14, 2000 at 02:34:54PM -0500, Eric Gray wrote:
> Ben,
> 
>     That would seem to indicate that either it is
> not a problem for them, or it is an opportunity
> for everyone else.  :-)
> 
>     If the major market leaders do not feel that
> it is necessary to support one mechanism to do
> MTU discovery, what is to make anyone feel
> that they will support a new one?
> 
> --
> Eric
> 
> Ben Black wrote:
> 
> > PMTUD as described in RFC 1191 requires intermediate LSRs to 1) have
> > the ability to generate an ICMP packet back to the source of the packet
> > needing fragmentation and 2) not be configured to silently drop packets
> > that are too big.  Current popular LSRs from Cisco and Juniper will
> > silently drop packets which are too big.  This breaks RFC 1191 PMTUD.
> >
> > ben
> >
> > On Thu, Dec 14, 2000 at 02:10:56PM -0500, Eric Gray wrote:
> > > Ben,
> > >
> > >     Oops!  RFC 1191, 11/1990.  Numerical alliteration error...
> > >
> > > --
> > > Eric
> > >
> > > Eric Gray wrote:
> > >
> > > > Ben,
> > > >
> > > >     RFC 1991, November, 1990.
> > > >
> > > > Ben Black wrote:
> > > >
> > > > > To which IP MTU size discovery mechanism are you referring?
> > > > >
> > > > > ben
> > > > >
> > > > > On Thu, Dec 14, 2000 at 01:38:34PM -0500, Eric Gray wrote:
> > > > > > 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
> > > > > >
> > > > > >
> > >
> > >
> >
> > --
> > what great thing would you attempt if you knew you could not fail?
> 
> 

-- 
what great thing would you attempt if you knew you could not fail?