Subject: RE: PPP over Sonet default MRU

From: Stephane St Hilaire <[email-masked]>
Date: Thu, 23 Jan 2003 11:17:12 -0500

> From: James Carlson [mailto:[email-masked]]
> Sent: Thursday, January 23, 2003 10:48 AM
> To: Stephane St Hilaire
> Cc: Ietf-Ppp (E-mail)
> Subject: RE: PPP over Sonet default MRU
> 

> Exactly.  However, you're still allowed to have the MRU configured
> manually to some other value at both ends, and you don't *have* to
> negotiate it.

It's more frequent to see configuration commands to set the MTU than the
MRU. At least that's what I've seen. And I don't think that by configuring
one MTU, the other side's MRU would be in any way affected. I mean that I
wouldn't necessarily equate configuring one side's MTU with configuring the
other's MRU (which will remain unaffected no matter what commands I enter on
the other equipment). 

Here's another question.
Let's say router A has an MRU of 10K and a manually configured MTU of 4K and
that router B has a MRU of 2K (which it does send during LCP negotiations).
Is it "acceptable" for router A to send frames bigger than 2 K just because
it is configured to do so ?  I would tend to say no.

> 
> Conflating "unnumbered mode" operation with IPCP negotiation is an
> implementation error, in my opinion.

Probably. I just didn't want to go into discussing IPCP at this time and
focus on the MRU "issue". 

> 
> The "manual configuration" could be as simple as an implementation
> constant in my view.  

Here I don't agree entirely. I do see a difference between something that is
manually configured (operator intervention) and a "hard coded" default
setting. 

> In order to do that, I think you should document
> the system usage something like this: "this equipment will fail to
> operate properly if the peer doesn't support an MRU of at least 4470
> octets; sorry about that."

You could always dynamically lower your MTU to the other side's MRU, when it
is discovered. 

> That's why PPP added negotiation of these things; to avoid requiring
> everyone to synchronize their knobs and implementation constants
> throughout the universe.  It's much better when peers negotiate rather
> than making assumptions.  See RFC 1547 section 2.9 (as well as most of
> section 4).

Well of course that's exactly right, I'm still at a loss to know why an
implementation supporting a larger MRU than 1500 (when the exact value
actually varies from one product line to another) wouldn't send that
information to it's peer. Is the other end supposed to guess or use some
sort of PPP ESP-Extensions ?

Steph

---

From: James Carlson <[email-masked]>
Date: Thu, 23 Jan 2003 11:43:23 -0500

Stephane St Hilaire writes:
> MRU.

It depends on the implementation.  Some implementations (e.g., CMU/ANU
ppp) have controls for both.

> At least that's what I've seen. And I don't think that by configuring
> one MTU, the other side's MRU would be in any way affected.

I don't think I understand that.  If you *set* the MTU, then you're
explicitly telling your system that the peer's MRU is at least that
large.  If you say it's so, then it must be so.

What else could that possibly mean?

> I mean that I

That's the whole point of implementing negotiation.  Negotiation is a
good thing.  It allows you to detect cases where the two
configurations are in conflict and (in some cases) recover from the
problem.

The fact that one or more vendors didn't implement useful negotiation
features is a problem to take up with those vendors.  ("Dear Vendor:
Please consider implementing this useful feature from RFC 1661 ...")

> it is configured to do so ?  I would tend to say no.

That's a configuration error.  The administrator failed in setting it
up incorrectly, and the implementations are lacking for failing to
provide helpful negotiation to detect the problem.

> focus on the MRU "issue". 

That's fine.  I was just pointing out that the issue is much broader
and more generic: PPP allows you to negotiate things that were (in
prior protocols) explicitly manually configured on both ends of a
link.  PPP doesn't *require* you to do that negotiation (which is why
they're "options"), but it's obviously a very good thing to do so, and
usually requires really good justification to avoid it.

For example, some implementations fail to implement the LCP Magic
Number option.  This is clearly a Very Bad Thing because it allows
looped-back interfaces to become established, and because implementing
the option is no skin off anyone's nose: you don't need any additional
hardware support to do it.  However, it's still an option, and vendors
are free to make implementation mistakes.

> manually configured (operator intervention) and a "hard coded" default

From the perspective of the protocol, I don't.  You either get the
information from negotiation (the peer tells you its MRU, which then
becomes a limit on the MTU that you may use), or you get it through
some authoritative "external" mechanism.  The protocol doesn't (and
can't) care where that external mechanism gets its information -- the
protocol knows nothing of user interfaces, #defines, or other such
matters.  That's an implementation matter.

> You could always dynamically lower your MTU to the other side's MRU, when it

Assuming your implementation actually is capable of doing that, then,
yes, I agree that this is the best choice.  I can imagine
implementations that might not be able to do this -- e.g., ones that
don't bother supporting IPv4 fragmentation and thus fix the MTU to be
equal to the maximum MRU supported on any other interface.  Obviously,
those implementations should still negotiate the value; they'd just
have to fail to bring up the link if the peer's MRU is too small.
(Which is exactly the intent of the option; preventing broken
configurations.)

> sort of PPP ESP-Extensions ?

If you don't implement an option, then human intervention of some kind
is required to handle that feature.  If it's a fixed MRU or MTU, then
the human will have to read the supplied documentation to determine if
the link will work.

It's out of PPP's hands at that point.  There's no way (or reason) to
"require" the implementation of features that vendors don't want to
implement, at least not by way of the IETF.

-- 
James Carlson, Solaris Networking         <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677