Re: [v6ops] Agenda discussion

Rémi Després <despres.remi@laposte.net> Wed, 14 March 2012 13:41 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973EC21F8760 for <v6ops@ietfa.amsl.com>; Wed, 14 Mar 2012 06:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.924
X-Spam-Level:
X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3]
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 olrWacmkXyZl for <v6ops@ietfa.amsl.com>; Wed, 14 Mar 2012 06:41:34 -0700 (PDT)
Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id F121821F8782 for <v6ops@ietf.org>; Wed, 14 Mar 2012 06:41:33 -0700 (PDT)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id lRhW1i00F37Y3f403RhXdr; Wed, 14 Mar 2012 14:41:32 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-120--909510929"
From: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <CAD6AjGSJDSD-KBO3QgQJM50MCgHRKmXmTuXzzjCigHmH6KH9dw@mail.gmail.com>
Date: Wed, 14 Mar 2012 14:41:30 +0100
Message-Id: <D1631154-0F84-4C8F-AA65-D909101D06CA@laposte.net>
References: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> <23B5B3FA-A0A1-4671-97A9-D8964706344B@laposte.net> <8AD0DC9E-29C6-4E9D-AB30-4DE1DD37A62B@cisco.com> <C6EB6D4C-45C2-47A3-85C9-EDC5C9733406@laposte.net> <4F609B96.90409@gmail.com> <CAD6AjGSJDSD-KBO3QgQJM50MCgHRKmXmTuXzzjCigHmH6KH9dw@mail.gmail.com>
To: Cameron Byrne <cb.list6@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] Agenda discussion
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2012 13:41:35 -0000

Hi Cameron,

I see more the NAT64+ proposed in the latest 4rd draft as a complement to the 464XLAT approach that you promoted.

The goal is some commonality in customer nodes between a stateful solution (DS hosts using NAT64s) and a stateless  solution (4rd in this instance).

Of course, it's difficult to have it understood if there is no opportunity to explain it.

Regards,
RD

 

Le 2012-03-14 à 14:32, Cameron Byrne a écrit :

> 
> On Mar 14, 2012 6:22 AM, "Tom Taylor" <tom.taylor.stds@gmail.com> wrote:
> >
> > Perhaps it would be useful to know that Rémi's 4rd-U is actually a competitor to MAP.
> >
> >
> 
> Yep. And they both see 464xlat as a competitor.
> 
> I oppose bringing this "mine is better than yours" story to the floor. It has not been productive on the list and it will be less productive in person where it is harder to counter the hand waving arguments (like concerns about a /96 that have been addressed clearly on the list and seems to be only the interest of one person)
> 
> The stateless solutions have a place in softwires. Once they have operational scenarios and deployment lessons learned, they will fit v6ops.
> 



> Cb
> > On 14/03/2012 7:23 AM, Rémi Després wrote:
> >>
> >> Fred,
> >>
> >> 2012-03-14 11:38, Fred Baker:
> >>
> >>>
> >>> On Mar 13, 2012, at 8:40 AM, Rémi Després wrote:
> >>>
> >>>> Hi Fred,
> >>>>
> >>>> There has been discussion on the list about the relationship between 464XLAT and 4rd (24 v6ops e-mails with these 2 acronyms)
> >>>> The latest version of draft-despres-softwire-4rd-U (posted on March 12) introduces a NAT64 variant called NAT64+.
> >>>> Its purpose is 464XLAT-like scenarios with improved IPv4 transparency.
> >>>>
> >>>> I would appreciate a slot (10 minutes or more) to present what is at stake, operationally speaking.
> >>>> There is no v6ops-specific draft: time has been too short to make one despite relevance to v6ops of the subject matter to v6ops.
> >>>> (There is of course no plan to present protocol contents in v6ops, Softwire being the place for this.)
> >>
> >>
> >> This is only based on a small part of the latest 4rd-u draft.
> >> There is definitely no need to present all other documents you listed below.
> >> I do believe that, in 10 min, I can usefully inform the v6ops WG about the relationship between 464XLAT and 4rd.
> >>
> >> Regards,
> >> RD
> >>
> >>
> >>
> >>
> >>>>
> >>>> Thanks,
> >>>> RD
> >>>
> >>>
> >>> 4rd and dIVI are two legs of MAP, as I understand it. I was expecting that discussion during the 464xlat discussion, from the floor, but I'm willing to give someone ten minutes to present the MAP effort
> >>>
> >>>        http://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u
> >>>        http://datatracker.ietf.org/doc/draft-fu-softwire-4rd-mib
> >>>        http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment
> >>>        http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhcp-option
> >>>        http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encapsulation
> >>>        http://datatracker.ietf.org/doc/draft-mdt-softwire-map-translation
> >>>        http://datatracker.ietf.org/doc/draft-mdt-softwire-mapping-address-and-port
> >>>        http://datatracker.ietf.org/doc/draft-murakami-softwire-4rd
> >>>        http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast
> >>>
> >>> and discuss its implications vis-a-vis 464clat. In ten minutes, this is obviously at a very high level. Do you think you can talk with your fellow contributors to the MAP effort and find one person who can fairly the describe all of that?
> >>>
> >>>> Le 2012-03-06 à 05:46, Fred Baker a écrit :
> >>>>
> >>>>> Stated in no particular order, we have the following documents that meet these criteria:
> >>>>> - not in the IESG process somewhere
> >>>>> - posted or updated since IETF 82
> >>>>> - have had list discussion since IETF 82 or responds to discussion at IETF 82
> >>>>>
> >>>>> At this point, I take them as our agenda at IETF 83. If I am missing a document (if you have posted it since Sunday, I may well be missing it), please remind me.
> >>>>>
> >>>>>
> >>>>> http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance
> >>>>> "IPv6 Guidance for Internet Content and Application Service Providers",
> >>>>> Brian Carpenter, Sheng Jiang, 22-Feb-12
> >>>>>
> >>>>> No presentation expected, but the authors would like working group adoption. We need to decide whether we want to do that.
> >>>>>
> >>>>> http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance
> >>>>> "Using the IPv6 Flow Label for Server Load Balancing", Brian Carpenter,
> >>>>> Sheng Jiang, Willy Tarreau, 17-Jan-12
> >>>>>
> >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat
> >>>>> "464XLAT: Combination of Stateful and Stateless Translation", Masataka
> >>>>> Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12
> >>>>>
> >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-6204bis
> >>>>> "Basic Requirements for IPv6 Customer Edge Routers", Barbara Stark,
> >>>>> Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11
> >>>>>
> >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address
> >>>>> "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, Congxiao
> >>>>> Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12
> >>>>>
> >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation
> >>>>> "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)",
> >>>>> Fernando Gont, 3-Mar-12
> >>>>>
> >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6
> >>>>> "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, 1-Feb-12
> >>>>>
> >>>>> In the coming week, I am told to expect one additional -00 draft, and I could imagine other drafts being updated. I will be looking for those drafts to meet the criteria above as well, but please drop the chairs a note.
> >>>>> _______________________________________________
> >>>>> v6ops mailing list
> >>>>> v6ops@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/v6ops
> >>>>
> >>>>
> >>>
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >>
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops