Subject: RE: PPP over Sonet default MRU

From: Stephane St Hilaire <[email-masked]>
Date: Thu, 23 Jan 2003 10:26:41 -0500

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> Sent: Thursday, January 23, 2003 8:05 AM
> To: Stephane St Hilaire
> Cc: Ietf-Ppp (E-mail)
> Subject: Re: PPP over Sonet default MRU
> 
> 
> I think it's just a configured MRU.  There's nothing wrong with a
> configured (or even fixed) MRU.  

I understand that. The MRU will most likely be fixed and may be due to some
hardware constraint or foreseeable usage limit (and will in most case go
beyond 4470 and reach around ~9K).

> RFC 1661 PPP provides the advantage
> that the peers *can* negotiate the value on each end, providing very
> helpful diagnostic capabilities, but there's no requirement that
> anyone ever implement any of the options.  (That said, failing to
> implement useful options seems like a rather poor choice to me.)

I agree about the choice but my interpretation of the following excerpt:

"The maximum length for the Information field, including Padding,
      but not including the Protocol field, is termed the Maximum
      Receive Unit (MRU), which defaults to 1500 octets.  By
      negotiation, consenting PPP implementations may use other values
      for the MRU."

Is that unless you receive MRU information from the other end, you have to
assume that it can only receive up to 1500. One thing that is certain, is
that by definition all implementations will discard input frames larger then
the MRU, so if you don't tell the other end what your MRU is (and it isn't
1500), the other end has no way of knowing just how big a frame it can send
(beyond 1500).

> It's the same way with IP addresses: it's a very good idea to
> negotiate the endpoint addresses (even if they're not distinct from
> the addresses uses by other links) in order to avoid configuration
> errors.  There's no requirement that anyone do so.

That's true but IP addresses are slightly less critical/mandatory
connectivity wise (you could work in unnumbered mode) then an interface's
MRU in my opinion.

> 
> If the Cisco side doesn't have its MTU specifically tuned to 4470, and
> it's sending packets larger than 1500 octets, then I'd worry about
> it.  

As far as I know, NO configuration work is required by the operator, Cisco
routers (or I should say the one we're testing with) is just using it's
default MTU and sending out packets up to that MTU.

Thanks for the reply.

Steph

---

From: James Carlson <[email-masked]>
Date: Thu, 23 Jan 2003 10:48:13 -0500

Stephane St Hilaire writes:
> assume that it can only receive up to 1500.

Right; that's what it says.

> One thing that is certain, is

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.

What the text is saying is that if you have *NO* other information
about the peer's capabilities, then you are permitted to assume that
it supports at least the required 1500 octet minimum.  Of course, if
you have some sort of external configuration that tells you what the
peer's MRU actually is, then you don't have to assume that at all.

> connectivity wise (you could work in unnumbered mode) then an interface's

I think that's a red herring.  Even in unnumbered mode, nodes that are
able to communicate with IP at all *must* have at least one valid IP
address.  That address can be used as the local address for IPCP
negotiation purposes, and doing that serves the goal of IPCP's
IP-Address option -- making sure that the link isn't misconfigured.

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

> default MTU and sending out packets up to that MTU.

The "manual configuration" could be as simple as an implementation
constant in my view.  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."

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

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