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

From: Klausberger Walter <[email-masked]>
Date: Wed, 6 Jun 2001 19:20:21 +0200

Hi Elwin,

Sorry, I have been on vacation and so it took some time to answer.

I've been discussing this matter with James Carlson some time ago. The idea
of terminating MLPPP in the LAC seems to be a good idea at first. I called
that thing 'MLPPP to Tunnel proxy'. When you look at it in detail you see
some problems especially with BAP/BACP, Callback, bundles with mixed link
types and many other things. Maybe it could work with an intelligent LAC
(needs performance) and a restricted feature set.

I am open minded for this issue and maybe this is something we should
discuss in detail. In the PPPEXT group James Carlson is working on a draft
(load balancing) that is some kind of restricted MLPPP. Maybe this at least
could be supported by a LAC without having to much impact on existing LNS.

regards
Walter  

> -----Ursprüngliche Nachricht-----
> Von: Elwin Eliazer [mailto:[email-masked]]
> Gesendet am: Mittwoch, 16. Mai 2001 23:07
> An: Klausberger Walter
> Cc: [email-masked]
> Betreff: Re: AW: SLI from LNS to LAC ...
> 
> 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]>
> wrote:
> > 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/
> > > 
> 
> 
> =====
> -------
> 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: "W. Mark Townsley" <[email-masked]>
Date: Wed, 06 Jun 2001 14:27:22 -0500

> could be supported by a LAC without having to much impact on existing LNS.

When I have looked at this in the past, it seemed that the LAC could
play all the tricks it wanted to with local bundling of MLPPP without
the LNS knowing, and without modification of L2TP.

Note that, sometimes, you may actually want to send your member links to
another box. Remember that one of the early applications of PPP
tunneling was Multichassis-Multilink PPP. This doesn't mean you have to
send all member links to the final LNS, (you could still bundle the
sessions on an intermediate tunneling node) but it is one possibility.
The "Try Another Directed" AVP in the l2tp-security and l2tpbis drafts
define a way to direct the LAC to send a session to another LNS, which
could be helpful for efficient MLPPP bundling.

- Mark