Re: [16NG] [nwg-chair] NWG feedback on 16ng's IPv4 CS draft

"Riegel, Maximilian (NSN - DE/Munich)" <maximilian.riegel@nsn.com> Tue, 19 May 2009 21:05 UTC

Return-Path: <maximilian.riegel@nsn.com>
X-Original-To: 16ng@core3.amsl.com
Delivered-To: 16ng@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77EAB3A6E1B for <16ng@core3.amsl.com>; Tue, 19 May 2009 14:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
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 LvsyJiB34YcC for <16ng@core3.amsl.com>; Tue, 19 May 2009 14:05:06 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 2E3133A6E11 for <16ng@ietf.org>; Tue, 19 May 2009 14:05:05 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n4JL6e9W012067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 May 2009 23:06:40 +0200
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n4JL6edY027146; Tue, 19 May 2009 23:06:40 +0200
Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 May 2009 23:06:40 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 19 May 2009 23:06:40 +0200
Message-ID: <BC27158B99D3064A955ADE084783900C020F24D2@DEMUEXC014.nsn-intra.net>
In-Reply-To: <Pine.GSO.4.64.0905180807210.12703@tin>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [16NG] [nwg-chair] NWG feedback on 16ng's IPv4 CS draft
Thread-Index: AcnXsZm0sIl5tE+yQduhd0Bt8hhBRwBBlcvQ
References: <2828BDE8DC61004E8104C78E82A0B39710B25385F2@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com><BC27158B99D3064A955ADE084783900C01B5CBC8@DEMUEXC014.nsn-intra.net> <Pine.GSO.4.64.0905151247200.12703@tin>, <046201c9d589$267cf8d0$7376ea70$@com> <BAA9BC6C-6B59-4BA6-B63D-E09C26E0194B@mimectl> <BC27158B99D3064A955ADE084783900C020F18E5@DEMUEXC014.nsn-intra.net> <Pine.GSO.4.64.0905180807210.12703@tin>
From: "Riegel, Maximilian (NSN - DE/Munich)" <maximilian.riegel@nsn.com>
To: ext Wesley George <wgeorge@sprint.net>
X-OriginalArrivalTime: 19 May 2009 21:06:40.0688 (UTC) FILETIME=[B4996B00:01C9D8C5]
Cc: ext Alper Yegin <alper.yegin@yegin.org>, ext Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, 16ng@ietf.org
Subject: Re: [16NG] [nwg-chair] NWG feedback on 16ng's IPv4 CS draft
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 May 2009 21:05:08 -0000

Wesley, WiMAX Forum recommends that 16ng is not trying to redefine the
WiMAX Forum network design.
Not only appendix C but also other sections in the specification are
highly focused on the particularities of the WiMAX network architecture
- but with a couple of ambiguities, which would require a considerable
rewrite of large portions of the specification.
If we assume that the deployment of IPv4-CS in the WiMAX network
architecture is sufficiently specified by the documents of the WiMAX
Forum, the question arises, which issues are left the 16ng I-D on
IPv4-CS. From a WiMAX Forum perspective there is no harm, if the IPv4-CS
I-D would not exist. The WiMAX Forum makes references to the IPv6-CS
specification as well as to the IPoETH-CS specification, but not to the
IPv4-CS specification.

Hope this provides some insights why I wonder about the effort to clean
up the IPv4-CS specification.

Bye
Max

-----Original Message-----
From: ext Wesley George [mailto:wgeorge@sprint.net] 
Sent: Monday, May 18, 2009 2:10 PM
To: Riegel, Maximilian (NSN - DE/Munich)
Cc: ext Gabriel Montenegro; Samita Chakrabarti; ext Alper Yegin;
16ng@ietf.org
Subject: RE: [16NG] [nwg-chair] NWG feedback on 16ng's IPv4 CS draft

Max, I'm confused. Your message (snipped up below) was what caused me to

ask about a new draft. It seemed that WiMax Forum raised some concerns 
about unclear language in their review, and I was under the impression 
that this would require an update to the draft language to address them.

Please clarify what you meant if that was not the intent of the below 
message.

Thanks,
Wes

On Mon, 18 May 2009, Riegel, Maximilian (NSN - DE/Munich) wrote:

> Is there really a demand to work on an update of the IPv4-CS I-D?
> Which details would require/qualify for an IETF specification?
> The current architectural model closely resembles the WiMAX
> architecture, and WiMAX provides a comprehensive specification for it.
>
> Bye
> Max
>>
>>
>> On Thu, 12 Feb 2009, Riegel, Maximilian (NSN - DE/Munich) wrote:
>>
>>> Gabriel,
>>>
>>> The WiMAX Forum NWG reviewed section 4-3 and Appendix C of
>>> draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-04.txt and would like to
>>> make a couple of remarks on the MTU issue:
>>>
>>> - The I-D is not very clear about the MTU issues appearing in an
> IPv4
>>> over IEEE 802.16 transmission system. The ambiguities mainly result
>>> out of the vague definition of the IEEE 802.16 link comprising both
>>> the radio part of the link as well as the part of the link between
> BS
>>> and AR, when the functions are located in different entities.
>>>
>>> - Section 4.3 in particular misses the discussion of the
> dependencies
>>> between MTU size and the tunneling protocol deployed between BS and
> AR.
>>>
>>> - Section 4.3 also misses, that there is no packet loss when the MTU
>>> size limitation is caused by the encapsulation overhead on the link
>>> between BS and AR. E.g. when GRE is used for the tunnel between BS
> and
>>> AR, the transport IP layer can fragment the GRE packets to fit the
>>> transport MTU on the link between BS and AR. Reassembly in the
> tunnel
>>> endpoint at the AR will re-establish the original user IP packet.
>>>
>>> - Please note that the reason of the WiMAX NWG to limit the MTU
> going
>>> over IPv4-CS to 1400 Bytes was to avoid fragmentation on the link
>>> between BS and ASN-GW as well as on the link between ASN-GW and CSN
>>> (MIP tunnel). Fragmentation and re-assembly require considerable
>>> processing power in the network elements.
>>>
>>> - Appendix C makes statements which would require more detailed
> review
>>> of the I-D by WiMAX NWG. In particular 'The addressing and operation
>>> of IPv4-CS described in this document are applicable to the WiMAX
>>> networks as well' has not been verified yet.
>>> Furthermore 'Thus, WiMAX MS nodes should use this default (1400) MTU
>>> value per the current specification [WMF].  However, due to reasons
>>> specified in section 4.3 above, it is strongly recommended that
> future
>>> WiMAX MS nodes support a default MTU of 1500 bytes, and that they
>>> implement MTU negotiation capabilities as mentioned in this
> document.'
>>> makes recommendations to WiMAX without understanding the real
> reasons
>>> for the limitation of the MTU size in Mobile WiMAX.
>>>
>>> We would recommend to 16ng to revise the sections on MTU size to
>>> better explain the underlying issues leading to restrictions in the
> MTU
>> size.
>>> In particular the influence of tunneling inside the network should
> be
>>> carefully discussed.
>>> In addition we would kindly ask to either remove whole Appendix C on
>>> the WiMAX MTU size or revise the text explaining the real issues in
>>> the WiMAX architecture. In particular the statements on the
>>> applicability of the I-D on the WiMAX architecture and the
>>> recommendation on future modifications in the WiMAX architecture
> seem
>>> not to be very appropriate to us.
>>>
>>>
>>> Bye
>>> Max
>>> Vize Chair NWG
>>>
>>>
>>> ________________________________
>>>
>>> From: ext Gabriel Montenegro
> [mailto:Gabriel.Montenegro@microsoft.com]
>>> Sent: Monday, November 03, 2008 11:59 AM
>>> To: nwg-chair@list.wimaxforum.org
>>> Cc: 'Daniel Soohong Park'
>>> Subject: [nwg-chair] NWG feedback on 16ng's IPv4 CS draft
>>>
>>>
>>>
>>> Prakash, Max and Yong Chang,
>>>
>>>
>>> The IETF 16ng WG has published a revision of this draft:
>>>
>>> "Transmission of IPv4 packets over IEEE 802.16's IP Convergence
>>> Sublayer"
>>>
>>> Per this announcement:
>>>
>>> http://www.ietf.org/mail-archive/web/16ng/current/msg00863.html
>>> <http://www.ietf.org/mail-archive/web/16ng/current/msg00863.html>
>>>
>>> We understand that this specification currently is not normative to
>>> NWG (as opposed to RFC5121 on IPv6 CS). Nevertheless, given its
>>> relevance, and with the hope it may become normative to NWG in some
>>> future revision, the 16ng WG would like to solicit feedback from NWG
>>> on this draft.
>>>
>>> In particular, please note that this draft specifies a default MTU
> of
>>> 1500,  which is different from the WiMAX-specified MTU of 1400 (per
>>> the recently approved R1_V1.3.0-Stage-3  NWG specifications).  For
> MTU
>>> discussion, please refer to these sections:
>>>
>>>
> http://tools.ietf.org/html/draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-0
>>> 4#
>>> section-4.3
>>>
> <http://tools.ietf.org/html/draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-
>>> 04
>>> #section-4.3>
>>>
> http://tools.ietf.org/html/draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-0
>>> 4#
>>> appendix-C
>>>
> <http://tools.ietf.org/html/draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-
>>> 04
>>> #appendix-C>
>>>
>>> The 16ng WG will next meet on Nov 18 during the IETF in Minneapolis
>>> (https://datatracker.ietf.org/meeting/73/agenda.html). If at all
>>> possible, it would be best if comments were received before that
> date
>>> in order for the WG to discuss them during the meeting.
>>>
>>> Please send your comments to the 16ng@ietf.org
> <mailto:16ng@ietf.org>
>>> mailing list.
>>>
>>> Thanks,
>>>
>>> Gabriel and Daniel
>>> 16ng co-chairs
>>>
>>>
>>>
>>>
>> _______________________________________________
>> 16NG mailing list
>> 16NG@ietf.org
>> https://www.ietf.org/mailman/listinfo/16ng
>
>
>
>
>
>