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

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

Elwin,

comments inline..

>> 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?
>
> SURQ and SURP should be capable of supporting
> additional extension AVPs, and that is left
> outside this draft. (see the next response)
I don't understand how can one ensure interoperability
among peers who happen to agree on certain AVPs

>> Are you referring to extentions that are defined in
>> some other draft/rfc?
>> 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).
yeah that would help..

> 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.
it wasn't implied anywhere.. Anyways, does it also imply
that LAC or LNS can't send the data unless SURQ, SURP
exchange is reliably done?

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 ;)

thanks,
-- vipin

---

From: Elwin Eliazer <[email-masked]>
Date: Tue, 10 Jul 2001 14:10:27 -0700 (PDT)

Vipin,

Responses inlined.

cheers,
Elwin.

> among peers who happen to agree on certain AVPs

The idea of LEX AVP is to know the capabilities of
the peer, during the tunnel setup itself, so that
both the ends need not send some surprise
AVPs to figure out the capability of the other end.
This way the capability of the peer is determined
at an earlier stage, and hence decision need not
be made on a per-AVP basis.

The SURQ and SURP messages are added as the first
item in the LEX AVP, so that a surprise SURQ/SURP
need not be sent.

I do not see any new interop issue caused by doing
this.

> exchange is reliably done?

The SURQ and SURP are not intended to change the
state machine ... they are meant to be used as
messages for changing default session characteristics.
We need to see if there is some special handling
needed for the IPSec case, but for all other cases it
appears to be fine.

> 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?

> -- vipin

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

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