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

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

Hi Ron,

Was reading the draft again and have a doubt. when you have several ACs
after a LNS, how do you deal with the relay-session-ID so that clients can
distinguish between several ACs?

thanks,

Reinaldo

> -----Original Message-----
> From: Penno, Reinaldo [SC9:T327:EXCH] 
> Sent: Friday, August 10, 2001 3:07 PM
> To: 'Ron da Silva'
> Cc: [email-masked]'
> Subject: RE: I-D ACTION:draft-dasilva-l2tp-relaysvc-00.txt - Comments
> 
> 
> 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: "Reinaldo Penno" <[email-masked]>
Date: Mon, 13 Aug 2001 10:32:06 -0700

I was more into changing L2TP. I mean, since we are going to introduce these
new two AVPs, we could introduce whatever is necessary to cover the
situations we discussed.

-Reinaldo

> From: W. Mark Townsley [mailto:[email-masked]]
> Sent: Monday, August 13, 2001 10:23 AM
> Cc: 'Ron da Silva'; [email-masked]'
> Subject: Re: I-D ACTION:draft-dasilva-l2tp-relaysvc-00.txt - Comments
> 
> 
> 
> > Reinaldo Penno wrote:
> > 
> > Mark,
> > 
> > based on your rant, how about we put some text in place 
> specifying all these
> > situations (tunnel switching, several ACs, etc)and how they 
> would be handled,
> > and if needed make the appropriate extensions to whatever protocol?
> 
> Specifying each situation is a good thing of course. As for 
> modifying PPPoE,
> since it is already deployed in umpteen pieces of software, 
> CPEs, appliances,
> etc. I would rather find something that worked with the 
> marjority of what is
> already available vs. waiting on a software revision and update. 
> 
> Thanks,
> 
> - Mark
> 
> > 
> > regards,
> > 
> > Reinaldo
> > 
> > > From: W. Mark Townsley [mailto:[email-masked]]
> > > Sent: Monday, August 13, 2001 10:01 AM
> > > Cc: 'Ron da Silva'; [email-masked]'
> > > Subject: Re: I-D 
> ACTION:draft-dasilva-l2tp-relaysvc-00.txt - Comments
> > >
> > >
> > >
> > >
> > > > Reinaldo Penno wrote:
> > > >
> > > > Hello Mark,
> > > >
> > > > > 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.
> > > >
> > > > Exactly. I think we will not manage to get away with the
> > > relay without a
> > > > mechanism to know the path (something like the loop
> > > prevention AVP), unless we
> > > > blast all messages to all tunnels.
> > >
> > > The tunnels for which we blast messages to will need to 
> be limited by
> > > configuration, with definite recommendations to keep this
> > > number to one when at
> > > all possible.
> > >
> > > >
> > > > We can change 2516 to allow more than one relay-session-id,
> > > but I would prefer
> > > > something in L2TP.
> > >
> > > I don't think we need more than one ID if we keep the ID of
> > > local significance
> > > between any two devices.
> > >
> > > > If I'm not mistaked, 2516 follows the same relaying model
> > > > as DHCP, where if you already have a relay-host entry, you
> > > cannot add a second
> > > > one.
> > >
> > > <rant>
> > >
> > > It is hard to know what model 2516 follows with only a couple
> > > of easily
> > > misinterpreted paragraphs for the entire feature stuck at the
> > > end of the
> > > document in the Appendix under an optional TAG TLV
> > > description. But, these days
> > > "shorter" specifications are deemed "better" and pass through
> > > the process faster
> > > so who can blame the authors.
> > >
> > > </rant>
> > >
> > > I consider the Relay-Session-ID analogous to the "xid" in
> > > DHCP. From RFC2131:
> > >
> > >   xid           4  Transaction ID, a random number chosen by the
> > >                    client, used by the client and server 
> to associate
> > >                    messages and responses between a client and a
> > >                    server.
> > >
> > > While we are at it, let's compare PPPoE's IDs with DHCP.
> > >
> > > In DHCP you typically always have 3 entities: the Host, the
> > > Relay Agent, and the
> > > DHCP server (perhaps more than one if you configure more than
> > > one helper
> > > address). The Client ID (typically forwarded intact from the
> > > host by the relay
> > > agent) and the giaddr (inserted by the Relay Agent) are the
> > > typical basic pieces
> > > of information used to instruct the DHCP server as to what
> > > parameters to assign
> > > to the host and to keep up with the lease itself. The "xid"
> > > is used to match the
> > > individual transactions.
> > >
> > > The Client ID (often a MAC address) may actually be
> > > programmed in the DHCP
> > > server itself, and is more analogous to the PPPoE source MAC
> > > address that is
> > > forwarded intact in the PPPoE PAD Relay AVP. The PPPoE
> > > relay-session-ID does not
> > > have a similar property here. That is, I don't think the
> > > PPPoE AC, or any server
> > > that it consults for service advertisements, will key upon
> > > the Relay-Session-ID
> > > (at least I truly hope not).
> > >
> > > That said, even DHCP plays games with the Client ID when need
> > > be as well. For
> > > instance, DHCP proxy for access servers does not have a Host
> > > MAC address for
> > > Client ID identification available, so a combination of IP
> > > address, userid, etc.
> > > is typically used so that the DHCP server can keep track of
> > > leases. The DHCP
> > > server doesn't care that what is in the Client ID is a MAC
> > > address or some
> > > munged text, it is just an opaque blob that is probably
> > > hashed and stored in a
> > > lookup table. So, even if the Relay-Session-ID were to be
> > > considered analogous
> > > to the DHCP Client ID in some respects, we have deployed
> > > examples in general of
> > > how games are sometimes played by agents to fool the next
> > > participant in the
> > > relay when there is not enough information to fully play 
> by the rules.
> > >
> > > - Mark
> > >
> > > >
> > > > -Reinaldo
> > > >
> > > > >
> > > > > >
> > > > > > -ron
> > > > > >
> > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > Ron da Silva                          [email-masked]
> > > > > > Network Architect                    703.265.4548
> > > > > > America Online, Inc.
> > > > > > A wholly owned subsidiary of AOL Time Warner Inc.
> > > > >
> > >
>