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

Qi Sun <sunqi.csnet.thu@gmail.com> Wed, 27 June 2012 09:20 UTC

Return-Path: <sunqi.csnet.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 8A40F21F8661 for <softwires@ietfa.amsl.com>; Wed, 27 Jun 2012 02:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ApFNIIeJH3vz for <softwires@ietfa.amsl.com>; Wed, 27 Jun 2012 02:20:26 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A504B21F8663 for <softwires@ietf.org>; Wed, 27 Jun 2012 02:20:26 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so1337561pbc.31 for <softwires@ietf.org>; Wed, 27 Jun 2012 02:20:26 -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; bh=C/E8BZkNbTfoq7X1l0YPEP8UMhGXjm/9lRj3eYg2oz0=; b=s1SfLIVFeciSGN3AmbadLiv8pIY55IsqUCVrZVEVludgmCyixDFVLzSdV2XsD17Bkq 2zY/SzqHsFSo5O5SjIHCJrmYQ0mFrZXyKoSQueVa4SST3J1gj7LIt+Wamj8hi41Bx8yS o/EHyz5WoTQaqGZRTd3+DoP+ngOMouUGBOUWPG/+C9xRjZcE2VvEkay4FSqC/mr1S5MD 2tmKYNlTV+IG3ut8s77qfnHGZ601mLXWhBlStvovCFQrpBfyNTgGlMtqw/CHAIfUKz54 LPr+baOwnHvmmGBfqFk7SiU3jUU9BynIsny5sz4P0UYhwmtPQualyNl4Bx/nrh1zzC3f /0mg==
MIME-Version: 1.0
Received: by 10.68.225.201 with SMTP id rm9mr62027978pbc.71.1340788826370; Wed, 27 Jun 2012 02:20:26 -0700 (PDT)
Received: by 10.143.7.3 with HTTP; Wed, 27 Jun 2012 02:20:26 -0700 (PDT)
In-Reply-To: <B725FD4A-35D6-46BE-A32A-87C3E4C3F958@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> <CAC16W0CUWhwLD8NFGxsCHWGUtRatpSUvOfFAerriUbtuQLezcA@mail.gmail.com> <1E6988FF-BFE6-4DA4-A7F6-B8BC4205967F@gmail.com> <CAAtO+XmHYvSOwxOShiNfEgXhOMGvKhPce2vvTWXa=+i+47GeSg@mail.gmail.com> <B725FD4A-35D6-46BE-A32A-87C3E4C3F958@gmail.com>
Date: Wed, 27 Jun 2012 17:20:26 +0800
Message-ID: <CAAtO+Xn-HJNh=h8299MhNAKNGwZDzVzTwy29+FKujHt6wp=pwA@mail.gmail.com>
From: Qi Sun <sunqi.csnet.thu@gmail.com>
To: Satoru Matsushima <satoru.matsushima@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b2ede33b6f09804c370b936"
Cc: Softwires WG <softwires@ietf.org>
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 09:20:27 -0000

Hi Satoru,

Please see inline.

BTW, my name is Qi :)

Qi Sun


On Wed, Jun 27, 2012 at 4:37 PM, Satoru Matsushima <
satoru.matsushima@gmail.com> wrote:

> Hi Qiong,
>
> On 2012/06/27, at 16:54, Qi Sun wrote:
>
> > Hi Satoru,
> >
> > Please see inline.
> >
> > Qi Sun
> >
> > On Wed, Jun 27, 2012 at 2:57 PM, Satoru Matsushima <
> satoru.matsushima@gmail.com> wrote:
> >
> > On 2012/06/27, at 15:38, Peng Wu wrote:
> >
> > >> 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,
> >
> > Agree on that it's not what I'm intended to. MAP thus never put DHCPv4
> over IPv6, nor PCP into its specification. Please keep your mind in peace.
> >
> > [Qi] That's not what the thread is discussing. Please do not try to
> change the topic.
> >
>
> Not intended.
>
> > > 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.
> >
> > Not to force, MAP uses its MAP protocol to an use case which also could
> be covered by LW46's DHCPv4 over IPv6, or PCP. Correct?
> >
> > [Qi] Do you mean MAP can do all these things WITHOUT ANY help from other
> documents, saying DHCPv6 options?
>
> Ah, ok. MAP define mapping rule as its protocol. DHCPv6 is a bearer of
> mapping rules.
>

[Qi]  What we are discussing is on the essence of MAP where 1:1 mode is
intended to import binding table on BR , and on whether the ietf-map-00 is
qualified as a WG draft without consensus of the softwire WG. Rather than
the provisioning methods, saying DHCPv4 over IPv6 or DHCPv6 options.

>
> >  All those mechanisms like DHCPv4 over IPv6 or PCP are not the essence
> of the protocol but provisioning method for LW4over6.
> > Actually, based on what you have said, I can get that the "new" MAP can
> achieve its NEW added 1:1 mode with the help of DHCPv4 over IPv6 for IPv4
> address allocation. Why don't you use it, which has been a DHC WG draft?
> >
>
> These are not possible because they require state in BR so that it's LW46
> use case, right? MAP define mapping rule in stateless manner.
>

[Qi] As a provisioning method, DHCPv4 over IPv6 DOES NOT require any state
in TC/BR. Please check the draft. As a result, this is not about stateful
or stateless. There is no conflict between the binding table on BR and the
DHCPv4 over IPv6 process.


> cheers,
> --satoru