Re: [Softwires] WG LC softwire-lb
Carlos Pignataro <cpignata@cisco.com> Wed, 29 April 2009 15:22 UTC
Return-Path: <cpignata@cisco.com>
X-Original-To: softwires@core3.amsl.com
Delivered-To: softwires@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CCB03A67F3; Wed, 29 Apr 2009 08:22:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.262
X-Spam-Level:
X-Spam-Status: No, score=-6.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tB1MBWoEcw4U; Wed, 29 Apr 2009 08:22:17 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 1E3063A715A; Wed, 29 Apr 2009 08:22:16 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n3TFNbX4025253; Wed, 29 Apr 2009 11:23:37 -0400 (EDT)
Received: from [64.102.157.114] (dhcp-64-102-157-114.cisco.com [64.102.157.114]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n3TFNaJe023981; Wed, 29 Apr 2009 11:23:37 -0400 (EDT)
Message-ID: <49F870F8.9070301@cisco.com>
Date: Wed, 29 Apr 2009 11:23:36 -0400
From: Carlos Pignataro <cpignata@cisco.com>
Organization: cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: robert@raszuk.net
References: <5EE53708-2D8B-4DFB-8365-27041AACB0BE@cisco.com> <49F178ED.2080905@raszuk.net>
In-Reply-To: <49F178ED.2080905@raszuk.net>
X-Enigmail-Version: 0.95.7
X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+, Z+jj`4%06nd'y9[ln&ScJT5S+O18e^
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: l3vpn@ietf.org, Clarence Filsfils <cfilsfil@cisco.com>, Ralph Droms <rdroms@cisco.com>, Alain Durand <Alain_Durand@cable.comcast.com>, pwe3@ietf.org, softwires@ietf.org
Subject: Re: [Softwires] WG LC softwire-lb
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Apr 2009 15:22:18 -0000
Hi Robert, Thank you for your comments, please see inline. On 4/24/2009 4:31 AM, Robert Raszuk wrote: > Hi David, > > Perhaps I may have missed the discussion on this in the other WGs but I > have two comments/questions ... > > * Why the decision on enhancing the load balancing capability of IP > encapsulated packet has to be signaled as opposed to be a local matter > of the ingress router performing encapsulation ? This is because the load-balancing field is signaled (see RFC5512), so using for lb it needs signaling of a block to avoid collisions. Note also the context from the title, lb for Mesh Softwires. For the L2TPv3 case, and from <http://tools.ietf.org/html/rfc5512#section-4.1>, the only encapsulating header field that is always there is the Session ID (Cookie is optional), which is signaled; the case for GRE is equivalent, but also please see below. If it's only a local matter, the encapsulating header's fields could not be used and you would be limited to playing with e.g., the source IP address. > > * Reg use of GRE key for the purpose of load balancing I must say that > GRE key has already been proposed in number of solutions today. Therefor > overloading more on it may be impractical. Did authors analyzed use of > Sequence Numbers in GRE header instead for the purpose of increasing > effectiveness of load-balancing by the transit nodes ? Yes, it was considered, but we need a field that can be used for flow identification. From RFC2890, the seq # MUST be used by the receiver to establish packet transmission order, so it's incompatible with a per-flow use. The GRE Key's semantics from RFC2890 match this use, <http://tools.ietf.org/html/rfc2890#section-2.1>: The Key field contains a four octet number which was inserted by the encapsulator. The actual method by which this Key is obtained is beyond the scope of the document. The Key field is intended to be used for identifying an individual traffic flow within a tunnel. Thanks, -- Carlos. > > Cheers, > R. > > >> All - >> Following the last IETF meeting all comments have been addressed in: >> >> http://tools.ietf.org/html/draft-ietf-softwire-lb-02 >> >> The authors have requested a WG LC and I have added L3VPN and PWE3 that >> may be interested and have comments on the technology. Please send back >> all comments by May 7, 2009. >> >> Thanks >> >> DWard, Alain > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >
- [Softwires] WG LC softwire-lb David Ward
- Re: [Softwires] WG LC softwire-lb Robert Raszuk
- Re: [Softwires] WG LC softwire-lb Carlos Pignataro
- Re: [Softwires] WG LC softwire-lb Robert Raszuk
- Re: [Softwires] WG LC softwire-lb Carlos Pignataro