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

From: "Vipin Jain" <[email-masked]>
Date: Tue, 10 Jul 2001 15:42:36 -0700

comment inline..

> > IMHO, I think it would be wise to allow SURQ and
> > SURP
> > for "zero session id" to identify similar
> > characteristics for all sessions in a tunnel..
> > Of course it would be optional, but can give
> > flexibility
> > and efficiency.. just in case ;)
> 
> That is an interesting suggestion ... may be we
> can add this to indicate a tunnel as such, which
> might be interpreted as all sessions within a
> tunnel. Do you have any specific application in
> mind for this?
Whenever a tunnel has an associated SLA...
implicitly there can be multiple sessions that can
come in on a particular tunnel (L2TP Tunnel for VPDNs probably?)

> 
> > 
> > thanks,
> > -- vipin
> > 
> 
> 
> =====
> -------
> Elwin Stelzer Eliazer
> Corona Networks
> -------
> 
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/
>

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 20 Jul 2001 17:42:42 -0700

A minor nit: in section 6.1, it says:

      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
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      the established state.

ICCNs _and_ OCCNs are sent only by LACs, which are the only ones that can
determine whether the call has been connected. A corrected version:

      ...
      In the case of an LNS, this message can be sent after receiving
      ICCN or OCCN. In the case of an LAC, this message can be sent
      after sending ICCN or OCCN.
      ...

At 03:47 PM 6/19/01 -0700, Elwin Eliazer wrote:
>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
>-------
>
>Spot the hottest trends in music, movies, and more.
>http://buzz.yahoo.com/
>