Subject: Session update messages for L2TP ...

From: Elwin Eliazer <[email-masked]>
Date: Tue, 19 Jun 2001 15:47:20 -0700 (PDT)

Hi all,

Not sure if you got a chance to read the draft
mentioned below. We would appreciate to hear your
review comments on this. This draft emerged as a
result of some earlier discussions we had in this
list.

Thanks.

cheers,
Elwin.

A New Internet-Draft is available from the on-line
Internet-Drafts 
directories.

	Title		: L2TP Session Update Mechanism
	Author(s)	: N. Gowda, E. Stelzer, U. Sirsiwal
	Filename	: draft-naveen-l2tpext-sessupdate-00.txt
	Pages		: 5
	Date		: 11-Jun-01
	
Once a L2TP session is established, the current
standard [RFC 2661]
has no explicit mechanism to update the session
characteristics,
during the life of the session, between the L2TP
tunnel
endpoints. One such requirement for this mechanism is,
LNS informing
LAC about the PPP-user's service characteristics, so
that
user-specific service actions can be applied at LAC.
Eg: DSCP
marking.
There is a need for additional messages that will
address similar
requirements. Two additional messages are defined in
this draft for
this.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-naveen-l2tpext-sessupdate-00.txt

=====
-------
Elwin Stelzer Eliazer
Corona Networks
-------

__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 20 Jun 2001 10:47:18 -0400

Also sprach Elwin Eliazer
>Not sure if you got a chance to read the draft mentioned below. We
>would appreciate to hear your review comments on this. This draft
>emerged as a result of some earlier discussions we had in this list.

Couple of thoughts.

I don't see any inherent problems with the SURQ and SURP message types,
though I'm not sure I see a huge amount of usefulness for them either.
I guess getting a little usefulness out of them is worth considering
them though.

I am somewhat of the opinion that the L2TP Extension AVP should probably
be split off into a seperate draft since I'm not sure that it and the
new message types really depend on each other.  They each could have
usefulness in and of themselves without needing the other to be
effective.

I would also question the need for the L2TP Extension AVP at all.  We
can essentially accomplish the same thing by defining a new AVP for
whatever extension comes up.  It just changes the contention for
"namespace" from the bitmap defined in the LEX-AVP, to the AVP number.
*shrug*  I tend to think that using an AVP per extension provides extra
flexibility since you can include more than just a simple on-off state,
you can include parameters and values to control how the extension is
implemented.  With the M-bit set to 0 (which, of course, it should be),
it doesn't matter if the other end implements the extension...if it
doesn't implement it, it'll ignore it...if it does implement it, it'll
use it.

Of course...now I'm having some doubts about what I've said above...I'll
let what I've typed stand for the moment but reserve the right to change
my mind if other discussion shows me that I need to (quite possible).
:)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

---

From: Elwin Eliazer <[email-masked]>
Date: Thu, 21 Jun 2001 13:01:59 -0700 (PDT)

Jeff,

My responses inlined.

cheers,
Elwin.

--- Jeff Mcadams <[email-masked]> wrote:
> mentioned below. We

Consider the case where a user needs to be assigned
a particular DSCP (or any other user-specific IP
service profile) after user-authenication ... LNS
informing LAC on these. This we have discussed in
earlier thread of mails also.

> doesn't implement it, it'll ignore it...if it does

This AVP is useful, since the capabilities could be
understood at the earlier stage itself, rather than
assuming that and proceeding further and later
detecting that the other end does not support some
new AVP.

I do agree with you that the draft addresses two
different issues (the messages, and the extn AVP)
... and maybe it has to be split.

=====
-------
Elwin Stelzer Eliazer
Corona Networks
-------

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/