Subject: RE: PPP over Sonet default MRU

From: Stephane St Hilaire <[email-masked]>
Date: Thu, 23 Jan 2003 16:56:49 -0500

> 
> > 
> > Actually when I say "it's so", I'm really saying "I want it 
> so", I could
> > easily be wrong. 
> > When I'm configuring my MTU I am in NO WAY affecting the 
> actual MRU of the
> > other system. Is that clearer ?
> 
> Sure.  But if you say that it's so, then you have to be right.

You don't really have to be right, the sytem can still work even if you're
wrong, as mentionned earlier you could when discovering that the remote MRU
is lower then your configured MTU, log something and lower your MTU to the
discovered value, this is not the same as voltage or clocking. There are no
voltage negociation protocols. There also is no such thing as a "universal"
known default value for stuff like voltage and clocking options, whereas for
PPP there is a default and by definition all PPP compliant equipment must AT
LEAST support/work with the default values.

> 	2. you don't implement that option at all, just reject it as
>            unrecognized (LCP Configure-Reject), and use some
>            configured value.

The ability to receive/understand the MRU option in LCP is not optional (the
option negociation scheme is extensible but the MRU is not an extension to
LCP). What IS optional is sending MRU information to your peer. Knowing full
well that if you don't they will assume you only support the default 1500
value. If you don't like the received MRU you should send a NACK (it's too
low for your MTU for example). Sending a reject would mean; I don't
implement this "MRU feature". What would that mean anyway ?

> It's not different from what you have to do if the peer sends IPCP
> Configure-Reject for your IP-Address option.  You have to make a
> choice: plow on with whatever configured addresses you might have, or
> shut the link down and call for help.  It's mostly a policy decision.

There is no default value for IP addresses for IPCP (how could there be...).
This is quite another story.

> I think you might have misunderstood what I wrote.
> 
> If, in a given implementation, there's never a possibility of being in
> a position of having to transmit an IPv4 datagram that is larger than
> the link MTU, then it's certainly the case that you'll never have to
> fragment anything.  If you never have to fragment, then you don't have
> to bother implementing fragmentation.  Nobody can tell whether or not
> you implement features that you don't ever have occasion to use.

I see your point but it's not a very likely situation. I don't see a router
removing all possibility of configuring interfaces MTU by design just to
avoid the possibility of fragmentation. 

Steph

---

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

> LEAST support/work with the default values.

I think you're missing the point here.  If you explicitly configure
the MTU *AND* you're not willing to listen to what the peer says about
his MRU, *THEN* you will indeed encounter breakage when the peer's MRU
is less than what you configured.  Large packets just won't go
through, and there'll be no notification of this fact.  This is not
all that much different from picking the wrong clock sources and
having a 200ppm drift -- it'll sometimes appear to sort of work
(especially with small packets), and other times not.

(For what it's worth, it might indeed be possible to write a suitable
protocol based on FDL to negotiate a lot of those "necessary"
parameters.  The fact that this isn't there is the same sort of
problem that PPP addresses in its own domain.)

(And many modern power supplies can handle wide voltage ranges and
adapt.  Those that can't are sort of like PPP implementations that
don't bother to go to the trouble of implementing the useful options.)

> LCP).

I think that's at odds both with RFC 1661:

6.  LCP Configuration Options
[...]
   Design Philosophy

      The options indicate additional capabilities or requirements of
      the implementation that is requesting the option.  An
      implementation which does not understand any option SHOULD
      interoperate with one which implements every option.

... and with existing practice.  There are quite a few implementations
that don't bother implementing every option listed in RFC 1661 (in
particular, Quality-Protocol is somewhat rare).  None are mandatory.

If you'd like to call those implementations non-conformant with RFC
1661, that's up to you, but it's irrelevant for interoperability.

> What IS optional is sending MRU information to your peer. Knowing full

It means "I don't support negotiation of your MRU (my MTU); you'll
have to live with whatever the default might be, or whatever your
local configuration tells you to do."

It's the same as with all PPP options.  If the peer refuses to play
the game, then you have to fall back on the information that you
already know, or simply shut down the link.  Which one you pick is
purely a matter of local policy.

> This is quite another story.

In practice there often is -- the implementation often has external
information (explicit interface configuration or the result of an
authentication database query, for example) that give any necessary IP
addresses.  Or, perhaps, it's happy to run without them at IPCP time,
and then rely on BOOTP or DHCP over UDP/IP to establish addressing.
(Yes, quite a few vendors do actually support that.)

Obviously, the RFC can't specify a default.  That's not the same thing
as saying that there *is* no default.

The story isn't different, and that's just the point.  If the peer
refuses to negotiate, then that's *ALL* that you know.  He's refusing
to negotiate, so you can assume what you want to, constrained only by
the goal of interoperability.

Basically, if you had a PPP implementation that refused *all*
configuration options, that would be perfectly legal.  It would then
be functionally identical (in most respects; except for the CRC) to
SLIP in operation -- all parameters must be configured explicitly at
both ends, and life as we know it ceases if you happen to get any of
them wrong.

That, once again, was the very reason for developing option
negotiation in PPP.  Configuring both ends correctly is hard.  Having
the two ends validate and perhaps amend that configuration such that
the link is usable is better.

> avoid the possibility of fragmentation. 

I think you might be underestimating the perversity of nature.  ;-}

I'm not claiming that's what's going on with either of these vendors,
but it's certainly not an impossible situation.

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