Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode?
Xing Li <xing@cernet.edu.cn> Fri, 15 February 2013 09:35 UTC
Return-Path: <xing@cernet.edu.cn>
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 DD71021F8495 for <softwires@ietfa.amsl.com>; Fri, 15 Feb 2013 01:35:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTvHQgNpTnTX for <softwires@ietfa.amsl.com>; Fri, 15 Feb 2013 01:35:01 -0800 (PST)
Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8586121F846B for <softwires@ietf.org>; Fri, 15 Feb 2013 01:35:00 -0800 (PST)
Received: from [127.0.0.1] (unknown [221.11.179.1]) by centos (Coremail) with SMTP id AQAAf3CrVgUOAR5RjywKAA--.34555S5; Fri, 15 Feb 2013 17:34:08 +0800 (CST)
Message-ID: <511E013B.2000801@cernet.edu.cn>
Date: Fri, 15 Feb 2013 17:34:51 +0800
From: Xing Li <xing@cernet.edu.cn>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: ian.farrer@telekom.de
References: <CD42D49A.53F2B%ian.farrer@telekom.de>
In-Reply-To: <CD42D49A.53F2B%ian.farrer@telekom.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-CM-TRANSID: AQAAf3CrVgUOAR5RjywKAA--.34555S5
X-Coremail-Antispam: 1UD129KBjvJXoWxZFy5KF43Xr43try7Ar1fJFb_yoW5tF1rpF y3JFnFkr1DJF18Jw4Igr48G340yrWFqr43Xr15Gr18Z390yF18Ar10qw4ruryDWr98JF4j qrW8Wa43Wan8AFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUDC14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14 v26r4j6ryUM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aVAF wI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52 x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC2z280aVAFwI0_Jr0_Gr1l Ox8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxw CY02Avz4vE14v_GFWl42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxVWUJVWUGwC20s02 6x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0x vE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE 42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87 Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x0JUdEfOUUUUU=
X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/
Cc: softwires@ietf.org, ot@cisco.com, draft-ietf-softwire-map@tools.ietf.org
Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode?
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: Fri, 15 Feb 2013 09:35:02 -0000
Hi, Ian, The 1:1 mode is a natural characteristic of MAP and removing it from the draft will cause more confusion. Please also see https://datatracker.ietf.org/doc/draft-xli-softwire-map-testing/ which shows that a MAP CPE can naturally support 1:1 mode. Regards, xing ian.farrer@telekom.de 写道: > Hi Ole, > > Assuming that the Unified CPE draft gets adopted by the workgroup, then > there needs to be alignment of the different drafts reflecting this. > > The unified CPE draft describes how a CPE interprets the presence (or lack > of) configuration parameters to understand which softwire mode to > configure. If a MAP CE implemented this (to be a 'unified MAP CE'), then > it would have two ways of configuring 1:1 mode - via the presence of the > tunnel endpoint address, an IPv4 address (and optionally a restricted port > range) and also through a BMR with EA=0. > > Two ways of configuring the same function doesn't seem like a good idea, > even if the underlying mechanism that this function is implemented with is > different. > > So, what I would propose is that EA=0 for MAP is not included as a > provisioning option in the MAP draft. If the parameters described in the > unified CPE draft required for 1:1 mode are configured on the unified MAP > CE, then it should interpret these to mean EA=0 and configure itself > accordingly. > > > I also think that it would be cleaner if this 1:1 functionality was > described in a separate document to the current MAP draft. As the 1:1 mode > functionality of MAP is a big architectural change to the mesh mode > function, it really needs a lot more than 2 paragraphs in order to > describe what it is and how it is used. > > > Best regards, > Ian > > On 14/02/2013 11:14, "Ole Troan" <ot@cisco.com> wrote: > > >>> #25: Maintain or remove MAP1:1 Mode? >>> >> OK, so here is a task for whomever thinks MAP 1:1 mode should be removed. >> >> - what does "remove MAP 1:1 mode mean"? >> - please suggest text changes to the mechanism that removes 1:1 mode. >> >> given that my opinion is that 1:1 mode is an unremovable part of MAP, the >> question just doesn't make sense to me. >> >> I don't want this issue to be an excuse to block a last call, can we >> quickly resolve this, and can we agree to drop it if there are no >> significant contributions within the next week? >> >> cheers, >> Ole >> >> >> >>> The WG discussed several times this point (refer to the mailing list >>> archives). >>> >>> MAP1:1 mode is a particular mode which may re-use some of the >>> provisioning >>> methods defined for MAP. >>> >>> MAP1:1 vs. Lw4o6: >>> * MAP1:1 is not fully stateless. >>> * Lw4o6 is a standalone specification which provides the same service as >>> MAP1:1. >>> >>> -- >>> >>> -------------------------------------+----------------------------------- >>> -- >>> Reporter: | Owner: draft-ietf-softwire- >>> mohamed.boucadair@orange.com | map@tools.ietf.org >>> Type: defect | Status: new >>> Priority: major | Milestone: >>> Component: map-e | Version: >>> Severity: - | Keywords: >>> >>> -------------------------------------+----------------------------------- >>> -- >>> >>> Ticket URL: <http://trac.tools.ietf.org/wg/softwire/trac/ticket/25> >>> softwire <http://tools.ietf.org/softwire/> >>> >>> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > > >
- Re: [Softwires] [softwire] #25: Maintain or remov… Rémi Després
- Re: [Softwires] [softwire] #25: Maintain or remov… Ole Troan
- Re: [Softwires] [softwire] #25: Maintain or remov… mohamed.boucadair
- Re: [Softwires] [softwire] #25: Maintain or remov… Ole Troan
- Re: [Softwires] [softwire] #25: Maintain or remov… Rémi Després
- Re: [Softwires] [softwire] #25: Maintain or remov… Rajiv Asati (rajiva)
- Re: [Softwires] [softwire] #25: Maintain or remov… ian.farrer
- Re: [Softwires] [softwire] #25: Maintain or remov… Maoke
- Re: [Softwires] [softwire] #25: Maintain or remov… Satoru Matsushima
- Re: [Softwires] [softwire] #25: Maintain or remov… Wojciech Dec (wdec)
- Re: [Softwires] [softwire] #25: Maintain or remov… Rémi Després
- Re: [Softwires] [softwire] #25: Maintain or remov… Xing Li
- Re: [Softwires] [softwire] #25: Maintain or remov… Satoru Matsushima
- Re: [Softwires] [softwire] #25: Maintain or remov… Wojciech Dec (wdec)
- Re: [Softwires] [softwire] #25: Maintain or remov… Qi Sun
- Re: [Softwires] [softwire] #25: Maintain or remov… Rémi Després
- Re: [Softwires] [softwire] #25: Maintain or remov… Wojciech Dec (wdec)
- Re: [Softwires] [softwire] #25: Maintain or remov… Rémi Després
- Re: [Softwires] [softwire] #25: Maintain or remov… Wojciech Dec (wdec)
- Re: [Softwires] [softwire] #25: Maintain or remov… Rémi Després
- Re: [Softwires] [softwire] #25: Maintain or remov… Wojciech Dec (wdec)
- Re: [Softwires] [softwire] #25: Maintain or remov… Rémi Després
- Re: [Softwires] [softwire] #25: Maintain or remov… Qiong
- Re: [Softwires] [softwire] #25: Maintain or remov… Ole Troan
- Re: [Softwires] [softwire] #25: Maintain or remov… Wojciech Dec (wdec)
- Re: [Softwires] [softwire] #25: Maintain or remov… Rémi Després
- Re: [Softwires] [softwire] #25: Maintain or remov… ian.farrer
- Re: [Softwires] [softwire] #25: Maintain or remov… Ole Troan