Re: [shara] Summary and outcomes from aplusp BoF at IETF 76

<pierre.levis@orange-ftgroup.com> Thu, 10 December 2009 12:18 UTC

Return-Path: <pierre.levis@orange-ftgroup.com>
X-Original-To: shara@core3.amsl.com
Delivered-To: shara@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6D7428C0E0; Thu, 10 Dec 2009 04:18:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.629
X-Spam-Level:
X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1Qal-LQU1f8; Thu, 10 Dec 2009 04:18:23 -0800 (PST)
Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id BDAF128C0E6; Thu, 10 Dec 2009 04:18:22 -0800 (PST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 13:17:53 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 10 Dec 2009 13:17:52 +0100
Message-ID: <F1A741D65FFEF6489D607B26ABA0ED57013B751D@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <4B20D917.5090003@free.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [shara] Summary and outcomes from aplusp BoF at IETF 76
Thread-Index: Acp5iqwKvWdDFvbORHyLLl/7nuU5XAAB5luw
References: <8FD04E6A-62DF-4606-A374-CBE657F0CF0B@cisco.com> <2927_1260194664_4B1D0B68_2927_2219_1_94C682931C08B048B7A8645303FDC9F30EF2B00588@PUEXCB1B.nanterre.francetelecom.fr> <EFDE258A-6C69-4FEB-A8F5-CB5DA6BF7F09@cisco.com><14682_1260426885_4B209685_14682_2786_1_94C682931C08B048B7A8645303FDC9F30EF2BBC9B5@PUEXCB1B.nanterre.francetelecom.fr> <4B20D917.5090003@free.fr>
From: pierre.levis@orange-ftgroup.com
To: rdroms@cisco.com
X-OriginalArrivalTime: 10 Dec 2009 12:17:53.0208 (UTC) FILETIME=[CC3AEB80:01CA7992]
Cc: shara@ietf.org, iesg@ietf.org, Softwire@core3.amsl.com, softwire-chairs@tools.ietf.org
Subject: Re: [shara] Summary and outcomes from aplusp BoF at IETF 76
X-BeenThere: shara@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Sharing of an IPv4 Address discussion list <shara.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/shara>, <mailto:shara-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shara>
List-Post: <mailto:shara@ietf.org>
List-Help: <mailto:shara-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shara>, <mailto:shara-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Dec 2009 12:18:25 -0000

 
Hi Ralph,

Yes and we must not consider Dave Thaler's presentation as the IETF consensus.
-The slides only showed up at the beginning of the BoF session, so they couldn't be discussed on the mailing list beforehand (no reference draft either).
-Due to lack of time they couldn't really be discussed during the BoF.
-As noticed in the minutes: Problem statement clear/not clear: hum was louder for "not clear", meaning people didn't understand what was at stake.

So I would like to back Margaret's proposal:
"From an IETF process standpoint, I think that the best thing we can  
do with the outcome of the aplusp BOF is to ignore it completely"

A+P deserves further consideration and discussion


Regards,

Pierre 


-----Message d'origine-----
De : shara-bounces@ietf.org [mailto:shara-bounces@ietf.org] De la part de Rémi Després
Envoyé : jeudi 10 décembre 2009 12:19
À : Ralph Droms
Cc : IESG IESG; Chairs; Softwire@core3.amsl.com; shara@ietf.org
Objet : Re: [shara] Summary and outcomes from aplusp BoF at IETF 76

Ralph,

It's IMHO constructive that Mohamed made the effort to continue this 
discussion.

First, I agree with the list of positive points of A+P he listed.
It is a useful contribution to balance the list of negative points
of Dave's presentation in Hiroshima. (This list BTW has been challenged 
during the BOF, with too little time to argue technically).

I agree also with Margaret's view that the BOF process has been
sufficiently unusual for the chairs' conclusion to be open to revision.

In addition, I note that:
o The scope of the BOF has been firmly limited to A+P *in the context of
DS-lite*.
Any conclusion, contested or not, must therefore be also limited to this
context.
As a minimum, A+P in the mesh-softwire context can therefore by no means 
be considered as ruled out.
o At the end of the Softwire meeting, time being too short, I introduced
in 5 minutes a 28 pages draft on a mesh-softwire lite approach. This
approach, derived from 6rd, i.e. intended for simple and short term
deployment, includes a variant of A+P as a feature.
I was told that more time should be available for it at the next IETF
meeting, which is fair in view of the time that was available.

More comments in line.

Conclusion (as Mohamed wrote):
"Why not give us a second chance to better explain the problem we are
targeting and explain the rationale of the solutions we are proposing?"

Regards,

RD

> Dear Ralph,
> 
> Thank you for your answers but I still have some objections.
> 
> Please see in line.
> 
> 
> -----Message d'origine----- De : Ralph Droms
> [mailto:rdroms@cisco.com] Envoyé : mercredi 9 décembre 2009 15:29 À :
> BOUCADAIR Mohamed NCPI/NAD/TIP Cc : shara@ietf.org; IESG IESG;
> Softwire Chairs Objet : Re: [shara] Summary and outcomes from aplusp
> BoF at IETF 76
> 
> Responses in line...
> 
> On Dec 7, 2009, at 9:04 AM 12/7/09,
> <mohamed.boucadair@orange-ftgroup.com
>> <mohamed.boucadair@orange-ftgroup.com> wrote:
> 
>> Dear Ralph,
>> 
>> You mentioned that "a+p has too many side effects, not all of which
>>  are known at this point, to be a useful mechanism to meet that
>> need."
>> 
>> - Could you enumerate these "too many side effects"? BTW, It is 
>> strange to have an objection to work an A+P because "not all of 
>> which are known at this point"?!
> 
> Let me clarify.  Dave Thaler's presentation pointed out enough side
>  effects specific to A+P to lead to the conclusion.  I assume other
>  side effects would be discovered in the course of developing an a+p
>  specification.

Why to assume this?
Why not to assume also, or instead, that some of the listed side effects
are inexistent, even in the sole DS-lite context (as everal participants
knowing the subject said it during the BOF).
(I have a very great respect for Dave's contributions in general, but 
this one was clearly not at the usual level.)


> Med: I'm afraid to disagree here since D. Thaler's presentation is
> mostly a collection of issues which are not specific to A+P (Please
> refer to
> http://www.ietf.org/mail-archive/web/shara/current/msg00196.html). 
> Particularly, the "Long-term impact" slide from D. Thaler prezo is
> not so that true since the proposed A+P solutions allow a smooth
> migration to IPv6 while solving the IPv4 address exhaustion. - A+P
> solutions encourage the deployment of IPv6 in local domain without
> requiring universal agreement to move to IPv6 since interconnection
> functions at the boundaries are stateless. - A+P allows also to
> shorten the lifetime of the dual-stack plans in the network and only
> IPv6 is required for the delivery of IPv4 and IPv6 connectivity
> services. - Services are not broken since we don't need any ALG to be
> deployed in the core network. - A+P is not a hurdle for the
> introduction of new services since there is no need to update
> intermediary nodes (such as CGNs). - A+P does not need any state
> synchronisation for robustness reasons since now per-flow data is
> maintained in intermediary nodes. - A+P allows to offer
> subscriber-hosted services with current practices. No need to define
> new protocols (some modifications are required to avoid port
> conflict) - Already defined tools and techniques (e.g., URL, SRV
> records, redirection, etc.) allows to specify a port number in the
> host part - Etc.
> 
> 
>> - Are these issues specific to A+P? - Should we do the same
>> exercise for other forms of shared address schemes? - Should we
>> understand that the underlying message from the IESG is to go for a
>> CGN-based solution? Quid of maintaining ALGs, service brokenness,
>> lawful data storage, robustness, etc.? If CGN are massively
>> deployed, what will be the motivation to move to IPv6? Again: what
>> is the exit strategy proposed by the IESG. I'm afraid to say that
>> DS is not a viable one!
> 
> There is no silver bullet to be found anywhere.  We have some 
> solutions, which we need to deploy as judiciously as possible while
> we move the Internet to IPv6.  The existing interim technologies have
>  known problems; I interpret the response in the BoF to indicate that
> a +p is not considered to be less problematic or otherwise
> advantageous relative to the existing technologies.

NATs are unavoidable and very useful in various scenarios, but they are
also THE major cause of many complex problems.
In particular, they are responsible for the high sophistication of such
interim technology as Teredo.

Suggesting, as Dave did, that A+P will be at least as problematic as
Teredo, is wrong, and very misleading:
o Unlike NATs and Teredo, A+P can be stateless (a property that BTW
fosters the interest for 6rd) .
o If combined with CGNs, A+P is AFAIK the simplest known approach for 
incoming connections.

> 
> Med: I wasn't in the BoF, but reading the mail from M. Wasserman
> makes me think that there was something "wrong" 
> (http://www.ietf.org/mail-archive/web/shara/current/msg00195.html). 
> So, why not give us a second chance to better explain the problem we
> are targeting and explain the rationale of the solutions we are
> proposing?
> 
> You mentioned "I will
>> ask the softwire WG to consider the issue of inbound connections to
>>  subscriber-provided services as part of their work on DS-lite. "
>> 
>> - Does it mean that only port forwarding policies and configuration
>>  of static mappings in the AFTR (BTW, the AFTR terminology is 
>> misleading since the ds-lite CGN is not an AF translator) will be
>> in scope?
> 
> If I understand your question correctly, yes, I will ask the softwire
>  WG to develop control mechanisms for forwarding in the AFTR.
> 
>> - Does it mean that A+P features MAY be supported in B4 and AFTR?
>> Or a+p is explicitly out of scope of the solution candidates to
>> solve "connections to subscriber-provided services"?
> 
> a+p is out of scope for the softwire WG and no work is chartered 
> elsewhere.
> 
>> Cheers, Med
> 
> - Ralph
> 
> 
>> -----Message d'origine----- De : shara-bounces@ietf.org
>> [mailto:shara-bounces@ietf.org] De la part de Ralph Droms Envoyé :
>> vendredi 4 décembre 2009 17:59 À : shara@ietf.org Cc : IESG IESG;
>> Softwire Chairs Objet : [shara] Summary and outcomes from aplusp
>> BoF at IETF 76
>> 
>> Thanks to Dan and Christian for chairing the BoF and to everyone
>> who participated.  I especially thank the participants for staying
>> on topic and having a constructive and useful discussion of the
>> issues during the BoF.
>> 
>> There were a couple of aspects of the BoF that I wish I had handled
>>  better.  In particular, I didn't intend to exclude any of the 
>> proponents of the various a+p proposals related to dual-stack lite 
>> (DS-lite) and, in retrospect, we could have done a better job with
>> the initial formulation of the questions asked at the end of the
>> BoF. I'll reiterate that I think the chairs did a great job with
>> the BoF, considering the history and context of the topic, and the
>> shortcomings of the BoF are really my responsibility.
>> 
>> However, I think that this BoF, considered with the outcome of the 
>> previous shara BoF, came to a couple of useful conclusions:
>> 
>> * there is a need to provide inbound connections to 
>> subscriber-provided services, and
>> 
>> * a+p has too many side effects, not all of which are known at this
>>  point, to be a useful mechanism to meet that need.
>> 
>> Comments on these conclusions is encouraged...
>> 
>> Considering this outcome, no work on a+p will be chartered.  I will
>>  ask the softwire WG to consider the issue of inbound connections
>> to subscriber-provided services as part of their work on DS-lite.
>> Other working groups may take on development of techniques for
>> providing inbound connections in other technologies and scenarios.
>> 
>> - Ralph
>> 
>> _______________________________________________ shara mailing list 
>> shara@ietf.org https://www.ietf.org/mailman/listinfo/shara
>> 
>> ********************************* This message and any attachments
>> (the "message") are confidential and intended solely for the
>> addressees. Any unauthorised use or dissemination is prohibited. 
>> Messages are susceptible to alteration. France Telecom Group shall
>> not be liable for the message if altered, changed or falsified. If
>> you are not the intended addressee of this message, please cancel
>>  it immediately and inform the sender. 
>> ********************************
>> 
> 
> 
> ********************************* This message and any attachments
> (the "message") are confidential and intended solely for the
> addressees. Any unauthorised use or dissemination is prohibited. 
> Messages are susceptible to alteration. France Telecom Group shall
> not be liable for the message if altered, changed or falsified. If
> you are not the intended addressee of this message, please cancel it
> immediately and inform the sender. ********************************
> 
> _______________________________________________ shara mailing list 
> shara@ietf.org https://www.ietf.org/mailman/listinfo/shara
> 

_______________________________________________
shara mailing list
shara@ietf.org
https://www.ietf.org/mailman/listinfo/shara