Subject: Re: An update to LBD

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

> > > > 2.  No-Fragmentation Configuration Option Format
> > > 
> > > >                                ... Implementations MUST NOT Configure-
> > > >    Nak this option.
> > > 
> > > Why not Configure-Nak for it?
> > 
> > It's a boolean, like short sequence numbers.  Except for an unsolicted
> > Nak, there's nothing that can be hinted here.  Either the peer
> > implements it, or it doesn't.  Allowing a general Nak doesn't make
> > much sense.
>
> I agree, there seems little point in including this in an unsolicited
> NAK.  It would mean "I want you to tell me not to fragment".  If you
> don't want to fragment, you don't have to, you don't need to tell the
> peer to force you not to.

Ok, but what about the no-MP-header option?  If you insist on not spending
cycles sending the MP header, how do you convey to the peer that is why
you are refusing to run?

On the other hand, if John Carlson's system is prepared to send MP headers
in its high speed mode, then a case can be made that this whole proposal
is unneeded.  What if these systems would negotiate MP the old fashioned
way, and then just use the RFC 1990 permission to send IP packets without
MP headers?  And route any incoming packets bearing MP headers via the
extremely super slow path?  And go slowly if any of the MRUs of the links
differ?  That way
  - a pair of his systems would go fast, just as is the case with
       the proposed PPP extension.
  - a pair would be protected from errors and so forth by the MP
       negotiation, just as with the proposal.
  - one of his systems would interoperate with any other MP system, albeit
      slowly, just as is the case with the proposal. 
  - since LCP and other non-IP packets are extremely rare and surely
      treated as very special cases in an extremely super-slow path
      (relatively speaking), it does not matter if they have MP headers
      or not.
  - no new RFC's would be required 
  - real life operational experience could be obtained before setting   
      the idea in standards concrete.  It is extremely difficult to change
      a protocol after it has been given a number.  You can hardly do
      anything except make a whole new option.

Note that I'm not talking about ordinary BF&I multilink, but the words
in RFC 1990 about not including MP headers.  Yes, I realize that
only a matter of hours ago I claimed that some systems probably don't
like missing MP headers; Let 'em be fixed. 

Vernon Schryver    [email-masked]