Re: [shara] SHARA preliminary agenda posted

Ralph Droms <rdroms@cisco.com> Sun, 08 November 2009 03:58 UTC

Return-Path: <rdroms@cisco.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 8EBC53A6837 for <shara@core3.amsl.com>; Sat, 7 Nov 2009 19:58:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 1grrr+I9RmGv for <shara@core3.amsl.com>; Sat, 7 Nov 2009 19:58:33 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C33B73A690F for <shara@ietf.org>; Sat, 7 Nov 2009 19:58:33 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.44,702,1249257600"; d="scan'208";a="267833356"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 08 Nov 2009 03:58:58 +0000
Received: from [10.21.51.163] ([10.21.51.163]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA83wv8X006877; Sun, 8 Nov 2009 03:58:58 GMT
Message-Id: <B9281579-3680-4C5F-B41F-1EBAFAD0A7DF@cisco.com>
From: Ralph Droms <rdroms@cisco.com>
To: Randy Bush <randy@psg.com>
In-Reply-To: <m23a4shruy.wl%randy@psg.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sun, 08 Nov 2009 12:58:57 +0900
References: <070301ca5e44$5534c830$c6f0200a@cisco.com> <7C6E75E7-CC63-4E19-BD13-0F2C74E3C009@lilacglade.org> <074501ca5e49$ffea7720$c6f0200a@cisco.com> <4AF327A7.1070505@psg.com> <635562E0-6F11-45B9-BDCD-37C6A57CC548@cisco.com> <m2hbt8ianb.wl%randy@psg.com> <CB6B89C5-FF85-466B-8674-5ACCF68ABE1B@cisco.com> <m23a4shruy.wl%randy@psg.com>
X-Mailer: Apple Mail (2.936)
Cc: shara@ietf.org
Subject: Re: [shara] SHARA preliminary agenda posted
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: Sun, 08 Nov 2009 03:58:34 -0000

On Nov 6, 2009, at 7:25 PM 11/6/09, Randy Bush wrote:

>>> i guess you don't need the nokia drafts at the france telecom bof
>> To respond to that statement, I need to know what the nokia drafts
>> are.
>
> the one referenced in a+p draft is draft-bajko-pripaddrassign-01.txt

OK, thanks.

>> I also wasn't able to identify the Nokia mode of use from the A+P
>> documents I read, so I don't know what you're concerned about us
>> ruling out of scope for the BOF.
>
> again, from the a+p draft
>
> 4.2.  A+P for Mobile Providers
>
>   In the case of mobile service provider the situation is slightly
>   different.  The A+P border is assumed to be the gateway (e.g., GGSN/
>   PDN GW of 3GPP, or ASN GW of WiMAX).  The need to extend the address
>   is not within the provider network, but on the edge between the
>   mobile phone devices and the gateway.  While desirable, IPv6
>   connectivity may or may not be provided.
>
>   ...

That last sentence - which I think is in conflict with constraint 10  
in section 2.1 - is why I'm concerned about this scenario.  It has the  
potential to provide more support to the continued use of IPv4 than is  
desirable.

>> However, A+P remains a function distinct from DS-lite, and at least
>> deserves review in its own BOF.
>
> then why did the iesg/iab say the bof was limited to the ds-lite
> application?
>
> randy

I'm willing to consider an extension to other tunnel/IPv6  
deployments.  But the basic technology needs  the development of  
details, as I expect we'll discuss in the BoF, that are unrelated to  
the specific tunneling technology.

- Ralph