Subject: AW: SLI from LNS to LAC ...

From: Klausberger Walter <[email-masked]>
Date: Wed, 16 May 2001 11:37:46 +0200

Hi Elwin,

I'm a bit confused about turning on and off of ML-PPP based on
authentication.

ML-PPP capability is negotiated in LCP phase (before authentication). If the
LNS allows no further link (depending on user profile) it can simply reject
them during authentication phase of these additional links. Sure the LAC
would accept the link and forward it through the tunnel first, but the LNS
would terminate the session immediately after recognizing it.

If I tell the LAC that this user is not allowed to have a further link, the
LAC would have to recognize the user of the incomming PPP session. This may
be possible when the LAC forwards the session depending on the user name,
but in other cases (like forwarding depending on the DNIS) it may not. And I
do not think that PPP sniffing in the LAC is a good idea to find the
username in this case.

So I agree with Mark that the LAC shouldn't care...

Comments are welcome
regards,
- Walter

> -----Ursprüngliche Nachricht-----
> Von: Elwin Eliazer [mailto:[email-masked]]
> Gesendet am: Mittwoch, 16. Mai 2001 05:42
> An: W. Mark Townsley
> Cc: [email-masked]
> Betreff: Re: SLI from LNS to LAC ...
> 
> Mark,
> 
> The cases when LNS needs to inform LAC after
> authentication phase some characteristics that
> are based on user, will need additional messages.
> One such requirement is the conveying the user
> based IP service information to LAC, so that LAC
> can take appropriate actions, like QOS and IPSec. 
> 
> Another requirement is: MLPPP can be turned on
> or off by LNS based on authentication information;
> which cannot be sent to LAC as of now.
> 
> Acknowledgments to these may be needed for some
> cases from LAC to LNS.
> 
> regards,
> Elwin.
> 
> --- "W. Mark Townsley" <[email-masked]> wrote:
> > 
> > WEN is currently the only "after session
> > establishment" message defined
> > for receipt by an LNS. New messages are not
> > difficult to create though.
> > What type of information would you like to signal?
> > 
> > - Mark
> > 
> > Elwin Eliazer wrote:
> > > 
> > > Hi,
> > > 
> > > Are there any standard way of changing the
> > > characteristics of a L2TP tunnel/session
> > > after the tunnel/session setup is complete?
> > > 
> > > SetLinkInfo (SLI) PDU defined in RFC 2661,
> > > section 6.4 can only be used by LNS to
> > > inform LAC. Are there any methods like that
> > > from LAC to LNS?
> > > 
> > > Your response would be appreciated.
> > > 
> > > regards,
> > > Elwin.
> > > 
> > > =====
> > > -------
> > > Elwin Stelzer Eliazer
> > > Corona Networks
> > > San Jose, CA
> > > 408-519-3832
> > > -------
> > > 
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Yahoo! Auctions - buy the things you want at great
> > prices
> > > http://auctions.yahoo.com/
> 
> 
> =====
> -------
> Elwin Stelzer Eliazer
> Corona Networks
> San Jose, CA
> 408-519-3832
> -------
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - buy the things you want at great prices
> http://auctions.yahoo.com/
>

---

From: Elwin Eliazer <[email-masked]>
Date: Wed, 16 May 2001 14:07:17 -0700 (PDT)

Hi Walter,

Is it not a good idea to terminate MLPPP at the LAC,
if LAC is capable of doing that, and then pass it
as a single PPP session to LNS?

cheers,
Elwin.

--- Klausberger Walter <[email-masked]>

=====
-------
Elwin Stelzer Eliazer
Corona Networks
San Jose, CA
408-519-3832
-------

---

From: Bill Baumann <[email-masked]>
Date: Wed, 16 May 2001 15:11:20 -0700 (PDT)

Hello Elwin,

One the benefits of L2TP is to allow MLPPP to function in very large modem
pools where dial-in access is spread over a multitude of machines.  If two
calls of MLPPP session arrive on two different LACs, the LNS can still
combine them if it does the termination.

Unfortunately, some vendors do not support MLPPP in the LNS.  (According
to Redback's tech support, they do not support it.)

Bill