Subject: Re: strange boundary cases in RFC 1990 (Multilink)

From: [email-masked] (Vernon Schryver)
Date: Mon, 12 Jan 1998 21:48:13 -0700

> From: Archie Cobbs <[email-masked]>

> ...
> > Also, what if you will never have more than one link the bundle but
> > want the sequencing or fragmentation provided by RFC 1990.
> 
> Is this case really worth the trouble? I've never heard of anyone doing
> that, but there may be a good reason to. Care to elaborate?

In theory, you might solve problems caused by the 1500 LCP MRU limitiation
with PPP extension protocols that otherwise push you past 1500.
Examples are encryption, bridging, and some flavors of CCP.
I do not know if anyone has actually done this.  Other, direct ways of
dealing with such problems seem easier, but the notion has been
mentioned.

The sequence numbers of RFC 1990 MP could be used to detect lost
packets for encryption or compression without the CCP reset-request
mechanism.  Again, I don't know if anyone has actually done such a
thing.

Also, wasn't there some talk of using RFC 1990 sequence numbers for
something in initial iterations of L2TP?  I think those ideas were not
seriously considered or at least did not survive.

Vernon Schryver,  [email-masked]

---

From: [email-masked] (Jonathan Goodchild)
Date: Wed, 14 Jan 1998 14:09:38 +0000

Archie Cobbs writes:
     
>> But, we need to define what it means to have Multilink on in one
>> direction only.  Is it indeed the intent that any Multilink in either 
>> direction makes all links one entity at the Network layer?  
>> Consensus?
>
> The only thing I can see single-direction multi-link meaning is this: 
>
>    Everything is exactly the same as normal multi-link, except 
>    that in one direction you don't send any fragmented packets, 
>    instead sending only normal packets over either link (perhaps 
>    load balancing). You still have a single bundle.
>
> However, taking it to mean this would probably be incompatible with 
> some or most existing implementations.
     
I agree.
     
> Question for MP implementors out there: what do you do if you 
> receive a config-reject of your MRRU, but you have already 
> config-ack'd the peer's MRRU?
     
I assume that the link isn't part of any multilink bundle.
     
However, if my MRRU is config-ack'd by the peer, but the peer doesn't 
include MRRU in its own Config-req, I assume that the link is part of 
a multilink bundle.  Looking at it now, I see that this is 
inconsistent.
     
Frankly, I think single-direction multilink should be outlawed.
     
---
Jonathan Goodchild

---

From: [email-masked] (Vernon Schryver)
Date: Wed, 14 Jan 1998 10:26:30 -0700

> > direction makes all links one entity at the Network layer?  Consensus?

As I said before, it makes theoretical sense.  I don't think it is
useful, and it should probably be outlawed lest people be confused.

>   Everything is exactly the same as normal multi-link, except that
>   in one direction you don't send any fragmented packets, instead
>   sending only normal packets over either link (perhaps load
>   balancing). You still have a single bundle.

Exactly.  That i valid view, although it does have the unnecessary
restriction or assumption that an MP bundle contains 2 instead of 1, 3,
4, 5 or some other number of links.

I agree.

> Question for MP implementors out there: what do you do if you receive
> a config-reject of your MRRU, but you have already config-ack'd the
> peer's MRRU?

Don't use MP.