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

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 10 Aug 2001 15:07:38 -0700

Hello Ron,

thanks for the answer. Comments inline.

> -----Original Message-----
> From: Ron da Silva [mailto:[email-masked]]
> Sent: Friday, August 10, 2001 1:44 PM
> To: Penno, Reinaldo [SC9:T327:EXCH]
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-dasilva-l2tp-relaysvc-00.txt - Comments
> 
> 
> 
> 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
> > very nice application), it would have to relay all messages back.
>
> Hmm...not sure what you mean by this.

Bad wording. I was pointing out the fact that in a enviroment like this the
LAC will have establish control connections to several LNSs and send the
PADI. Potential large amount of messages and replication of messages has to
be done in a environment with large number of LNSs. In an ethernet
environment the client has to send just one message. This might affect
performance. Or might not....

> 
> 
> 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 mapping will only be possible if the AC resides on the LNS. See below.

(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.
> 

My point is that in the draft you assumed that the AC resides on the LNS.
When the AC and LNSs are not on the same device, the L2TP LAC or LNS have no
idea about these thresholds (let's use "state" to be more general). So, for
instance,  you can send SRRQ messages everytime to every LNS or try to
perform some optimization. A very simple case is when an AC fails. The LAC
would still continue to send SRRQ to the LNS before the AC. There might be
others issues, have to think about it.

> Please clarify you concern on b) above.
> 

just did. My main point is that IMO the draft shouldn't assume that LNS and
ACs are on the same machine. When AC=LNS is a subset of the more general
case.

thanks,

Reinaldo

---

From: Ron da Silva <[email-masked]>
Date: Mon, 13 Aug 2001 10:03:43 -0400

Reinaldo,

On Fri, Aug 10, 2001 at 03:07:38PM -0700, Reinaldo Penno wrote:
> My main point is that IMO the draft shouldn't assume that LNS and

Ok, got it now - the draft assumes the LNS is the PPPoE AC.  The outstanding
issue is for an LNS that either offers multiple PADOs or that reflects multiple
PADx messages to PPPoE ACs that are on an attached LAN.

In the case of reflection to local LAN, the LAC first differentiates the LNS by
use of the PPPoE Relay-Session-ID, the PADOs associated with that LNS would
need to be further differentiated by unique the AC-Name TAGs for each PPPoE AC
on the LAN that is sending a PADO via the LNS.

For the other case, I don't think it would make sense for the LNS to have
multiple PADOs without reflecting them from other ACs on an attached LAN;
however, if it did it would need to either fudge the AC-Name with a virtual
AC-Name for each PADO or add additional Service-Name TAGs to differentiate
the PADOs.  Practically though, if the LNS wanted to offer multiple services
it should simply respond with a single PADO that has all of the Service-Name
TAGs available - no need to dump them into multiple PADOs that I can see.

Now, another related task would be that if the PPPoE AC were not the LNS
the LNS would likely need to repack the PPP into a local PPPoE session between
the LNS and the local PPPoE AC.   Hmm...I think that needs some more thinking...

-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: Mon, 13 Aug 2001 17:49:09 +0200

> TAGs available - no need to dump them into multiple PADOs that I can see.

Unless there is a namespace conflict among the LACs.

> the LNS and the local PPPoE AC.   Hmm...I think that needs some more thinking...

Here, the relay agent looks like a PPPoE Host. The current draft speaks to
forwarding when the relay agent is a PPPoE AC only. I think both are possible,
as long as you allow yourself full flexibility for the relay agents to mess with
the relay-session-id as needed. I think the draft either needs to define how
relay mode is accomplished at the LNS (e.g. PPPoE Host relay mode), or just
state it as being out of scope.

Note that even if we don't try to support LNS to PPPoE AC forwarding, we will
have to think about some of this for relay through a tunnel switch.