Subject: RE: PPP over Sonet default MRU

From: Stephane St Hilaire <[email-masked]>
Date: Thu, 23 Jan 2003 13:13:54 -0500

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> 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.
> 

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 ?

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

I was going for a yes or no answer ; ). Configuration errors will occur no
matter what. I'm just saying should router A disregard the MRU information
it got from it's peer and still send according to it's configured MTU ? I
don't expect that would actually work very well.

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

I guess this is where you answered my previous question.

> or you get it through
> some authoritative "external" mechanism. 

If you get diverging information which should take precedence ? The locally
configured MTU or the ACTUAL MRU learned when bringing up the link ? I'm
inclining towards the latter, what is your opinon ?

> > You could always dynamically lower your MTU to the other 
> side's MRU, when it
> > is discovered. 
> 
> 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

Fragmentation is not an optionnal feature, at least for a IP V4 router (you
may be talking about another type of equipment). Though I can imagine
implementations that couldn't be bothered with the IETF and RFCs in general.

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

If you really meant: There's no way (or reason) to
 "require" the implementation of OPTIONAL features that vendors don't want
to
 implement, at least not by way of the IETF". Then I agree entirely. If not,
then even though there may be no WAY, I can think of lots of REASONS to do
so. 

Steph

---

From: James Carlson <[email-masked]>
Date: Thu, 23 Jan 2003 14:03:40 -0500

> other system. Is that clearer ?

Sure.  But if you say that it's so, then you have to be right.

It's like setting the clocking options on a T1 link.  You have to be
right.  If you're not, then it just won't work right.  Or like setting
that "115/230" switch on the back of the router.  You'll eventually
know if you got it wrong.

> don't expect that would actually work very well.

If you actually get an MRU option from your peer, then one of three
things can happen (ultimately; when the dust of negotiation settles):

	1. you agree to the peer's MRU -- this becomes a bound on the
           MTU that you can possibly use on the link.

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

	3. you determine through negotiation that the peer doesn't
           have an MRU that you like and that you can't fix it, so you
           shut down the link and call for human intervention.

Cases (1) and (3) are the good ones -- that's what negotiation is
supposed to do for you.  Case (2) is bad, but it's just the nature of
options rather than requirements.  (Of course, there's a subcase to 2
-- the peer could also shut down the link if it feels that you're
being unreasonable.)

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.

> inclining towards the latter, what is your opinon ?

It depends.

If you do recognize the option (i.e, you implement the LCP MRU
option), *and*  you return LCP Configure-Ack for that value, *then*
you're compelled to use an MTU that's no larger than the MRU
advertised by your peer.

None of those two preconditions (recognizing the option, and returning
Configure-Ack) are required.

> implementations that couldn't be bothered with the IETF and RFCs in general.

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.

In the scenario I suggest, if you have a link whose MTU (including any
optional encapsulation you might support) is at least as large as the
largest MRU on any link on your system, then there's no way you could
ever be in a position where you'd have to fragment anything that you
would forward onto that link.

I can imagine that some implementations of "high speed" interfaces
(for some definition of "high") might opt to avoid fragmentation.  I'm
not saying that it's necessarily goodness; merely that it's possible.

> then even though there may be no WAY, I can think of lots of REASONS to do

Sure.  That comes down to "quality of implementation."

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