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

From: Keyur Parikh <[email-masked]>
Date: Tue, 15 May 2001 15:37:18 -0400

-----Original Message-----
From: Bill Baumann [mailto:[email-masked]]
Sent: Tuesday, May 15, 2001 3:15 PM
To: [email-masked]
Subject: Re: SLI from LNS to LAC ...

I've thought that SLI was of questionable value.

Shouldn't the LAC be involved in the negotiation of the physical
parameters (ACCM, MRU, and Alternate FCS) rather than relying on the LNS
and client to decide values the LAC will use?

Wouldn't it work to have the LAC sit in the middle of the LCP
negotiations, intercepting and rejecting CONF REQ messages that are
unacceptable to it?  It would also monitor for CONF ACKs and use that
information instead of relying on SLI.
<KRP> I think the draft is very useful, the method you propose puts too much
burden on the LAC data path - specially when the LAC is suppose to be
"transparent" to PPP negotiations.

I'm curious what parameters might go the opposite direction.  I imagine a
more sophisticated LAC having such needs.

Bill

On Tue, 15 May 2001, W. Mark Townsley wrote:

> 
> 
> Keyur Parikh wrote:
> > 
> > How about negotiated FCS (RFC 1570) from LNS to LAC.
> 
> I believe alternate FCS was deprecated by pppext, but if you still need
> this, please look at:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-link-01.txt
> 
> > 
> > -----Original Message-----
> > From: W. Mark Townsley [mailto:[email-masked]]
> > Sent: Tuesday, May 15, 2001 1:17 PM
> > To: Elwin Eliazer
> > Cc: [email-masked]
> > Subject: Re: SLI from LNS to LAC ...
> > 
> > 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/
> 
>

---

From: "Chen, David" <[email-masked]>
Date: Wed, 16 May 2001 09:52:41 -0400

Elwin,

The layered network structure has been used for long time.
It will be very difficult for "networking" if
the comm stack collapsed.

I don't think L2tp knows DH key exchange (may not be a bad idea)
or PPP's ACCM or RSVP, RTP signaling ... who knows what's the payload in
IP... :-)

--- David

-----Original Message-----
From: Elwin Eliazer [mailto:[email-masked]]
Sent: Tuesday, May 15, 2001 11:42 PM
To: W. Mark Townsley
Cc: [email-masked]
Subject: 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.

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

---

From: "Umesh Sirsiwal" <[email-masked]>
Date: Wed, 16 May 2001 12:02:08 -0400

Chen, Elwin, Mark, et.al.
I do agree that we must "try to" preserve common
networking stack. draft-ietf-l2tpext-ds-03.txt,
and draft-ietf-l2tpext-security-02.txt adress 
some of the functionality needed for IPSec and DiffServ.

However, I agree with Elwin in spirit. We need
a way of modifying tunnel attributes without 
tearing down tunnel. For example draft-ietf-l2tpext-ds-03.txt
addresses issues with respect to DSCP used.
However, the DSCP usage may change because of
administrative policies on LNS end and it must
inform LAC about it. Similar arguments can be
made regarding draft-ietf-l2tpext-l2tphc-03.txt.
This can also be used for controlled de-commissioning
of LNS, in case LNS is capable of sharing state 
information with another LNS.

Current form of L2TP addresses issues with respect
to tunnel establishment and teardown. However,
it does not really adress issues with respect to
change in attributes of an existing tunnel.

-Umesh

-----Original Message-----
From: Chen, David [mailto:[email-masked]]
Sent: Wednesday, May 16, 2001 9:53 AM
To: 'Elwin Eliazer'; W. Mark Townsley
Cc: [email-masked]
Subject: RE: SLI from LNS to LAC ...

Elwin,

--- David

-----Original Message-----
From: Elwin Eliazer [mailto:[email-masked]]
Sent: Tuesday, May 15, 2001 11:42 PM
To: W. Mark Townsley
Cc: [email-masked]
Subject: Re: SLI from LNS to LAC ...

Mark,

regards,
Elwin.

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

---

From: "Chen, David" <[email-masked]>
Date: Wed, 16 May 2001 12:29:59 -0400

With the spirit of modifying L2tp attributes,
the IPSec's SA does not present in the "l2tp attributes",
So is "QoS".

Each of the topic (Sec, QoS) is another set of IP service protocols.
What the degree you suggest to let L2tp involved.

Also, the reliable connection can be solved in several level
from physical layer to IP layer or above.

If you implement Redudant Routing Protocol (which still having issues)
to keep the same IP among several different LNS...

--- David

-----Original Message-----
From: Umesh Sirsiwal [mailto:[email-masked]]
Sent: Wednesday, May 16, 2001 12:02 PM
To: [email-masked]
Subject: FW: SLI from LNS to LAC ...

-Umesh

-----Original Message-----
From: Chen, David [mailto:[email-masked]]
Sent: Wednesday, May 16, 2001 9:53 AM
To: 'Elwin Eliazer'; W. Mark Townsley
Cc: [email-masked]
Subject: RE: SLI from LNS to LAC ...

Elwin,

--- David

-----Original Message-----
From: Elwin Eliazer [mailto:[email-masked]]
Sent: Tuesday, May 15, 2001 11:42 PM
To: W. Mark Townsley
Cc: [email-masked]
Subject: Re: SLI from LNS to LAC ...

Mark,

regards,
Elwin.

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

---

From: "Umesh Sirsiwal" <[email-masked]>
Date: Wed, 16 May 2001 19:23:38 -0400

Thanx Mark,
I will write a draft for a message type. I am sure
Elwin wants to be co-author for it... Does anybody else
want to contribute on this?

-Umesh

-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]]
Sent: Wednesday, May 16, 2001 1:17 PM
To: Umesh Sirsiwal
Cc: Chen, David; [email-masked]
Subject: Re: SLI from LNS to LAC ...

There is nothing wrong with sending a message after tunnel/session
setup, just define the message type in a draft. There is certainly
precedence for sending a message after tunnel/session establishment. SLI
and WEN both work in this manner.

- Mark

Umesh Sirsiwal wrote:
> 
> David,
> 
> We already have draft in L2TP working group which allows
> LAC/LNS DSCP negotiation. We also have draft for header
> compression. I am not proposing any new AVP. I am proposing
> capability to change already negotiated AVP if conditions
> change on ends. I do agree that there is no new attributes
> needed for IPSec.
> 
> With respect to redundant router protocol, as you said
> redundant routing protocol has its own issues and there
> is a merit in transferring L2TP tunnels to another
> router in a controlled basis.
> 
> I am not proposing any NEW violation of layering principles
> just capability to modify existing AVP even after tunnel is
> established...
> 
> -Umesh
> 
> Sent: Wednesday, May 16, 2001 12:30 PM
> To: Umesh Sirsiwal; [email-masked]