The MPLS WG Archive

[Giles Heron <giles@packetexchange.net>]

Toby Smith wrote:
> 
> Giles Heron <giles@packetexchange.net> writes:
> 
> > > Hi,
> > >
> > > Are you sure about this last bit?  If one LSR has a configured MTU of
> > > 1400, and receives information from its peer for the same VC ID &
> > > interface type, but with an advertised MTU of 1500, I would think that
> > > this situation would be better served by maintaining the received
> > > mapping and relaying this status to the local user, who has a better
> > > chance of configuring the local interface to a matching MTU (or fixing
> > > things up on the remote side).
> > >
> > > If a release is sent instead, it then opens up the issue of having the
> > > LSR who issued the release later send a request for that mapping.
> > >
> > > Either that, or the remote LSR who receives the release from the local
> > > LSR now has enough information to pick a new MTU that might be more
> > > amenable to the LSR which sent the release.  But now we're talking
> > > about MTU negotiation, aren't we.
> >
> > exactly.
> 
> Excellent.  So, are you backing down from your statement about sending
> a release?  After all, you say:

I didn't say that ;-)

> > So we decided to depend on the SP managing to configure a matching MTU
> > size as well as VC ID and VC type at both ends...
> 
> ...which I think is the correct approach, and I think that's best
> served by simply maintaining the received mapping with the mismatched
> MTU and reconfiguring one of the boxes based on the information that
> the user can see in the sent & received label mappings show commands,
> instead of having an LSR send a release as soon as it receives a
> mapping with an MTU it doesn't expect, and then having to figure out a
> way to get the released mappings back again later.

but if you retain the received mapping then presumably the circuit will
start "working"?

Whereas if the circuit fails to come up the user will figure out that
something is wrong.  Hopefully when (s)he turns on debug there will be a
tell-tale message saying "MTU size mismatch".

There is, I believe, a precedent for this.  Doesn't OSPFv2 fail to
establish an adjacency unless the MTUs match?
 
> > In general I'd expect vendors to default the MTU to something sensible
> > for that encaps (e.g. 1500 for Ethernet, 1500 or 4470 for PPP, and so
> > on.)  So most of the time (assuming the SP has a core which can
> > transport this default MTU) no further action should be necessary from
> > the SP.
> 
> Hopefully, yeah.  :)
> 
> > I think I argued for putting default MTU values in the draft?  I can't
> > remember why we didn't put them in?
> 
> Seems like a good idea that might save someone the hassle of first
> discovering the defaults during some interop event.  :)

okay.  Let's poll the other authors to see what we get...

Giles

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================