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

From: "Vipin Jain" <[email-masked]>
Date: Wed, 22 Aug 2001 11:01:14 -0700

Mark, Ron:

Given that we can tunnel Ethernet over l2tp (Suhail's draft), why not simply
do following:

[pppoe]  <------> [LAC pppoe/l2tp] <-------> [ pppoe termnation on LNS (AC)
]

Why do we need to relay pppoe information to LNS, then?
An implementation will have to take care of recognizing pppoe discovery
packets on LNS in both situations.

thanks,
-- vipin

-----Original Message-----
From: Penno, Reinaldo [SC9:T327:EXCH] 
Sent: Wednesday, August 22, 2001 7:57 AM
To: 'W. Mark Townsley'; 'Mistretta, Tom'
Cc: ''Ron da Silva' '; [email-masked]' '
Subject: RE: PPPoE Relay-Session-Id TAG (was Re: I-D ACTION:draft-dasilva
-l2tp-relaysvc-00.txt - Comments)

Hello, 
IMHO we need to rethink this draft. I particulary do not like this
session_id mechanism and the draft is too restrictive. Session_IDs should be
defined by the AC only, we should not assume that the AC is a device
"co-resident" with the LNS and we should assume that a tunnel switched
network might exist between LAC and LNS. I prefer to find some other means
to identify LNS, AC and clients that do not mess with the PPPoE protocol.
Maybe some other AVPs in L2TP, MAC address, some other variable, etc. 
thanks, 
-RP 
> -----Original Message----- 
> From: W. Mark Townsley [mailto:[email-masked]] 
> Sent: Monday, August 20, 2001 11:03 PM 
> To: Mistretta, Tom 
> Cc: Penno, Reinaldo [SC9:T327:EXCH]; ''Ron da Silva' '; 
> [email-masked]' 
> ' 
> Subject: Re: PPPoE Relay-Session-Id TAG (was Re: I-D 
> ACTION:draft-dasilva -l2tp-relaysvc-00.txt - Comments) 
> 
> 
> 
> 
> "Mistretta, Tom" wrote: 
> > 
> > Right, I needed to be more specific with those terms.  But 
> in fact the LAC 
> > chooses both a PPPoE session-id (since that is only of 
> local significance 
> > between the LAC and host) and the PPPoE relay-session-id.  
> If the PPPoE is 
> > extended to an AC beyond the LNS, there is yet another 
> PPPoE session-id that 
> > has local significance between the LNS and AC (in this case 
> it is chosen by 
> > the AC).  There are two PPPoE sessions. 
> 
> Right. 
> 
> > 
> > And all this makes us think for the there needs to be two pieces of 
> > information in the case where there are ACs beyond the LNS: 
> one for the LAC 
> > to identify the tunnel/control channel itself, and another 
> for the LNS to 
> > identify the AC.  At first I was thinking that the source 
> MAC address could 
> > be used to identify the "remote" AC, but aren't the MAC 
> headers stripped 
> > when the PPPoE PAD messages are sent between the LAC and 
> LNS?  I thought so. 
> 
> They are not. In the current definition, the entire Ethernet 
> packet, MAC and 
> all, is sent in the PAD relay. If this is not clear, please 
> let us know. 
> 
> > In that case, I think there may need to be some other 
> facility so that the 
> > LNS can choose and provide to the LAC (to be further 
> relayed to the host) 
> > some identifer of the remote AC.  Both of these would need to either 
> > packaged up or referred to by the "final" PPPoE session-id 
> sent to the host 
> > to be returned by the PADR. 
> 
> The only thing I can think of here is to add a new PPPoE TLV that gets 
> propogated along. This sounds like a separate PPPoE draft. 
> Anything defined here 
> would of course be transparent to PPPoE Relay. 
> 
> > 
> > Of course these thoughts are just suppositions.  What do 
> others think? 
> > 
> > Tom 
> > 
> > -----Original Message----- 
> > From: Reinaldo Penno 
> > To: 'W. Mark Townsley'; Mistretta, Tom 
> > Cc: 'Ron da Silva'; [email-masked]' 
> > Sent: 8/20/2001 5:55 PM 
> > Subject: RE: PPPoE Relay-Session-Id TAG (was Re: I-D 
> ACTION:draft-dasilva 
> > -l2tp-relaysvc-00.txt - Comments) 
> > 
> > Hello Tom/Mark, 
> > 
> > The draft says the LAC chooses the *relay-session-id*, not the 
> > session-id. Is that what you are talking about? The SESSION_ID is 
> > generated by the AC in the PADS message. 
> > 
> > thanks, 
> > 
> > > -----Original Message----- 
> > > From: W. Mark Townsley [ mailto:[email-masked] 
> > <mailto:[email-masked]> ] 
> > > Sent: Monday, August 20, 2001 12:12 PM 
> > > To: Mistretta, Tom 
> > > Cc: Ron da Silva; Penno, Reinaldo [SC9:T327:EXCH]; [email-masked]' 
> > > Subject: Re: PPPoE Relay-Session-Id TAG (was Re: I-D 
> > > ACTION:draft-dasilva-l2tp-relaysvc-00.txt - Comments) 
> > > 
> > > 
> > > 
> > > 
> > > > 
> > > > 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 
> > > 
>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 23 Aug 2001 08:38:24 +0200

On every single data packet between your LAC and LNS you have:

PPP
PPPoE (session id lookup)
Ethernet (MAX address lookup)
L2TP (session/tunnel lookup)
UDP
IP

vs.

PPP
L2TP (session/tunnel lookup)
UDP
IP

All just for a few lousy PAD packets at session startup? 

I am OK with L2TP tunneling ethernet for bridging applications where the
segments being connected need to be tunneled over IP. However, when you are
doing this *just* to deliver a handful of PAD packets, I don't think that the
header overhead and additional lookups at the LNS justify this.

Also, by transmitting over the L2TP Control channel, the PAD packets are
delivered reliably, reducing the possibility of requiring a PAD retransmit from
the host due to possible dropping of L2TP data.

Also, you don't have to setup an entire L2TP session just to relay the PADI/O
packets.

- Mark

> Vipin Jain wrote:
> [pppoe]  <------> [LAC pppoe/l2tp] <-------> [ pppoe termnation on LNS (AC) ]
> 
> IMHO we need to rethink this draft. I particulary do not like this session_id
> mechanism and the draft is too restrictive. Session_IDs should be defined by
> the AC only, we should not assume that the AC is a device "co-resident" with
> the LNS and we should assume that a tunnel switched network might exist
> between LAC and LNS. I prefer to find some other means to identify LNS, AC and
> clients that do not mess with the PPPoE protocol. Maybe some other AVPs in
> L2TP, MAC address, some other variable, etc.
> 
> thanks,
> -RP