Re: IAB last call... Re: [ipv6-dir] Re: Updated document

Scott W Brim <sbrim@cisco.com> Mon, 09 January 2006 15:23 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evyrn-0004LV-JB; Mon, 09 Jan 2006 10:23:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evyrj-0004Jv-7J; Mon, 09 Jan 2006 10:23:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21312; Mon, 9 Jan 2006 10:22:04 -0500 (EST)
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvyyD-0007r0-Gz; Mon, 09 Jan 2006 10:30:07 -0500
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Jan 2006 07:23:12 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.99,347,1131350400"; d="scan'208"; a="19305285:sNHT25180160"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k09FMmJx012885; Mon, 9 Jan 2006 10:23:08 -0500 (EST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Jan 2006 10:22:46 -0500
Received: from [10.86.242.97] ([10.86.242.97]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Jan 2006 10:22:54 -0500
Message-ID: <43C27FCD.1020200@cisco.com>
Date: Mon, 09 Jan 2006 10:22:53 -0500
From: Scott W Brim <sbrim@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.3.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
Subject: Re: IAB last call... Re: [ipv6-dir] Re: Updated document
References: <200601091455.k09Et2c2020603@cichlid.raleigh.ibm.com>
In-Reply-To: <200601091455.k09Et2c2020603@cichlid.raleigh.ibm.com>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Jan 2006 15:22:54.0453 (UTC) FILETIME=[8FF63A50:01C61530]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Content-Transfer-Encoding: 7bit
Cc: "<john.loughney@nokia.com> (Nokia-NRC/Helsinki) John" <john.loughney@nokia.com>, Leslie Daigle <leslie@thinkingcat.com>, IAB IAB <iab@ietf.org>, Margaret Wasserman <MRW@devicescape.com>, Bradner Scott <sob@harvard.edu>, ipv6-dir@ietf.org, Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
X-BeenThere: ipv6-dir@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IPv6 Directorate <ipv6-dir.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6-dir>, <mailto:ipv6-dir-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6-dir@ietf.org>
List-Help: <mailto:ipv6-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6-dir>, <mailto:ipv6-dir-request@ietf.org?subject=subscribe>
Sender: ipv6-dir-bounces@ietf.org
Errors-To: ipv6-dir-bounces@ietf.org

<liaison hat> OK but please can we do whatever it takes to reach
closure on this today -- maybe tomorrow?  The meeting starts in one
week, and the TSB needs to process this as an input document.

On 01/09/2006 09:55 AM, Thomas Narten allegedly wrote:
>   The IETF has not planned on direct translation between IPv4 and
>   IPv6.  As a consequence there hasn't not been any work on mapping
>   IPv6 and IPv4 QOS.  Generally the IETF focuses on Internetworking,
>   not Interworking.

<personal hat> I would delete the last sentence because it's debatable
in a couple of ways, and unnecessary in any case.

>>The IPv6 flow label identifier is a 20-bit field in the IPv6 header. A
>>value of zero indicates that no flow id is set and no assumption on
>>the packets being part of a flow can be made. Further, nodes must not
>>assume that there is a semantic meaning of the flow label field. This
>>has had relevance in several IETF Working groups and related work,
>>where the possibility of using the Flow label field is considered for
>>overloading the semantics for other work. This has most of the time
>>been an artifact of work that would have benefited from a field of its
>>own in the IPv6 header. This has so far been deemed incompatible with
>>the definition of the flow label field.
> 
> 
> I'd suggest dropping the above, as it doesn't add anything beyond the
> existing RFCs.

<liaison hat> true but I believe it's worth calling it all out again,
to remind them that they shouldn't assume semantics in the flow label,
etc.  There was a thrust in that direction.

>>The IPv6 mobility model, Mobile Support in IPv6 aka Mobile IPv6, has
>>been adopted from the IPv4 version Mobile IP, with some modifications
>>and extensions.  Especially the security model for route optimisation
>>is different.  Mobile IPv6 is documented in RFC 3775 and RFC 3776,
>>with an optional extension in RFC 4283.  RFC 4225 explains the
>>rational and design behind the route optimisation security model, and
>>its limitations.
> 
> 
> I'm not sure I understand why Mobility is being called out for
> discussion. Is this a "NGN" topic? 

Hugely so.  One of their key documents is on mobility and how IPv6
supports it.  Not just IP mobility but higher layer mobility,
fixed-mobile convergence, and so on.  One of the things they
originally proposed was that SCTP was the answer to their mobility
problems.  I pointed out a few and they backed off of that in the
latest version, to requirements and generic scenarios.  They are
actually quite aware of the mobility support capabilities, so you
don't need to say much, but for the sake of responding to their
interests, it would be good to leave this paragraph in.

That said, my burning desire at this point is to see this get out the
door, so if deleting this paragraph makes that happen, go for it.

>>The IETF is currently considering extensions and, in the longer term,
>>potential alternatives, to Mobile IPv6.  Issues being addressed
>>include mobility between IPv4 and IPv6, combined mobility and
>>multi-homing, security issues related to mobility, and deeper
>>architectural problems related to the possible need of revising the
>>architecture along the so called identifier/locator split
>>suggestion.
> 
> This is too abstract/high-level for what we should be commmunicating
> to ITU-T.

Why?  They are trying to understand the IETF trajectory.  Are all of
these in the works, standards track or WG drafts?

(refrain) That said, my burning desire at this point is to see this
get out the door, so if deleting this paragraph makes that happen, go
for it.

swb

_______________________________________________
ipv6-dir mailing list
ipv6-dir@ietf.org
https://www1.ietf.org/mailman/listinfo/ipv6-dir