Subject: Re: PPPoE Relay-Session-Id TAG (was Re: I-D ACTION:draft-dasilva-l2tp-relaysvc-00.txt - Comments)

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 20 Aug 2001 21:11:46 +0200

"Mistretta, Tom" wrote:
> 
> I still have many thoughts about this draft but I'd like to latch on to the
> most
> recent conversation.
> 
> It seems like we're trying to figure out if we should support multiple ACs
> beyond
> the LNS or not, and if so, exploring use of the AC-cookie to differentiate
> between possible ACs. 

First half is correct, but not the second. We are trying to figure out if we
shold support multiple ACs beyond the LNS, but it we do we are exploring the use
of the Relay Session ID for this. 

>  While this is an option, you do have the MAC address
> of the
> different ACs as well.  If the LAC stored this state and assigned a
> different session-id
> to each one (i.e., then the session-id identifies both the LNS and the
> remote AC),
> then you wouldn't have to worry about the AC-cookie.  

Right. The cookie really only serves as a "security check" and potentially as a
fast state lookup mechanism (something that is perhaps faster than hashing on
the MAC address and session id). The session ID doesn't scale beyond 65K
sessions, which may or may not be enough particularly if you are aggregating
from distant LACs. 

> Of course this would
> require state to be held at the LAC which is undesirable, however if it's
> required anyway (not completely determined yet) it would be an option.

If you support the AC cookie you have to have state for non-relayed PPPoE
anyway. I think as long as Relayed PPPoE does not require any MORE state than
locally terminated PPPoE, then we have met a reasonable target.

> 
> But more importantly the whole conversation makes me wonder about how
> forwarding
> is going to work in the model where the PPP and PPPoE are not terminated at
> the
> LNS, but rather at some other AC beyond it.   

This is where I think we will have to have Relay Session ID support.

> For clarification, are we
> saying that:
> 
> - Client sends a PPP packet encapsulated in PPPoE and sends to LAC.
> - LAC strips PPPoE and re-encapsulates in L2TP and forwards to LNS.
> - LNS removes L2TP header and re-encapsulates with a new PPPoE and
>   MAC header and forwards to AC.

Agreed so for. 

> 
> The draft also says that the LAC is choosing the PPPoE session-id.  Wouldn't
> this
> cause problems for the remote AC since it is not choosing the session-id
> itself
> (i.e., overlaps in space caused by different LACs feeding into the same AC)?

When you send the PAD packet over PPPoE, you must have:

- PPPoE Session ID established between two PPPoE end points
- Valid MAC addresses between end points

When you send the PAD packet over L2TP, you must have:

- L2TP Tunnel ID and Session ID established between two L2TP end points (session
ID only needed for PADR/S/T)
- Valid IP addresses between L2TP end points
 
If you think of PPPoE and L2TP as just two different PPP tunneling protocols, it
becomes a lot easier conceptually. I don't know about you, but my code has a
*bunch* of different PPP tunneling protocols! :-)

> Actually, the PPPoE is completley stripped at the LAC so the way it would
> have to work is that the non-local AC would have to pick a session ID that
> would get peeled off by the LNS.  Then this would be part of the new header
> at the LNS.  In effect, there would be two PPPoE sessions: one between the
> LAC and the host, and the other between the LNS and the AC.

Yup, and arbitrarily more as you go down the line... One catch is that, unless
we want to add a TLV to PPPoE or an L2TP AVP to the PPPoE Relay information, one
could potentially lose the original MAC address from the PPPoE host and as such
lose some identity information of the initiating user/host.

> 
> In any case, is this considered required or optional functionality?

I would think that it would be optional. e.g. if you support forwarding from
PPPoE->L2TP, you don't have to worry about mapping MAC addresses and such. If
you suport forwarding from L2TP->PPPoE, you have to play more of these games. 

> 
> Tom
> 
> > -----Original Message-----
> > From: W. Mark Townsley [mailto:[email-masked]]
> > Sent: Monday, August 13, 2001 1:13 PM
> > To: Ron da Silva
> > Cc: Reinaldo Penno; [email-masked]'
> > Subject: Re: PPPoE Relay-Session-Id TAG (was Re: I-D
> > ACTION:draft-dasilva-l2tp-relaysvc-00.txt - Comments)
> >
> >
> >
> > You need something in the PADI to link the PADO as well. The
> > Cookie is only
> > defined as present in the PADO and PADR.
> >
> > So, as long as you are not forwarding to another PPPoE AC
> > then, yes, I think the
> > Cookie is sufficient, and probably better, than the relay session ID.
> >
> > - Mark
> >
> > Ron da Silva wrote:
> > >
> > > Does the Relay-Session-Id TAG really need to be changed
> > when forwarded
> > > from the LNS to the local PPPoE AC?  The LNS could use the
> > AC-Cookie TAG
> > > to uniquely identify the different PADOs from the LAN.
> > >
> > > -ron
> >