The MPLS WG Archive

[Dan Tappan <tappan@cisco.com>]

At 12:10 PM 12/14/00 -0800, Ben Black wrote:
>Cisco unpacks the IP datagrams, then processes them?


in the appropriate error handling case

>  Ouch.  It appears
>I was optimistically misinformed.

Optimistic in what sense? Optimistic that Cisco would field an 
implementation which would break existing network functionality? Optimistic 
that someone else could get away with a broken implementation because they 
hoped Cisco/Juniper had?


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