Subject: RE: [L2tpext] Question about LAC

From: Ignacio Goyret <[email-masked]>
Date: Tue, 14 May 2002 16:17:36 -0700

There is no such thing as a "ZLB ACK of a <fill-in_any_command>".
ZLB ACKs are part of the reliable delivery mechanism and are 100%
independent of any command.

ZLB ACKs are sent on the control channel. As such, they must follow
all the applicable rules for control messages, including setting
the tunnel and session id properly. The only commands that require
session id to be non-zero are ICRP, ICCN, OCRP, OCCN, SLI and WEN.
The CDN itself may or may not have a valid session id.
All other commands should have session id set to zero because they
are not session level commands.

At 01:27 PM 5/14/02 -0700, Jayant Jain wrote: 
>
>In the ZLB ack of a CDN message , should the session id be present
>in the header or should it be set to 0 

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: Kiran Brahmandam <[email-masked]>
Date: Fri, 17 May 2002 14:27:24 -0700

I have a question on Host Name AVP (RFC 2661). I'll appreciate if
someone can clarify it to me.

The Host Name AVP is exchanged during tunnel established. But if  the
HostName of the LAC/LNS is changed after the tunnel is established, then
do we need to inform the peer about this HostName change??.

Thanks in advance
Kiran

---

From: Motonori Shindo <[email-masked]>
Date: Mon, 20 May 2002 11:54:49 +0900 (JST)

Kiran,

From: Kiran Brahmandam <[email-masked]>
Subject: [L2tpext] Question about LAC/LNS Host Name AVP
Date: Fri, 17 May 2002 14:27:24 -0700

> do we need to inform the peer about this HostName change??.

I don't think it's necessary. Because Host Name attribute only shows
up in tunnel establishment phase (i.e. SCCRQ and SCCRP), it doesn't
play any role after the tunnel is established. 

Furthermore, in the current standard, there's no way to inform the
peer of such an event unless you invent a vendor-specific attribute to
do that.

If you see any reason we should do that, let's bring it up here and
call for open discussion.

Regards,

=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
 +----+----+     
 |.. .|    |     Motonori Shindo
 |_~__|    |     
 | .. |~~_~|     Sr. Systems Engineer
 | .  |    |     CoSine Communications Inc.
 +----+----+     
 C o S i n e     e-mail:  [email-masked] 
Communications
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=