The MPLS WG Archive

[Giles Heron <giles@packetexchange.net>]

Toby Smith wrote:
> 
> Giles Heron <giles@packetexchange.net> writes:
> 
> > Narasimha Swamy wrote:
> > >
> > > Hi,
> > > In case of L2VPN sessions configuration, it is possible for an edge LSR to
> > > receive unmatched MTU or vc-type from other edge LSR for a particular l2vpn
> > > session.
> >
> > By L2VPN here do you mean draft-martini?
> >
> > If so then yes - it is possible for the edge LSR to receive unmatched
> > MTU or vc-type from the peer edge LSR.
> >
> > > What type of message should be sent in this case to indicate this error. If
> > > notification message is sent, what will be the Status Code.
> >
> > A label release should be sent.
> 
> 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.

And from my memory of the discussion I think we decided to try and avoid
getting into negotiation for this parameter.

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

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.

I think I argued for putting default MTU values in the draft?  I can't
remember why we didn't put them in?

Giles

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