The MPLS WG Archive

[Ben Black <ben@layer8.net>]

Cisco unpacks the IP datagrams, then processes them?  Ouch.  It appears
I was optimistically misinformed.


ben

On Thu, Dec 14, 2000 at 03:19:27PM -0500, Dan Tappan wrote:
> At 11:06 AM 12/14/00 -0800, 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.
> 
> 
> I can't speak authoritatively for Juniper, but this is a false statement as 
> far as Cisco.
> 
> 
> >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
> > > > > >
> > > > > >
> > >
> > >