Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG

Satoru Matsushima <satoru.matsushima@gmail.com> Wed, 27 June 2012 02:20 UTC

Return-Path: <satoru.matsushima@gmail.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA3511E80FD for <softwires@ietfa.amsl.com>; Tue, 26 Jun 2012 19:20:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.407
X-Spam-Level:
X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2ZRE8I1xTXT for <softwires@ietfa.amsl.com>; Tue, 26 Jun 2012 19:20:36 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D0CFA11E80EF for <softwires@ietf.org>; Tue, 26 Jun 2012 19:20:35 -0700 (PDT)
Received: by dacx6 with SMTP id x6so697993dac.31 for <softwires@ietf.org>; Tue, 26 Jun 2012 19:20:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=m2M3SXMghSvfUC4ZO/MgKFQi/Ns2fPDEwTV573WwXX4=; b=r5JvEKAzsBzykhUO1ScxQlzZqWeIKag8g5e9+vvInGwPMHia2mS7IvzbjjmnB91hmc R7IYW+e7F/cFhe3hYmRp9mAMxOAuqynvoFZPJ3O8908DwrFPdrRLjw0JqBQTMSdxLq5m UcPgYg7ann8Khcku34ulMYWGlAOgQ4e/CRfh1F2JgxdRPLtfmSs7z9/L2Fxa/iUksMAp RQMc33a3JhUYuL5BaAGOpnwSeRPqs8IzlpADCMDI20IUP7Mj5+4EkkWRSHTll/zL8+Wx 3Lf30XCVcfEqi8O2NZJ854Gj1Rcr9HT9j3zcgqKVThAFSshnvb5MTnNEWYCOdtuYBEh0 1pTg==
Received: by 10.68.222.40 with SMTP id qj8mr57439173pbc.139.1340763635475; Tue, 26 Jun 2012 19:20:35 -0700 (PDT)
Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id he9sm13590780pbc.68.2012.06.26.19.20.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 19:20:34 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="iso-8859-1"
From: Satoru Matsushima <satoru.matsushima@gmail.com>
In-Reply-To: <CAFUBMqURHk_AJfaTmx0vVJVuVFL0QaKZp15p=fZXX+Ftpf50cg@mail.gmail.com>
Date: Wed, 27 Jun 2012 11:20:30 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <C41CE132-8C42-4898-B2DF-43BBFAE89515@gmail.com>
References: <CC0F2D82.285F4%ian.farrer@telekom.de> <CAFFjW4ireDBzacCFDYgh3kn3+MXx1=m3Kab6Wp7TFwnHeyfwDw@mail.gmail.com> <CAH3bfADW1LN5nr1trd+Hu0tu4R3cHNEcx5yppN4p4Rh1bHaq1w@mail.gmail.com> <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> <CAFUBMqURHk_AJfaTmx0vVJVuVFL0QaKZp15p=fZXX+Ftpf50cg@mail.gmail.com>
To: Maoke <fibrib@gmail.com>
X-Mailer: Apple Mail (2.1278)
Cc: softwires@ietf.org, ian.farrer@telekom.de
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 27 Jun 2012 02:20:36 -0000

Hi Maoke,

On 2012/06/27, at 10:48, Maoke wrote:

> dear Satoru, 
> 
> 2012/6/26 Satoru Matsushima <satoru.matsushima@gmail.com>
> On 2012/06/27, at 0:11, Qiong wrote:
> 
> > Agree with Ian.
> >
> > MAP is designed and optimized for algorithmatic address mapping, but not for per-subscriber rule mapping. Actually, the more you would like to solve, more complicated it will become.
> >
> > I will certainly not buy MAP for per-subscriber case when MAP-T, MAP-E, map-dhcp all becomes useless or not optimized. And I will not deploy per-subscriber stateful and stateless solutions at the same.
> >
> > So I encourage two seperated approaches optimized for different scenarios. It will be good for both.
> >
> > Do we really all forget about the "KISS" principle ?
> 
> Not quite.
> I believe that the most motivate to start this work in the wg has destined MAP to be 'multi-protocol socket v2.0' that's what the former wg chair wished to. Do you remember that?
> 
> i like the philosophy of "multi-protocol socket". however, i moderately doubt the "multi-protocol socket v2.0" is a perfect plan for every cases. in a quite good hotel, we see typically one 'multi-protocol socket' while a lot of local-standard sockets. i never think it will make me happy if i see every socket in my room is *multi-protocol*, occupying much spaces and quite noticeable on the walls. we need one to deploy somewhere not the only one type to deploy anywhere. ;-)

That point would be an operational matter for deploying any standardized technology. For example, an operator adopt OSPF to use its rich routing feature but the network is small, the operator does just area 0 routing, even OSPF allow inter-area routing for scale. Is an another ospf specification needed for 'OSPF Area 0 Only Routing'?


> 
> therefore i understand the motivation of the wg is making a unified solution covering both encapsulation and translation in the framework of stateless, WITHOUT the exclusiveness against other solutions, more specifically suitable for a certain use case. 
> 

Studying each significant use case is quite important. I agree on that point with no doubt. However, is it IETF business for each use case specification?

cheers,
--satoru