Subject: RE: PPP over Sonet default MRU

From: Stephane St Hilaire <[email-masked]>
Date: Thu, 30 Jan 2003 11:16:59 -0500

> -----Original Message-----
> From: Dennis Ferguson [mailto:[email-masked]]
> Sent: Thursday, January 30, 2003 1:42 AM
> To: [email-masked]
> Cc: Ietf-Ppp (E-mail)
> Subject: Re: PPP over Sonet default MRU
> 
> 
> Stephane,
> 
> on the other end of the link was fine, but I think he misread the fact
> that there is no way to do this with PPP as specified.  This will be
> fixed shortly.

Now that's great news ! I'll have to work on being less cynical in the
future.
Could I get a target release version/date ? I might be pushing my luck a
little ...

> will cause you
> to drop your MTU on the circuit to 1500 with absolutely no 
> way to change
> it short of replacing the software on the box at the other 
> end (and then
> replacing the software of his neighbors, and so on).  This 
> was a deployment
> nightmare.

My idea was to have our local MTU adjust to the remote MRU (only if the
latter was lower) all the time when our local MTU had NOT been MANUALLY
configured (it's using the old 4470 default). However if our local MTU was
manually configured, in the case where the remote MRU was not provided
during LCP, we would have continued using our MTU even if above 1500. If we
DID get the remote MRU and it was lower than our configured MTU we would not
connect. The idea being that if the operator actually configured his MTU, he
*really* wants it and to adjust it to something less then he wants is not
necessarily desirable. If he wants this configuration to work he will have
to do some configuration work on the peer. I guess there are many ways to
solve this issue.

> 
> I think what I decided to do instead to relieve the deployment issue
> while getting as close to the behavior of the new standard 
> as possible,
> in an MTU-configuration-centric implementation, was to:
> 
> - Always send an MRU option, even if the value being sent was 1500
>   bytes, omitting it only to deal with a -Reject (the configured MTU
>   was the first choice for the MRU, the hardware maximum was sent to
>   respond to a -Nak).  Always sending the option ensured that the
>   new implementation would at least never end up confused talking to
>   itself, or anyone else which always sends the option.
> 
> - Take no received MRU option to mean, use the configured MTU.
>   Otherwise, if he sent an MRU, use the configured MTU for the active
>   MTU if the received MRU was greater than or equal to this, the
>   received MRU otherwise.
> 

In this do you see "configured MTU" has something different from the
"default interface MTU" ? 

> This appears to be approximately Cisco's behavior too, for whatever
> reason.  While I don't know their reason, if it is the same 

With Cisco we've even tried connecting using a MRU smaller than 4470 (2048
just to see what would happen). Basically we got a bunch of NACKs telling us
to raise our MRU to 4470 (raising our MRU is seen as more feasible then
lowering theirs...) until we finally receive a reject. We might assume that
this means they will now use the default of 1500 but we were still able to
send 4K pings from the Cisco to our box. Considering that the Cisco's MTU
wasn't *configured*, this appears a bit inflexible. 

We even have a router tester that when negociating his MRU at 4K will NACK
our MRU of ~9K. So we can receive packets larger then he'll ever send,
what's the problem ?

> 
> I'd also just point out that the view expressed here that PPP 
> should always
> negotiate MRUs (which is also the only way I can interpret RFC 1661
> if the end result is supposed to be other than 1500), and 
> that bad things
> will necessarily happen if PPP is ever allowed to let the link come up
> with an inconsistent MTU/MRU, is a bit PPP-myopic since there 

In some cases this won't cause a problem. If the MRUs on both sides is
greater than the MTU on both sides (which in fact is generally the case),
even if the MRUs are inconsistent OSPF can come up and so fourth. Perhaps if
there were an actual IP MTU negotiation option in IPCP all ambiguities would
go away. OSPF wouldn't even have to do MTU checks when running on a point to
point link. Just a silly/half baked idea, please no flames !

> that the MTUs in use are compatible and will fail to form an adjacency
> if they aren't, which prevents the circuit from ever being put to use
> even if PPP is up.  In this case it may have been preferable 
> to be able
> to have PPP not bother with MRU negotiation itself, if this were an
> option, since the problem will be caught regardless and it may be more
> convenient to have the circuit up when you need to fix it so 
> you can use
> it to log into the neighbour box and repair its faulty 
> configuration.  We

In general I myself would agree but we are seeing a lot of operators who
don't want to provide access to their router management via data/forwarding
links as opposed to network management specific interfaces. However that's
another story.

> 
> And to share one other surprising thing I just noticed, while Juniper
> has built quite a large number of HDLC over SONET interfaces, 
> and while
> I am aware of a big variety of equipment it has been connected to via
> these interfaces, there has never been a user-initiated bug report

Perhaps the bugs were sent to the "smaller" vendors (where the user will
feel, perhaps wrongly in this case, that he has more leverage), and they
adapted their side of the equation.

> concerning this behavior (it has be noticed internally a 
> bunch of times,
> though not fixed for hysterical reasons), even though it 

I thought we had a monopoly on those types of reasons (or did you mean
hystorical ?): )

> should be failing
> to interoperate with implementations strictly conforming to 
> RFC 1661 in
> an unfortunate way.  I have no idea whether this means the Cisco
> implementation of MRU negotiation is common, or whether it means the
> use of PPP on interfaces of this type is fairly uncommon, however.

I'd combine both and come up with: PPP on sonet may not be all that uncommon
but Cisco and Juniper perhaps *own* most of it ?
I'm not really sure.

Thanks a lot !

Steph