Subject: Usage of ML Endpoint Discriminator Option

From: "John R. Martz" <[email-masked]>
Date: Mon, 23 Aug 1999 18:08:47 -0400

Folks,

I think my brains are not working correctly because I'm not understanding some of section 5.1.3
"Endpoint Discriminator Option" in RFC 1990. Hope by posting my questions to this list some kind
soul will help out.

First question: What should an implementation do if it receives the Endpoint Discriminator Option
but does NOT receive the MRRU option?

RFC1990 says that "the implementation MUST NOT assume that multilink operation is being requested on
this basis alone".

Well why not?? I'm a bit confused at this point as to when/how an implementation knows a link can be
part of a multilink bundle and when it knows a link can NOT be part of a bundle. (Probably doesn't
matter in typical connect scenarios ... but figure it's best to ask and learn).

Second question: What is RFC1990 asking an implementation to do for scenario (1), "no
authentication, no discriminator".

The text reads: "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".

Does this mean there is supposedly a "default bundle" to which all new links that negotiate an MRRU
but nothing else to identify the list are implicitly joined? Or does it mean that the link is
considered to part of a "bundle" of one and only 1 link? Also, I don't think I understand what is a
"manually configured bundle connecting two given systems". (Can anyone provide me with or point me
towards an example?)

Thanks for you patience in reading this. Hope someone will be able to set me straight.

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

---

From: James Carlson <[email-masked]>
Date: 24 Aug 1999 08:32:33 -0400

[email-masked] ("John R. Martz") writes:
> First question: What should an implementation do if it receives the
> Endpoint Discriminator Option but does NOT receive the MRRU option?

Nothing.  Some implementations will Configure-Reject it, others will
Configure-Ack it.  In either case, it doesn't enable MP, and doesn't
do anything special to the link.  (Personally, I prefer to send LCP
Configure-Ack, since it leads to faster convergence.  More
conservative implementations might Configure-Reject it to avoid
triggering MP-related bugs in their peers.)

> RFC1990 says that "the implementation MUST NOT assume that multilink
> operation is being requested on this basis alone".

Right.  MRRU enables MP.  The ED is just an unauthenticated
identifier.  In fact, an implementation could view it as logically
concatenated with the PAP/CHAP Peer-ID for validation purposes.
(Although this would lead to failures in practice if the hardware at
one end were replaced.)

> Well why not?? I'm a bit confused at this point as to when/how an
> implementation knows a link can be part of a multilink bundle and
> when it knows a link can NOT be part of a bundle. (Probably doesn't

For simplicity, there needs to be exactly one switch to enable or
disable MP on a link.  MRRU was chosen as that switch.

> Second question: What is RFC1990 asking an implementation to do for
> scenario (1), "no authentication, no discriminator".
> 
> The text reads: "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".
> 
> Does this mean there is supposedly a "default bundle" to which all
> new links that negotiate an MRRU but nothing else to identify the
> list are implicitly joined?

Yes.  Exactly.

> Or does it mean that the link is considered to part of a "bundle" of
> one and only 1 link? Also, I don't think I understand what is a
> "manually configured bundle connecting two given systems". (Can
> anyone provide me with or point me towards an example?)

It could be an explicit list provided by an operator specifying that
ports, 1, 2, and 7 (say) are all a single bundle, and that ports 3
through 6 are another bundle.

You would do this if you had some kind of reliable indication that the
links are actually connected to the peers intended.  For instance, if
it's a set of physical cables between two boxes and the cables are
under your control, you might forego authentication, but still want
MP.

Note that "manually configured" might also involve external
information -- such as calling party numbers on an ISDN line -- but
that's outside the scope of the specification.

(Scenario 1 is rather marginal; it's generally not used in practice
except with conformance tests.  ;-})

-- 
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: Clara McKenzie <[email-masked]>
Date: Wed, 25 Aug 1999 00:21:01 -0700

Hi John et al,

> but does NOT receive the MRRU option?

I always just Configure-ACK it - it's just a point of information.

> matter in typical connect scenarios ... but figure it's best to ask and learn).

If you have not been given an endpoint discriminator,  you can assign one based on the login name.
Here's my reading of the bundling rules.

RFC1990 5.1.3:

>As there is also no requirement for authentication, there are four
>   sets of scenarios:

>  (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.
An example would be (and here's where that manual configuration clause comes in) could be a no-auth
connection, but one that is identifiable by Called-Number or Calling-Number, you could assign the
Called or Calling Number as the bundle identifier.

>   (2)  Discriminator, no authentication:
>       Discriminator match -> MUST join matching bundle,
>       discriminator mismatch -> MUST establish new bundle.

no-auth connections are not "typical" but if there is no auth and the endpoints discriminators are
identified to you as the same then they can join the bundle. If you have additional information about
the calls that suggest to you that they shouldn't join (such as the Called Numbers are different and
you are identifying or "authenticating" via Called Numbers), then you can but them in separate bundles.

>   (3)  No discriminator, authentication:
>       Authenticated match -> MUST join matching bundle,
>        authenticated mismatch -> MUST establish new bundle.

Since authentication is the only identifier here, this makes sense.

>   (4)  Discriminator, authentication:
>        Discriminator match and authenticated match -> MUST join bundle,
>        discriminator mismatch -> MUST establish new bundle,
>        authenticated mismatch -> MUST establish new bundle.

No problem here either, if both as present, both must match.

> but nothing else to identify the list are implicitly joined?

As noted before,  you are able to identify the links by whatever means available, not just negotiated
values.

> Or does it mean that the link is
> considered to part of a "bundle" of one and only 1 link?

Each link is part of one bundle.

> Also, I don't think I understand what is a

If I login as "clara", the system looks up my connection information based on "clara".  That is
essentially manual configuration.  The conneciton information lookup could also have been based on my
Calling-Number, the Called-Number, or even based on my negotiated IP Address.  All examples of manual
configuration.

> IBM AS/400 TCP/IP PPP (and stuff)

Hope I didn't make it worse!

Clara McKenzie
[email-masked]

---

From: Holger Kummert <[email-masked]>
Date: Wed, 25 Aug 1999 09:56:52 +0200 (MEST)

> [email-masked] ("John R. Martz") writes:
[...]
> disable MP on a link.  MRRU was chosen as that switch.

In reading rcc1990 that is not so clear to me. Maybe it's intended when
you "read between the lines", but what I found was (as was pointed
out before):

5.1.3.  Endpoint Discriminator Option

   [...]
   the implementation MUST NOT assume
   that multilink operation is being requested on this basis alone.

So MRRU and ED together will be accepted to negotiate MP.
Another hint is in

11.1.  Negotiating Multilink, per se

   RFC 1717 permitted either the use of the Short Sequence Number Header
   Format (SSNHF) or the Maximum Reconstructed Receive Unit (MRRU)
   options by themselves to indicate the intent to negotiate multilink.
   This specification forbids the use of the SSNHF option by itself; but
   does permit the specific of both options together.

So MRRU and SSN together will also do.
So we decided in our PPP-implementation to accept a link to join (or
create) a bundle only when MRRU and one of SSN or ED is negotiated.
Is that correct?

Holger

--
Holger Kummert                         Phone: +49 721 9495-135
Nentec Netzwerktechnologie GmbH        WWW:   http://www.nentec.de/

---

From: James Carlson <[email-masked]>
Date: Wed, 25 Aug 1999 08:38:24 -0400 (EDT)

> you "read between the lines", but what I found was (as was pointed

I agree that the wording makes this less than clear, but my original
reply was correct.  There is only one switch that turns on MP -- it is
the MRRU.  You can certainly use the other options *with* the MRRU
when using MP.  But none of them enable MP.

> So MRRU and ED together will be accepted to negotiate MP.

Sure.  ED is accepted.  So are Protocol Field Compression and Address
and Control Field Compression.  None of these, though, enable
multilink operation.

> create) a bundle only when MRRU and one of SSN or ED is negotiated.

No.  MRRU alone does the job.

---

From: Holger Kummert <[email-masked]>
Date: Wed, 25 Aug 1999 16:19:58 +0200 (MEST)

> when using MP.  But none of them enable MP.

So I would recommend that we make this more clear when rfc1990
will be revised (for standard, when I remember correctly).

Holger

---

From: "John R. Martz" <[email-masked]>
Date: Wed, 25 Aug 1999 10:22:32 -0400

Folks,

Thanks much for your responses.

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.

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

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

Thanks,

---

From: James Carlson <[email-masked]>
Date: 25 Aug 1999 11:47:11 -0400

[email-masked] ("John R. Martz") writes:
> 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

You're certainly free to add any sort of user controls you like, and I
agree with you that the default bundle scenario is odd in some
configurations.

> My impression is this is a valid RFC 1990 compliant implementation

If I were pressed to worry about this, I would make it so that if a
peer fails to include an E-D in its LCP Configure-Request AND either
it sends LCP Configure-Reject for the authentication option or we're
configured not to offer that option, then I would not include MRRU in
my LCP Configure-Request and would send Configure-Reject if the peer
does include it.

There's one corner case you'll have to deal with to do this.  If you
send LCP Configure-Request with MRRU but no authentication, and the
peer Configure-Acks this request, and you then receive LCP
Configure-Request with MRRU but without E-D, you must Configure-Reject
MRRU and send a new Configure-Request without the MRRU option, since
your assumption would then be invalid.

(Of course, if you always demand authentication from your peers, and
you never accept an unauthenticated connection, then all of this
discussion, including the check-box option, is completely moot.  The
Peer-ID from the authentication protocol is as good as the E-D; and
maybe better.)

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

Those all fall under the "manual configuration" area; and they're all
legal if you have the information to do it right.  (Note that doing it
*right* might be hard, since calling party information isn't always
going to be strictly identical for a single caller, depending on what
his line configuration looks like.  Even on ISDN, the two B channels
*might* provide different number appearances.  Sigh.)