Subject: RE: I-D ACTION:draft-dasilva-l2tp-relaysvc-00.txt - Comments

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 10 Aug 2001 11:30:12 -0700

Hello Folks, Mark/Ron,

Since we talked a little bit about this on the WG I thought it would be good
to put some observations here.

First of all, so people do not get me wrong, I see applicability for a
solution of extending PPPoE through a IP network.

Now, I also see some issues:

a) When I first read this draft I had the impression that when the LNS had
received the relay PADX, it could then broadcast the packet through a
ethernet interface in order to reach several ACs. I think this option wasn't
described. In other words, the method assumes the LNS is the AC? I think
this limits the applicability of the solution.

b) Now, the way it is today this method somehow breaks what is powerful
about PPPoE, the discovery process. In response to a PADI you can have
several PADO from potencially different devices. So, you probably know where
I'm getting at....The LAC would have to open tunnels to several LNSs (if
available), get their responses and relay them back to the client, otherwise
the LAC would be breaking the discovery process by restricting the choice of
device to one. And if the ACs are distributed after several LNSs (this is a
very nice application), it would have to relay all messages back.

As an observation, it's very common for ACs to have different thresholds
based on domainname, ISPname, whatever. So if a AC does not answer to a PADI
or refuses a session, that doesn't mean that the LAC should start rerouting
ALL sessions to a different device. It could just mean that for ISP A the AC
will not handle any more sessions. Since this is dynamic, the LAC would need
to try all ACs/LNSs always or there must be a load AVP to indicate that.

c) There are several extensions for PPPoE proposed. I personally
participated on three. I do not know if there are issues or not with this
method relating extensions around PPPoE. There might be none, there might
be, I didn't really thought much about it.

Check for instance
http://search.ietf.org/internet-drafts/draft-penno-pppoe-ext-service-03.txt

I'm attaching a second one who deals with multicast and broadcast on PPPoE. 

d) Maybe you could join the chorus and convince Thomas N. to setup a PPPoE
BOF in Salt Lake City (;-). I tried in London.

thanks,

Reinaldo Penno

---

From: Ron da Silva <[email-masked]>
Date: Fri, 10 Aug 2001 16:43:43 -0400

Reinaldo,

> this limits the applicability of the solution.

Agreed.  I had discussed this with a colleague earlier this week.  Specifically,
need to consider an LNS sending multiple PADOs (whether or not they are
triggered by forwarding of the PADIs to a LAN attached to the LNS is a
subset).  I need to think it through some and will comment later...

> device to one...

Right...this is covered by allowing forwarding of the PADI to multiple
LNSs.

> ...and if the ACs are distributed after several LNSs (this is a

Hmm...not sure what you mean by this.

> to try all ACs/LNSs always or there must be a load AVP to indicate that.

I think I am loosing you on which ACs are LACs and which are LNSs and which
are doing nothing wrt L2TP.  In all cases, I would expect implementations
to provide mapping of PPPoE requests to LNSs (this could be triggered by 
a physical interface, MAC address, etc).  If those mappings include thresholds
or bounded resources, I see those constraints independent of the protocol
functionality.

Please clarify you concern on b) above.

> be, I didn't really thought much about it.

PADC - I think we can accommodate this extension.  For example, the LAC would
be able to generate the PADC (could be triggered by the LNS).  The PADT and
remaining procedures are already covered by the draft.

> I'm attaching a second one who deals with multicast and broadcast on PPPoE. 

Obviously, PPPoE has limitations wrt multicast and broadcast domains independent
of relay.  But in the draft attached in your email, it is assumed that the PPP
session is terminated at the LAC.  So, under the relay draft the LNS would need
to determine over which L2TP tunnels to forward multicast data.  Asking the
LAC to forward that payload to the multicast mac address is outside this
discussion I think.  Likewise, how the LAC would handle joins I don't think
needs to be addressed by the relay per se.

I'll have to think about this...but it isn't a problem with relay
necessarily, it is more of a PPPoE - multicast interaction problem.

-ron

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ron da Silva                          [email-masked]
Network Architect                    703.265.4548
America Online, Inc.
A wholly owned subsidiary of AOL Time Warner Inc.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Sun, 12 Aug 2001 23:33:21 +0100

> subset).  I need to think it through some and will comment later...

Allow multiple PADOs. You can leverage the relay-session-id to identify
which PPPoE AC beyond the LNS the session is for. We should probably expand the
text a bit here (specifically covering the case of LNS to PPPoE AC, vs. just
PPPoE Host to LAC), but I don't think this is a problem as long as we can rely
on the relay-session-ID. 

This begs the question though, how many PPPoE implementations actually
implement the relay-session-ID Tag as identified in the RFC? I hope that most
do. If they do not, we should decide whether to try and support relay to
multiple hosts via games with MAC addresses, inclusion of our own relay session
id tag of sorts at least to track forwarded messages between the LAC and LNS, or
simply pressure the PPPoE community to implement the relay Tag.