Subject: Comments on relay draft

From: "Mistretta, Tom" <[email-masked]>
Date: Wed, 22 Aug 2001 17:18:38 -0400

I would suggest that we take a closer look at the path we are taking with
this draft.  In general 
my concerns with the current draft fall into two areas:

1) The draft tries to address service selection, but it doing so it marries
PPPoE and L2TP 
    together in the solution.  I believe that any approach we take for
service selection with L2TP
    should be abstract enough as to be applicable to any access mechanism
that is used with L2TP.
    Access specific service selection mechanisms, such as the discovery
process in PPPoE, 
    would then utilize the generic L2TP solution.

2) The draft has scaling and performance issues in high-density environments
that need to be
    addressed.  For example, the only way to reflect services from different
LNSs is to broadcast
    the PADIs and aggregate the responses at the LAC.  In a "mother's day"
scenario, where N 
    clients are logging into the LAC and there are M LNSs to distribute
over, a problem that 
    used to be O(N) turns into O(N*M).

As mentioned at the London meeting, there are alternative approaches (i.e.,
proxy) that could
be used to achieve similar results that would maintain identical scalability
and call setup time 
characteristics.  It doesn't come without other restrictions, but these are
design tradeoffs that
need to be understood before moving forward.  

I think the discussion should start with a clear understanding of how
service selection is done
before authentication.  This in itself seems a little strange to me at
times, even though it is
a feature of PPPoE.  Once we get a clear view of that, then I think we
should follow with
a list of the requirements and design goals.  Only then will we be able to
make the right 
decision on how to approach the problem.

In reading the draft and discussing it with people, I see the following.
Others may want to 
add more.

Requirements:

- Allow a client (subscriber host) to request a list of services from a
server that resides at or beyond
  an LNS.  In turn this client would make a selection that would be sent to
the LNS on session
  setup.

- Allow different types of services to be defined at or beyond different
LNSs.

- Applicable to any access solution (independent of the client access
protocol - PPP, PPPoE, 
  whatever else may want to use L2TP in the future).

- Clearly defined operation with tunnel switches.

- Maintain the ability to do effective load distribution of sessions across
a set of LNSs with
  similar characteristics.

Design goal(s):

- Maintain current session setup time and scaling characteristics.

Tom

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 23 Aug 2001 10:06:41 +0200

Tom, these are some of the same arguments we have already hashed out on the list
before I believe (or at least they are not new to me). I will try and remain as
unbiased as possible, providing the counterpoint or summary of counterpoints
that I have already heard. Comments inline.

"Mistretta, Tom" wrote:
>     together in the solution.  

Actually, it simply tries to carry PPPoE information while *divorcing* PPPoE
from L2TP. By carrying PPPoE PAD packets in their entirety, PPPoE can add TLVs
and such without affecting L2TP. No different than a DHCP relay host carrying
all of the host DHCP Options without modifying them (just the few fields one has
modify at the relay point are defined). 

> I believe that any approach we take for

This is a reasonable idea, but does link the two service selection features far
more closely. e.g. you would need to be sure that you were not designing the
L2TP service selection feature to *fit* PPPoE, and essentially providing a TLV
to AVP translation method at the LAC. I actually designed something like this,
wrote it up, and decided not to submit it. It is more complex to implement in
L2TP (certainly requiring additional state at the LAC), and puts L2TP into the
service selection business in general. It is still a bit unclear how PPPoE will
use service selection, are you sure we want to go off and build a generic L2TP
service selection as well? 

However, if you still think this is a very good thing, feel free to submit a
generic "L2TP service selection" draft, and we can try to see how to map PPPoE
SS into L2TP SS. 

>     used to be O(N) turns into O(N*M).

I don't see this as very different than DHCP Relay forwarding a DHCP Discover to
mutliple DHCP Servers (which MAY, in turn, just be a load balancing server that
is forwarding the request onto one of many other DHCP servers). Or, a RADIUS
request that gets sent to multiple servers, proxied to other servers, and so on.
Thus, this problem is not anything exceptionally new. Such "fan out" of requests
would have to be controlled via good network management. We can certainly make
recommendations or "MUSTs" in the draft to this affect.

At any rate, given that L2TP passes PPP-based authorization information in the
L2TP control channel today, there is nothing stopping implementations from this
same exact type of "fan out" that you describe here today. e.g. I could assign
10 IP addresses and an LAC, and 10 more at an LTS and so forth. Each performing
an ICRQ/ICRP/ICCN exchange in hopes of the PPP AAA information matching a
service. The only reason this isn't a problem is that people are smart and don't
do that. Most perform some method of cycling through LNSs one at a time. The
same type of common sense would need to be applied here.

> need to be understood before moving forward.

Not to say that Proxy is not a reasonable model here. It certainly may be. But
it is solving a slightly different problem in a different way. I thought Ron's
note made that fairly clear. 

Let me try and provide some perspective here. I could take the "proxy is more
scalable" argument to simply invalidate PPP tunneling altogether.

Consider PPP tunneling vs. IP tunneling with PPP RADIUS Proxy. Once deployed,
both arguably do the same thing, but in one case (the latter) there is an
implicit trust relationship among policy servers (and perhaps NASs) that must be
supported *and* standardized. That is, I am taking the "PPP Control/AAA
Information" and "proxying" it down to the LAC so that I don't have to send it
across the L2TP control channel. Sound familiar? The difference is subtle, but
important. 

In general, I fail to see why forwarding of PPP Control information in the L2TP
control channel is considered that *different* that forwarding PPPoE Control
information in the L2TP control channel.

> before authentication.  

Why? Does a DHCP Relay box have to understand how DHCP servers operate beyond
the simple mechanism for acting as a Relay Agent? L2TP is simply the
passthrough.

> This in itself seems a little strange to me at
> times, even though it is

The point is, I don't want to try and standardize or wrestle with this problem
at all. I want to forward the PAD packets as best I can, and then let PPPoE folk
figure out how to deploy that. L2TPEXT is not the place to try and standardize
PPPoE. We are just providing an integration service.

This is no different than if GTP asked to have a few AVPs, and perhaps evan a
message or two, for some wireless tunneling stuff specific to their domain to be
passed through to the LNS, and perhaps into another GTP tunnel. Why should I
have to "understand" cellular or packet data networks (beyond that which is
necessary to pass the data at the right time relative to session establishment)
in order to allow this? 

One could even argue that this is not much different than passing a Called
Number or ATM VPI/VCI either. Bottom line, it is just some information that is
relevant to the access method transitioning to an L2TP session that is being
passed through the L2TP control channel for the other side to peruse as he sees
fit. L2TP itself doesn't know what an ATM VPI/VCI is, but the policy at the end
of the tunnel certainly should if it is needed to provide the service.

> - Maintain the ability to do effective load distribution of sessions across

These sound like requirements for a new extension to L2TP - "L2TP Service
Selection" or some such. This is a different beast. On its own, there may be
some motivation for its purpose.

However, if it is being defined just a common translation point, I think in
order to adequately define this we need to have at least two, if not more,
service selection enabled protocols that we are trying to translate into this
new L2TP extension. The point is that, if, after defining this, it is never used
for more than PPPoE then we have surely wasted a lot of effort. 

Let me draw an analogy. If I have 10 people from 10 different countries,
speaking 10 different languanges, it makes sense just to teach them all one
common language so that they can communicate. But, If I only have two people
speaking two different languages, it probably makes more sense to just pick one
and teach it to the other. 

Thus, arguments for a generic SS mechanism of its own within L2TP aside, the
answer to this question really depends on how many service selection enabled
protocols we think L2TP will have to integrate with, and whether or not they
will be similar enough to fall into our generic L2TP service selection
technique.

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 23 Aug 2001 08:08:36 -0700

Hello Mark,

I didn't read the email fully but I just like to point out some statements
on your previous email, which kind of of go back to our discussion on
comparing PPPoE and DHCP.

1) "Actually, it simply tries to carry PPPoE information while *divorcing*
PPPoE.."

2) "Why? Does a DHCP Relay box have to understand how DHCP servers operate
beyond
the simple mechanism for acting as a Relay Agent? L2TP is simply the
passthrough."

3) "I want to forward the PAD packets as best I can, and then let PPPoE folk
figure out how to deploy that"

So, I actually agree with these, but then, let's not mess the PPPoE protocol
in any way [(2) and (3)] and let's not assume LNS can share information with
an AC by considering them on the same box [(1)]. Anyway, I think I made
those observations clearly on my last email.

Now, I do not think 

a) - Allow different types of services to be defined at or beyond different
LNSs.

b) - Applicable to any access solution (independent of the client access
protocol - PPP, PPPoE, whatever else may want to use L2TP in the future). 

c) Clearly defined operation with tunnel switches.
 
d) Maintain the ability to do effective load distribution of sessions across
a set of LNSs with similar characteristics.

are a different beast as you said, specially (a) and (c). If you want to
make sure of [(1)-(3)], then you should be able to make sure it is general
enough

Finally, (b) and (d) are not specifically tied to the problem in hand, but
have applicability in it, so I propose we try to hash out some ideas on
service selection and load balancing.

regards,

Reinaldo

> -----Original Message-----
> From: W. Mark Townsley [mailto:[email-masked]]
> Sent: Thursday, August 23, 2001 1:07 AM
> To: Mistretta, Tom
> Cc: [email-masked]'
> Subject: Re: Comments on relay draft
> 
> 
>

---

From: "Mistretta, Tom" <[email-masked]>
Date: Thu, 23 Aug 2001 11:22:30 -0400

Hi Mark,

How about focusing on this one point first.  In my view it all stems from

>the simple mechanism for acting as a Relay Agent? L2TP is simply the

Not for address assignment, because that is well understood already.  But if
the DHCP relay box was relaying PPPoE PADIs then I would have the same
opinion: that we need to understand the application before designing the
solution.

It appears to me that the draft is trying to address PPPoE service selection
over L2TP, this is mentioned in the abstract and section 2.0.  I can see
possible value in doing this but all the models that make sense to me are
limited in scope of service selection.  My exposure to PPPoE service
selection is fairly coarse: for example, someone plugs their laptop into the
airport LAN and gets a set of ISPs he can try to authenticate to.  Maybe the
list is augmented by "gold" or "free".  In any case it's a short list
because more involved service selection is done after full authentication.
This application has a set of hard requirements -- like contacting multiple
ACs -- whereby if the solution does not perform well the application is not
possible to deploy in a larger scale environment.  You can see from my
requirements list where some of the other issues may be.

So fundamentally, how do we see this being used?  Like I've described?
Finer level of service selection?  I understand that you want to take the
view that L2TPEXT should not care, but I believe it is not prudent to
proceed without more understanding of the application.  How else can you
make design choices?  Should we get the PPPoE people involved (newbie
question: who are they as PPPoE is informational?).

Tom

-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 4:07 AM
To: Mistretta, Tom
Cc: [email-masked]'
Subject: Re: Comments on relay draft

Tom, these are some of the same arguments we have already hashed out on the
list
before I believe (or at least they are not new to me). I will try and remain
as
unbiased as possible, providing the counterpoint or summary of counterpoints
that I have already heard. Comments inline.

Actually, it simply tries to carry PPPoE information while *divorcing* PPPoE
from L2TP. By carrying PPPoE PAD packets in their entirety, PPPoE can add
TLVs
and such without affecting L2TP. No different than a DHCP relay host
carrying
all of the host DHCP Options without modifying them (just the few fields one
has
modify at the relay point are defined). 

>     would then utilize the generic L2TP solution.

This is a reasonable idea, but does link the two service selection features
far
more closely. e.g. you would need to be sure that you were not designing the
L2TP service selection feature to *fit* PPPoE, and essentially providing a
TLV
to AVP translation method at the LAC. I actually designed something like
this,
wrote it up, and decided not to submit it. It is more complex to implement
in
L2TP (certainly requiring additional state at the LAC), and puts L2TP into
the
service selection business in general. It is still a bit unclear how PPPoE
will
use service selection, are you sure we want to go off and build a generic
L2TP
service selection as well? 

However, if you still think this is a very good thing, feel free to submit a
generic "L2TP service selection" draft, and we can try to see how to map
PPPoE
SS into L2TP SS. 

>     used to be O(N) turns into O(N*M).

I don't see this as very different than DHCP Relay forwarding a DHCP
Discover to
mutliple DHCP Servers (which MAY, in turn, just be a load balancing server
that
is forwarding the request onto one of many other DHCP servers). Or, a RADIUS
request that gets sent to multiple servers, proxied to other servers, and so
on.
Thus, this problem is not anything exceptionally new. Such "fan out" of
requests
would have to be controlled via good network management. We can certainly
make
recommendations or "MUSTs" in the draft to this affect.

At any rate, given that L2TP passes PPP-based authorization information in
the
L2TP control channel today, there is nothing stopping implementations from
this
same exact type of "fan out" that you describe here today. e.g. I could
assign
10 IP addresses and an LAC, and 10 more at an LTS and so forth. Each
performing
an ICRQ/ICRP/ICCN exchange in hopes of the PPP AAA information matching a
service. The only reason this isn't a problem is that people are smart and
don't
do that. Most perform some method of cycling through LNSs one at a time. The
same type of common sense would need to be applied here.

> need to be understood before moving forward.

Not to say that Proxy is not a reasonable model here. It certainly may be.
But
it is solving a slightly different problem in a different way. I thought
Ron's
note made that fairly clear. 

Let me try and provide some perspective here. I could take the "proxy is
more
scalable" argument to simply invalidate PPP tunneling altogether.

Consider PPP tunneling vs. IP tunneling with PPP RADIUS Proxy. Once
deployed,
both arguably do the same thing, but in one case (the latter) there is an
implicit trust relationship among policy servers (and perhaps NASs) that
must be
supported *and* standardized. That is, I am taking the "PPP Control/AAA
Information" and "proxying" it down to the LAC so that I don't have to send
it
across the L2TP control channel. Sound familiar? The difference is subtle,
but
important. 

In general, I fail to see why forwarding of PPP Control information in the
L2TP
control channel is considered that *different* that forwarding PPPoE Control
information in the L2TP control channel.

> service selection is done

Why? Does a DHCP Relay box have to understand how DHCP servers operate
beyond
the simple mechanism for acting as a Relay Agent? L2TP is simply the
passthrough.

> decision on how to approach the problem.

The point is, I don't want to try and standardize or wrestle with this
problem
at all. I want to forward the PAD packets as best I can, and then let PPPoE
folk
figure out how to deploy that. L2TPEXT is not the place to try and
standardize
PPPoE. We are just providing an integration service.

This is no different than if GTP asked to have a few AVPs, and perhaps evan
a
message or two, for some wireless tunneling stuff specific to their domain
to be
passed through to the LNS, and perhaps into another GTP tunnel. Why should I
have to "understand" cellular or packet data networks (beyond that which is
necessary to pass the data at the right time relative to session
establishment)
in order to allow this? 

One could even argue that this is not much different than passing a Called
Number or ATM VPI/VCI either. Bottom line, it is just some information that
is
relevant to the access method transitioning to an L2TP session that is being
passed through the L2TP control channel for the other side to peruse as he
sees
fit. L2TP itself doesn't know what an ATM VPI/VCI is, but the policy at the
end
of the tunnel certainly should if it is needed to provide the service.

However, if it is being defined just a common translation point, I think in
order to adequately define this we need to have at least two, if not more,
service selection enabled protocols that we are trying to translate into
this
new L2TP extension. The point is that, if, after defining this, it is never
used
for more than PPPoE then we have surely wasted a lot of effort. 

speaking two different languages, it probably makes more sense to just pick
one

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 23 Aug 2001 17:19:14 +0200

> Reinaldo Penno wrote:
> 
> Hello Mark,
> 
> I didn't read the email fully but I just like to point out some statements on
> your previous email, which kind of of go back to our discussion on comparing
> PPPoE and DHCP.
> 
> an AC by considering them on the same box [(1)]. Anyway, I think I made those
> observations clearly on my last email.

Yes, agreed.

> d) Maintain the ability to do effective load distribution of sessions across a
> set of LNSs with similar characteristics.
> 
> are a different beast as you said, specially (a) and (c). If you want to make
> sure of [(1)-(3)], then you should be able to make sure it is general enough
> 

Perhaps I painted the listed requirements with too big a brush. 

(a) and (c), as you say, should be well defined. Ron is including more text
regarding (d). (b) is what opens up the scope considerably and more of what I
was referring to as a different beast.

---

From: Ron da Silva <[email-masked]>
Date: Thu, 23 Aug 2001 16:30:22 -0400

Gee - lots of comments.  Thanks!  Thread was getting sort of long - maybe
I can summarize the issues?

1) General L2TP SS AVP(s) vs. PPPoE PAD specific AVP
2) Scaling wrt lots of LNS, etc.
3) Proxy vs. Relay
4) Clarify design goal of draft
5) Operation under tunnel switching
6) Operation of ACs beyond the LNS
7) Do we need to discuss service selection?
8) Load distribution

Let's address them systematically after we have them all identified.
Anything to add?

-ron

---

From: "Mistretta, Tom" <[email-masked]>
Date: Thu, 23 Aug 2001 22:16:56 -0400

Sorry for the messy posting.  I agree we should hit one at a time.

Issue list is pretty complete, however I would start with a discussion of
the target application.  This I suppose would include your thought on the
need to discuss service selection.  Then I would progress on the rest of the
requirements (including the need to support different services at different
LNSs - that one is not in there) before looking at any one solution.

My last post talked a little bit about this too (it may have been lost in
the lengthy email).

Tom

-----Original Message-----
From: Ron da Silva
To: Mistretta, Tom; [email-masked]; [email-masked]
Cc: [email-masked]
Sent: 8/23/2001 4:30 PM
Subject: Re: Comments on relay draft

Gee - lots of comments.  Thanks!  Thread was getting sort of long -
maybe
I can summarize the issues?

-ron

---

From: Ron da Silva <[email-masked]>
Date: Thu, 30 Aug 2001 14:58:21 -0400

Ok, revised based on feedback from Tom.

1) Clarify design goal of draft
2) Do we need to discuss service selection?
3) Proxy vs. Relay
4) General L2TP SS AVP(s) vs. PPPoE PAD specific AVP
5) Operation of ACs beyond the LNS
6) Operation across multiple LNSs with inhomogeneous services 
7) Scaling wrt lots of LNS, etc.
8) Load distribution
9) Operation under tunnel switching

-ron

---

From: Ron da Silva <[email-masked]>
Date: Thu, 30 Aug 2001 15:06:35 -0400

> 1) Clarify design goal of draft

This is simple.  Provide a mechanism to perform PPPoE service selection
somewhere remote from the LAC.  Specifically (since this is under the
guise of the L2TP WG) provide a mechanism that can leverage any
pre-existing L2TP topology and specific the interface between PPPoE
service selection and L2TP.  (Other remote service selection methods
may be developed outside of L2TP, but they are not in the scope of this
draft.)

-ron

---

From: Ron da Silva <[email-masked]>
Date: Thu, 30 Aug 2001 15:08:15 -0400

> 2) Do we need to discuss service selection?

I don't think so, but I am open to suggestions. :-)

-ron

---

From: Ron da Silva <[email-masked]>
Date: Thu, 30 Aug 2001 15:12:16 -0400

> 3) Proxy vs. Relay

I think they solve different problems (refer to issue #1).
Proxy (where the LAC has some knowledge communicated back to it
and facilitates service selection directly) is interesting, but
not under the scope of this draft by definition of the design
goal.

I propose delaying comments on issues 4-9 until we give 1-3 some
time to be hashed somewhat.

-ron

---

From: "Paul W. Howard" <[email-masked]>
Date: Thu, 30 Aug 2001 18:44:15 -0400

Ron,

Is this goal really "service selection remote from the LAC "?  I would seem
that we're really trying to provide is the ability to make the remote ACs
visible to the requesting host?  It's the host that is going to do the
actual service selection based on the received PADOs, not the remote AC.

Thanx,

Paul Howard

---

From: Ron da Silva <[email-masked]>
Date: Fri, 31 Aug 2001 09:04:55 -0400

Paul,

> actual service selection based on the received PADOs, not the remote AC.

Poor articulation on my part - yes host does the selection, remote ACs
simple offer services.  Not looking to change PPPoE functionality.

thanks,
-ron