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

Peng Wu <pengwu.thu@gmail.com> Wed, 27 June 2012 06:38 UTC

Return-Path: <pengwu.thu@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 C602121F857F for <softwires@ietfa.amsl.com>; Tue, 26 Jun 2012 23:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.243
X-Spam-Level:
X-Spam-Status: No, score=-3.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 flQg22IHzTA0 for <softwires@ietfa.amsl.com>; Tue, 26 Jun 2012 23:38:04 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C89E421F8579 for <softwires@ietf.org>; Tue, 26 Jun 2012 23:38:03 -0700 (PDT)
Received: by qadz3 with SMTP id z3so2268888qad.10 for <softwires@ietf.org>; Tue, 26 Jun 2012 23:38:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MXpKCJT3Zu4xesbESccpBtouYx5uRUDTQOy98C3Iwrk=; b=jJQsa81caYp/f4mKukSnkwlcN5aCcIRAEyYIEeXUtt+W0icMnxL0AmsdzwQYZIk557 h9PufBgPQVmMVKqT+x/MHnDHHO/bVwNJ6k5CpJaTYRJDSC0yclItGG5xLqcvfXALeb6N FhsOBm1MRAbtmCvFjkfm4kGGksUJkoYCOzhwVpbIatDVuMx/5POA8hJpmnRzwLKfUOa/ X6Wt7E593ov8aZTIVdOl6wkreXDfSkCbHfMxAwdYDMNO4kO2YkxvXmFu328kZWbZSwfU VFqSyoKVynlUsPkYYdxrKP3oNuIdKStOHZgy8Y8IXIE44p7EV8poCPQwunMnBBjIzObD dPpw==
MIME-Version: 1.0
Received: by 10.224.78.195 with SMTP id m3mr29663462qak.1.1340779083202; Tue, 26 Jun 2012 23:38:03 -0700 (PDT)
Received: by 10.229.216.212 with HTTP; Tue, 26 Jun 2012 23:38:03 -0700 (PDT)
In-Reply-To: <CBD94C41-5A67-4DDC-BDE4-514C7F186E8B@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> <C41CE132-8C42-4898-B2DF-43BBFAE89515@gmail.com> <CAC16W0Ds-aRLMbyVdwifA3wjJwHuKOKjhkDLxxRm+X68wOnv7A@mail.gmail.com> <CBD94C41-5A67-4DDC-BDE4-514C7F186E8B@gmail.com>
Date: Wed, 27 Jun 2012 14:38:03 +0800
Message-ID: <CAC16W0CUWhwLD8NFGxsCHWGUtRatpSUvOfFAerriUbtuQLezcA@mail.gmail.com>
From: Peng Wu <pengwu.thu@gmail.com>
To: Satoru Matsushima <satoru.matsushima@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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 06:38:04 -0000

>>>> 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'?
>>
>> Well if I only have a simple network and I uses RIP, you don't make
>> OSPF somehow compatible with RIP(or just include RIP with an OSPF
>> terminology face? I don't know) and say "hey, just use this super
>> suite, don't consider it overloaded, it's for unity!"
>
> Oh, you don't argue that OSPF covers an use case which is also covered by RIP. So then why are you arguing that an use case of MAP is eventually same with the LW46 use case?
I'm clearly saying they have different use cases, but that's not the
point. Let me repeat. If I want RIP, you cannot just place RIP into
OSPF, put an OSPF "face" on it, and force me to use the OSPF "suite"
while the essence of the protocol I'm using is still RIP.