Subject: Re: An MP alternative

From: Vernon Schryver <[email-masked]>
Date: Fri, 17 Apr 1998 11:03:41 -0600 (MDT)

> From: James Carlson <[email-masked]>

> > Personally, the only error detecting I see from using MP negotiations is
> > mis-matched MRU's, and I don't see a problem there.
>
> Mismatched paths (over SONET/SDH infrastructure) or misidentified
> peers can be far more hazardous.  As are links where the peer IP
> address is not what was expected.  IPCP nicely handles the latter
> checks, and MP nicely specifies that there be only *one* IPCP
> negotiation session per bundle, which simplifies the error cases.

Yes, IPCP deals with IP address confusion.

You don't need MP to require the administrative restriction of having only
one set of state IP machines per bundle.  You could instead do separate
IPCP negotiations on each link, and administratively require them to have
the same answers, or in other words, use the redundant IPCP config-requests
and -acks as confirmation that the peers agree.  Isn't that what everyone's
BF&I Multilink implementations have done for years?

> >  Why not let the peers
> > bring up links with varying MRUs?  So what if you have 3 links with 9K
> > MRU's and one link with 256?  You'd just do the obvious, wouldn't
> > you?
>
> The "obvious" is not so obvious when the implementation is in
> hardware.  Knowing how and when to fragment (calculate MIN(link-MTU)?)
> depending on when the link is chosen is one part of the problem.  The
> other part of the problem is that mismatched MRU/MTUs among links may
> well be configuration errors.

I guess 'obvious' is in the eye of the beholder.  What's obvious to me is
"never fragment, and put big packets in queues with big enough MTU's".

> > There is nothing except the MRU that the MP negotiation can protect, is
> > there?
>
> IPCP peer addresses.

I think the several interoperable, commercial BF&I Multlink
implemementations require a single pair of IP addresses for the whole
bundle, and manage that restriction without RFC 1717/1990.  When my code
detects inconsistent MRU's, MTU'S, MRRU's, MTRU's, or certain other
parameters, it puts a snooty message in the log and an LCP
Terminate-Request.

> > You might use end-point discriminators to ensure that the peers know
> > that they are doing BF&I.
>
> Yes; that's essentially the point here.  I could have written an I-D
> which says just that, but then it begs a number of questions, such as
> what to do in any error cases.  I believe a tighter description of the
> usage is needed.

I guess it wouldn't hurt to ensure that obvious stuff is written down.

> > I think you need more words than what I think are in your draft to avoid
> > confusion among computers, implementors, and users. ...

> All of the data is "outside the scope" in the old sense.  None of it
> is sent with MP headers at all.  None of it is sequenced or reordered.
>
> If this option is chosen, there's only one way to send data and
> negotiate per this I-D.  The old in-or-out-of-MP ambiguity doesn't
> exist.

But that wasn't entirely clear to me, which seems to mandate some
more or different words.

vjs

---

From: James Carlson <[email-masked]>
Date: Fri, 17 Apr 1998 14:00:37 -0400

> BF&I Multilink implementations have done for years?

Yes, but, again, only by convention and by administrative
intervention, not by standard and not by negotiation.

> "never fragment, and put big packets in queues with big enough MTU's".

Unless, of course, the point that does the distribution among links is
before a switch fabric where it is impractical to have yet another
table with all of the MTUs.  Unless, of course, such redistribution
would violate assumptions (or guarantees) about message reordering.

This is why standardization is a reasonable thing.  It's not
necessarily the case that two implementors of good faith will always
choose the same 'obvious' solution.

> parameters, it puts a snooty message in the log and an LCP

You're doing it right.  But there's no *document* that says you're
doing it right.  Should we decide to interoperate, it would be nice to
have a bit of paper that says what we think we've agreed to do, no?

> But that wasn't entirely clear to me, which seems to mandate some

I noticed that this was a problem, and I *think* I've corrected this
in the version of the draft I sent out today.  If not, it would
probably be helpful to know where the reader stumbles.

-- 
James Carlson, Consulting S/W Engineer  <[email-masked]>
IronBridge Networks / 55 Hayden Avenue  71.246W    Vox:  +1 781 402 8032
Lexington MA  02173-7999 / USA          42.423N    Fax:  +1 781 402 8092
"PPP Design and Debugging" ------- http://id.wing.net/People/carlson/ppp