RE: [L2tpext] Please comment on draft-galtzur-l2tpext-gr-01.txt

Sharon Galtzur <sharon@AXERRA.com> Sun, 11 January 2004 13:55 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28498 for <l2tpext-archive@lists.ietf.org>; Sun, 11 Jan 2004 08:55:40 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afg3T-0000si-Hh; Sun, 11 Jan 2004 08:55:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Afg35-0000rP-DM for l2tpext@optimus.ietf.org; Sun, 11 Jan 2004 08:54:39 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28402 for <l2tpext@ietf.org>; Sun, 11 Jan 2004 08:54:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Afg34-0005L0-00 for l2tpext@ietf.org; Sun, 11 Jan 2004 08:54:38 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Afg1A-0005Cg-00 for l2tpext@ietf.org; Sun, 11 Jan 2004 08:52:43 -0500
Received: from [80.74.100.67] (helo=antivir2) by ietf-mx with smtp (Exim 4.12) id 1AffvY-0004zI-00 for l2tpext@ietf.org; Sun, 11 Jan 2004 08:46:53 -0500
Received: from 192.168.254.14 by antivir2 (InterScan E-Mail VirusWall NT); Sun, 11 Jan 2004 15:45:26 +0200
Received: by TLV1 with Internet Mail Service (5.5.2653.19) id <Y3GCT2LW>; Sun, 11 Jan 2004 15:44:10 +0200
Message-ID: <AF5018AC03D1D411ABB70002A509132601085FEA@TLV1>
From: Sharon Galtzur <sharon@AXERRA.com>
To: "'Paul W. Howard'" <phoward@juniper.net>, "W. Mark Townsley" <townsley@cisco.com>
Cc: l2tpext@ietf.org
Subject: RE: [L2tpext] Please comment on draft-galtzur-l2tpext-gr-01.txt
Date: Sun, 11 Jan 2004 15:44:09 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: l2tpext-admin@ietf.org
Errors-To: l2tpext-admin@ietf.org
X-BeenThere: l2tpext@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=unsubscribe>
List-Id: Layer Two Tunneling Protocol Extensions <l2tpext.ietf.org>
List-Post: <mailto:l2tpext@ietf.org>
List-Help: <mailto:l2tpext-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=subscribe>

Hello all,
See my response in the mail body.

Sharon Galtzur

> -----Original Message-----
> From: Paul W. Howard [mailto:phoward@juniper.net]
> Sent: Friday, January 09, 2004 4:59 PM
> To: W. Mark Townsley
> Cc: l2tpext@ietf.org
> Subject: Re: [L2tpext] Please comment on 
> draft-galtzur-l2tpext-gr-01.txt
> 
> 
> I have a few questions/concerns in regards to this draft:
> 
> 1) This proposal presents what appears to be an entirely different 
> mechanism than that proposed in the v2 draft 
> (draft-vipin-l2tpext-failover-02.txt).   It would seem to be 
> important 
> that we attempt to have a single mechanism for both v2 and v3 
> or to at 
> least minimize the differences to those that are unavoidable.

In LDP there is exactly the same occurrence - 
RFC 3478: Graceful Restart Mechanism for Label Distribution Protocol 
RFC 3479: Fault Tolerance for the Label Distribution Protocol (LDP) 

This draft follows the model presented in RFC 3478 with adaptation to L2TPv3

> 
> 2) I don't understand the basic reset of the sequence number 
> space for 
> the control connection.   Is this setting up a replacement tunnel or 
> attempting to reset the sequence numbers of the extant tunnel?

The tunnel is restarted almost exactly as in
draft-ietf-l2tpext-l2tp-base-11.txt
One technical difference is the added AVP to advertise the graceful restart
capability.
Another difference is that while restarting the sessions certain information
need 
to endure the restart (i.e. Session ID, Cookie value etc) that will allow
the data path
to continue without interruptions.

> 
> 3) It would appear that there is a linear relationship between the 
> number of packets required for the fail over and the number of 
> established sessions.   This would seem to present issues 
> with scalability.

The behavior of the graceful restart proposal is not worse then normal start
of 
L2TPv3 (since the mechanism of the graceful and non graceful restart are
practically the same). 
If there is scalability issue in this proposal it is inherit to the whole
L2TP model and not restricted to 
the proposed graceful restart


> 
> Thanx,
> 
> Paul Howard
> 
> W. Mark Townsley wrote:
> 
> >
> > I would like to ask that interested parties review the 
> following draft 
> > "Layer Two Tunneling Protocol (Version 3) Graceful Restart" and 
> > provide comments to the list. This draft was originally 
> presented in 
> > Vienna, and updated based on comments during the meeting.
> >
> > http://www.ietf.org/internet-drafts/draft-galtzur-l2tpext-gr-01.txt
> >
> > The authors would like to make this a WG document.
> >
> > Thanks,
> >
> > - Mark
> >
> >
> > _______________________________________________
> > L2tpext mailing list
> > L2tpext@ietf.org
> > https://www1.ietf.org/mailman/listinfo/l2tpext
> >
> 
> 
> 
> _______________________________________________
> L2tpext mailing list
> L2tpext@ietf.org
> https://www1.ietf.org/mailman/listinfo/l2tpext
> 

_______________________________________________
L2tpext mailing list
L2tpext@ietf.org
https://www1.ietf.org/mailman/listinfo/l2tpext