Subject: Re: Usage of ML Endpoint Discriminator Option

From: Vernon Schryver <[email-masked]>
Date: Wed, 25 Aug 1999 09:04:30 -0600 (MDT)

> From: "John R. Martz" <[email-masked]>

> The "default bundle" scenario makes me nervous. I'm not sure it's something my customers would
> really want chosen for them as the default. I'm considering limiting my implementation to not allow
> scenario (1) multilink unless a customer explicitly manually configures to allow it. Perhaps
> something like a "Require remote link identification to enable multlink" checkbox. The default would
> be to have this "checked" and the customer would have to uncheck it to get scenario (1) behavior.

What is "scenario (1) behavior"?

It makes perfect sense to always have a default MP bundle, even when MP
is explicitly not configured (e.g. MRRU never seen or Configure-Rejected)
To make that point another way, some common MP implementations do not use
MP headers when there is only a single link in the bundle (subject to the
cautions in RFC 1990, which were added explicitly for such
implementations).

Another consideration is that RFC 1990 is not the only PPP multilink
protocol.   RFC 1990 is the only IETF official protocol, but the far older
"load sharing," "round-robin," or "BF&I" tactic is still around.  That
tactic consists of simply running 2 or more parallel PPP links with the
same IP addresses at both ends and doing the obvious with IP packets.
The Endpoint Discriminator is a handy way to distinquish those old style
bundle from RFC 1990 bundles.

> My impression is this is a valid RFC 1990 compliant implementation choice. Anyone disagree?

An implementaor can disable most PPP features.

> Clara's ideas about using the called or calling phone numbers to limit the scope of a "default
> bundle" are interesting alternatives too.

I doubt that would be useful in many situations.
When you establish a second phone call, don't you usually have a
new calling phone number (or CID or ANI)?  If so, the called PPP peer cannot
always use calling phone numbers to label the MP link.
Don't you sometimes have different called phone numbers?   If so, you
can't always use the called numbers.

Note that one of the official types of Endpoint Discriminator is a
telephone nuymber.  If you can pick a single phone number, then you can
also use it with Endpoint Discriminators.

When I don't have Endpoint Discriminators, I like to identify the MP
bundle by the IP address at the far end.  In fact, I like to make
the remote IP address the primary identification of the bundle, since
you always have a remote IP address, but many not have other info.
The trouble with that idea is that with some configurations, you do not
discover the remote IP address until inconveniently late.

Vernon Schryver    [email-masked]

---

From: James Carlson <[email-masked]>
Date: 25 Aug 1999 13:45:55 -0400

> What is "scenario (1) behavior"?

Scenario 1 from RFC 1990:

   (1)  No authentication, no discriminator:
        All new links MUST be joined to one bundle, unless
        there is manual configuration to the contrary.
        It is also permissible to have more than one manually
        configured bundle connecting two given systems.

> It makes perfect sense to always have a default MP bundle, even when MP

Right; though I think you're making a very different point.  John
Martz's message was questioning the utility (or security, perhaps) of
allowing all unauthenticated, no-ED links to join into a single,
implementation-wide "default" bundle.

You are right that having a default MP bundle for a clearly identified
*separate* link (not a default implementation-wide) is probably a good
implementation choice, but I don't think that was the issue.

> bundle from RFC 1990 bundles.

Um, I don't think so.  MRRU distinguishes RFC 1990 from BF&I bundles.
ED itself might be a nice thing to have around for BF&I ...

> bundle by the IP address at the far end.

For configuration management and SNMP interfaces, that probably makes
sense.

I can't make sense out of that for an MP implementation, though.  You
don't have the IP address on subsequent links that should join the
bundle since you won't be going through IPCP again on those links.
The only data you have around when you must make the decision to join
a bundle "already in progress" (as they say) or create a new one is
from LCP and authentication.  Right?

-- 
James Carlson, System Architect                     <[email-masked]>
IronBridge Networks / 55 Hayden Avenue   71.246W   Vox:  +1 781 372 8132
Lexington MA  02421-7996 / USA           42.423N   Fax:  +1 781 372 8090
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp

---

From: "John R. Martz" <[email-masked]>
Date: Wed, 25 Aug 1999 15:27:23 -0400

> you always have a remote IP address, but many not have other info.

This may be a pointless counter-point, but the peer doesn't have to give you an IP address, correct?

One of the things I intiailly screwed up and had to fix in my IPCP negotiation was connecting to a
router. Routers typically don't want to give you their IP address because it expects it'll just be
forwarding/routing all the IP packets sent to it. Consequently, a dedicated router is likely to send
you an IPCP cfg-request with no options.

-john martz ([email-masked])
IBM AS/400 TCP/IP PPP (and stuff)