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

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 13 Aug 2001 10:15:49 -0700

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?

regards,

Reinaldo

> -----Original Message-----
> From: W. Mark Townsley [mailto:[email-masked]]
> Sent: Monday, August 13, 2001 10:01 AM
> To: Penno, Reinaldo [SC9:T327:EXCH]
> 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.
> > >
>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 13 Aug 2001 19:22:56 +0200

> 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