Subject: RE: Session update messages for L2TP ...

From: "Vipin Jain" <[email-masked]>
Date: Fri, 6 Jul 2001 03:07:59 -0700

Elwin,

comments inline..

> 5.0 Introduction
> 
>     Following additional messages are defined to exchange session
>     characteristics:
> 
>       Session-Update-Request (SURQ)
> 
>       Session-Update-Reply (SURP)
> 
>     The SURQ is sent either from LAC to LNS or LNS to LAC. On receiving
>     this the recipient responds by sending SURP. SURP contains the
>     recognized and processed AVPs from SURQ.
> 
>     These messages can be used for user-specific service information to
>     be exchanged between LAC and LNS, even after the session is
>     established.
shouldn't last para be:
"These message SHOULD be used for user-specific service
information to be exchanged between LAC and LNS, ONLY after
session is established"

> 6.0 Session Characteristics Update Messages
> 
> 6.1 Session-Update-Request (SURQ) Message
> 
>     The Session-Update-Request is sent by the LNS/LAC to update peer
>     regarding session parameters. SURQ message is sent only after
>     session establishment is successful. In case of LNS this message can
>     be sent after receving ICCN or sending OCCN, and the session
>     reaching the established state. In case of LAC this message can be
>     sent after sending ICCN or receiving OCCN, and the session reaching
> 
> 
> 
> Naveen, et al.                                                  [Page 2]
> 

> INTERNET-DRAFT          L2TP Session Update Mechanism          June 2001
> 
> 
> 
>     the established state.
> 
>     Recipient MUST be able to update its session information, if
>     required be, based on SURQ.
> 
>     The attribute value for Message Type AVP is TBD. The Mandatory bit
>     for this AVP MUST be Zero, so that the session can continue even
>     when the peer can not recognize this message.
>     Other existing or new AVPs can be added to the list of optional AVPs
>     in this message as and when required.
> 
>     The following AVPs MUST be present in the SURQ:
>       Message Type
> 
> 6.2 Session-Update-Reply (SURP) Message
> 
>     The Session-Update-Reply is sent by LAC/LNS to inform the peer about
>     the acceptance of the information in SURQ received earlier.  SURP
>     contains the recognized and processed AVPs in the same order as
>     received in SURQ.
> 
>     Recipient MUST be able to update its session information, if
>     required, based on SURP.
> 
>     The attribute value for Message Type AVP is TBD and the Mandatory
>     bit for this AVP MUST be Zero. Other existing or new AVPs can be
>     added to the list of optional AVPs in this message as and when
>     required.
> 
>     The following AVPs MUST be present in the SURP:
>       Message Type
> 
SURQ and SURP doesn't include any AVP that explains the capability of a
session. What is the use of sending LEX-AVP alone in SCCRQ etc. messages
then?

> 7.0 L2TP Extension AVP (LEX-AVP)
> 
>     The L2TP Extesion AVP, Attribute Type TBD, describe the L2TP
>     extension support capability of a system. This AVP can be sent in
>     SCCRQ and/or SCCRP messages.
> 
>     Tunnel initiator can send this AVP to indicate to the peer regarding
>     the extensions it supports and peer can also send its extension
>     support through this AVP in SCCRP. After processing this AVP both
>     the system can learn about the peer's capability to support
>     different L2TP extensions and behave based on the results.
Pardon my ignorance:
Are you referring to extentions that are defined in some other draft/rfc?
Where are the definitions of extensions defined?

> 
> 
> 
> 
> 
> 
> 
> 
> 
> Naveen, et al.                                                  [Page 3]
> 
> INTERNET-DRAFT          L2TP Session Update Mechanism          June 2001
> 
> 
> 
> 
> 
> 
>      0                 1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |M|H|0|0|0|0|    Length         |            Vendor ID          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |        Attribute Type         |             L2TP  ...

>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        ... Extension Capabilities   |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>     M bit MUST be set to 0 and this AVP can be hidden (H-bit set to 0 or
>     1). Length (before hiding) is 10 octets. Vendor ID is TBD.
>     Attribute Type is 2 octet in length and its value is TBD. The L2TP
>     Extension Capabilities field is a 32-bit bit-map representing the
>     list of L2TP extensions supported. Each bit corresponds to one L2TP
>     extension, and the bit being set indicates the appropriate extension
>     is being supported. This also implies all the unallocated bits to be
>     cleared. The extensions mentioned in this draft uses the bit-0 in
>     this field. So, any implementation supporting this draft, needs to
>     have bit-0 set.
> 
> 
> 8.0 Summary and Conclusions
> 
>     It is possible to change the session parameters during the life of
>     session without restarting the session, using the SURQ and SURP
>     messages. The LEX-AVP can be used to inform the peer about the list
>     of supported L2TP extensions.
How can exchanging 32bit map allow exchanging the session parameters?
Where are the parmeters exchanged in SURQ and SURP?

> 
> 
> 9.0 IANA Considerations
>     
>     Should this document advance on as standards track official
>     attribute values need to be assigned for the LEX-AVP. Also message
>     type needs to be assigned for SURQ and SURP.
> 
> 
> 10.0 Security Considerations
>  
>     This document does not introduce any new security issues beyond
>     those inherent in L2TP, and may use the same mechanisms proposed for
>     those technologies, where applicable.

There is no explanation about what happens to the data flows when say DSCP
is
changed; for example:

LAC                 LNS
  SURQ   --->    valid SURQ (gets some DSCP value from this, act on it now?)
         <----   Send SCRP (or act on that DSCP now?)
 ZLB     ---->   or act on that now?

thanks,
-- vipin

-----Original Message-----
From: Elwin Eliazer [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 3:47 PM
To: [email-masked]
Subject: Session update messages for L2TP ...

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: Elwin Eliazer <[email-masked]>
Date: Mon, 9 Jul 2001 16:17:41 -0700 (PDT)

Vipin,

Thanks for your comments.
My responses are inlined.

regards,
Elwin.

> information to be exchanged between LAC and LNS,

We will make this change.

> > Naveen, et al.                                    
>              [Page 2]

SURQ and SURP should be capable of supporting
additional extension AVPs, and that is left
outside this draft. (see the next response)

> Where are the definitions of extensions defined?

May be it must be reworded more clearly.
The "IP services over L2TP" draft, submitted
recently by Naveen and me, describe two such
extensions (for IPSec and QOS).

> > Naveen, et al.                                    
>              [Page 3]
> >      0                 1                   2      
>             3
> Where are the parmeters exchanged in SURQ and SURP?

The purpose of LEX AVP is just to understand the
peer's capability to support an L2TP extension or
not, apriori. It is not meant to be used in SURQ and
SURP to obtain and user-specific service information.

>  ZLB     ---->   or act on that now?

The SURQ generating node should apply only after
receiving SURP. The recepient of SURQ should start
acting on it, as soon as it had sent a positive
SURP. Though LAC to LNS for SURQ is also fine, as
you have shown above, LNS to LAC is the most common
case that we expect.

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

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