Re: [MEXT] GRE support in DSMIPv6 - AD review
Henrik Levkowetz <henrik@levkowetz.com> Thu, 15 January 2009 21:51 UTC
Return-Path: <mext-bounces@ietf.org>
X-Original-To: mip6-archive@megatron.ietf.org
Delivered-To: ietfarch-mip6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008713A6783; Thu, 15 Jan 2009 13:51:00 -0800 (PST)
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 378EE28C0F8 for <mext@core3.amsl.com>; Thu, 15 Jan 2009 13:50:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.55
X-Spam-Level:
X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 M-nxODlms3JR for <mext@core3.amsl.com>; Thu, 15 Jan 2009 13:50:57 -0800 (PST)
Received: from av9-2-sn2.hy.skanova.net (av9-2-sn2.hy.skanova.net [81.228.8.180]) by core3.amsl.com (Postfix) with ESMTP id F3F8F3A6405 for <mext@ietf.org>; Thu, 15 Jan 2009 13:50:56 -0800 (PST)
Received: by av9-2-sn2.hy.skanova.net (Postfix, from userid 502) id 4E684381EF; Thu, 15 Jan 2009 22:50:41 +0100 (CET)
Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av9-2-sn2.hy.skanova.net (Postfix) with ESMTP id 31BB937FB5; Thu, 15 Jan 2009 22:50:41 +0100 (CET)
Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id B011937E44; Thu, 15 Jan 2009 22:50:39 +0100 (CET)
Received: from localhost ([127.0.0.1]:47233 helo=chardonnay.local) by shiraz.levkowetz.com with esmtp (Exim 4.69) (envelope-from <henrik@levkowetz.com>) id 1LNa6p-0004Mc-92; Thu, 15 Jan 2009 22:50:39 +0100
Message-ID: <496FAFA7.2000706@levkowetz.com>
Date: Thu, 15 Jan 2009 22:50:31 +0100
From: Henrik Levkowetz <henrik@levkowetz.com>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Pasi.Eronen@nokia.com
References: <C594245E.B121%hesham@elevatemobile.com> <1696498986EFEC4D9153717DA325CB7202E5DEBA@vaebe104.NOE.Nokia.com> <DE33046582DF324092F2A982824D6B030525D193@mse15be2.mse15.exchange.ms> <496F98AA.7030601@levkowetz.com> <1696498986EFEC4D9153717DA325CB7202E5E2CE@vaebe104.NOE.Nokia.com>
In-Reply-To: <1696498986EFEC4D9153717DA325CB7202E5E2CE@vaebe104.NOE.Nokia.com>
X-Enigmail-Version: 0.95.7
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: Pasi.Eronen@nokia.com, vijay@wichorus.com, hesham@elevatemobile.com, mext@ietf.org, jari.arkko@piuha.net, henrik-sent@levkowetz.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false
Cc: mext@ietf.org, jari.arkko@piuha.net
Subject: Re: [MEXT] GRE support in DSMIPv6 - AD review
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0531178598=="
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org
Hi Pasi, On 2009-01-15 21:59 Pasi.Eronen@nokia.com said the following: > Henrik Levkowetz wrote: > >> That would work for me. I'd very much like to see the TLV header >> itself kept; the reason is that if something else (GRE or whatever) >> than an IP header follows the UDP header, there isn't a clear and >> obvious way of dynamically distinguishing *what* that something else >> is, unless the TLV header is there. Ripping it out completely would >> leave the specification less ready for extension than otherwise, >> which would be unfortunate if we already know that there are needs >> for extension. > > Right.. however, since the future extensions will include a > negotiation mechanism (some bit somewhere) to say "I support this > extension FOOBAR (which implies using TLV header)", do we need > a separate "I support TLV header" bit in this spec? > > (Since if you don't support any of the extensions, sending normal > IPv4/IPv6 using the TLV format seems a bit strange.) Agreed on not needing the TLV for normal IPv4/IPv6. Not sure if that means that it's a good idea to remove the TLV support bit, if we keep the TLV. > BTW -- currently, the spec says that the packet has a *single* TLV > header (not a sequence of them), so the length field isn't > actually used for anything -- so it's really TV header :) Agreed. In 3519, the extra header has a different layout and no length field, which is anyway needed if one wants to use it as a 'next header' header. More below. >> One thing in the -05 and -06 drafts which surprised me when looking >> at them now was the value assignments for the TLV type field -- I'd >> expected the use of already-defined protocol numbers here, in a >> similar manner to what's in Section 3.3 of RFC 3519, rather than a >> new registry. But there are maybe things I've forgotten from our >> earlier discussion which makes a new type number space necessary. > > Even when TLV header is negotiated, some packets (at least BUs) are > sent without the TLV header (the IP header starts immediately after > UDP header). Agreed. > Currently, the TLV Type field is just 4 bits (to align it with the IP > version number field), and obviously values 4 and 6 won't work > (for some reason, the current spec also forbids values 2, 3, 5, > and 7..15 -- I can't see why that couldn't be relaxed...). Ah. I see the TLV header layout has changed. In order to do something similar to 3519, I imagine it looking something like the following (which seems to be somewhat in alignment with what you suggest below): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Res. | Next Header | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type This field is always 0 (zero) and distinguishes the TLV header from the IPv4 and IPv6 headers. > If it was 8 bits, at least TLV types 0x40..0x4f and 0x60..0x6f would > need to be reserved (and that would complicate using already-defined > protocol numbers). Or we separate out the type and value ('next header', above) parts, which removes the need to reserve some ranges). But maybe I'm off in the woods here -- I haven't followed any recent discussions on the TLV format, so I'm not aware of the background for the layout in the current spec. Best, Henrik
_______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext
- [MEXT] GRE support in DSMIPv6 - AD review Hesham Soliman
- Re: [MEXT] GRE support in DSMIPv6 - AD review Giaretta, Gerardo
- Re: [MEXT] GRE support in DSMIPv6 - AD review Basavaraj Patil
- Re: [MEXT] GRE support in DSMIPv6 - AD review Pasi.Eronen
- Re: [MEXT] GRE support in DSMIPv6 - AD review Hesham Soliman
- Re: [MEXT] GRE support in DSMIPv6 - AD review George Tsirtsis
- Re: [MEXT] GRE support in DSMIPv6 - AD review Hesham Soliman
- Re: [MEXT] GRE support in DSMIPv6 - AD review George Tsirtsis
- Re: [MEXT] GRE support in DSMIPv6 - AD review Hesham Soliman
- Re: [MEXT] GRE support in DSMIPv6 - AD review George Tsirtsis
- Re: [MEXT] GRE support in DSMIPv6 - AD review Hesham Soliman
- Re: [MEXT] GRE support in DSMIPv6 - AD review George Tsirtsis
- Re: [MEXT] GRE support in DSMIPv6 - AD review Sri Gundavelli
- Re: [MEXT] GRE support in DSMIPv6 - AD review Basavaraj Patil
- Re: [MEXT] GRE support in DSMIPv6 - AD review Pasi.Eronen
- Re: [MEXT] GRE support in DSMIPv6 - AD review Vijay Devarapalli
- Re: [MEXT] GRE support in DSMIPv6 - AD review Vijay Devarapalli
- Re: [MEXT] GRE support in DSMIPv6 - AD review Behcet Sarikaya
- Re: [MEXT] GRE support in DSMIPv6 - AD review Henrik Levkowetz
- Re: [MEXT] GRE support in DSMIPv6 - AD review Pasi.Eronen
- Re: [MEXT] GRE support in DSMIPv6 - AD review Henrik Levkowetz
- Re: [MEXT] GRE support in DSMIPv6 - AD review Hesham Soliman
- Re: [MEXT] GRE support in DSMIPv6 - AD review pierrick.seite
- Re: [MEXT] GRE support in DSMIPv6 - AD review Behcet Sarikaya
- Re: [MEXT] GRE support in DSMIPv6 - AD review Hesham Soliman
- Re: [MEXT] GRE support in DSMIPv6 - AD review pierrick.seite
- Re: [MEXT] GRE support in DSMIPv6 - AD review Pasi.Eronen
- Re: [MEXT] GRE support in DSMIPv6 - AD review Hesham Soliman
- Re: [MEXT] GRE support in DSMIPv6 - AD review Sri Gundavelli
- Re: [MEXT] GRE support in DSMIPv6 - AD review Basavaraj Patil
- Re: [MEXT] GRE support in DSMIPv6 - AD review Sri Gundavelli
- Re: [MEXT] GRE support in DSMIPv6 - AD review Basavaraj Patil
- Re: [MEXT] GRE support in DSMIPv6 - AD review Sri Gundavelli
- Re: [MEXT] GRE support in DSMIPv6 - AD review Behcet Sarikaya
- Re: [MEXT] GRE support in DSMIPv6 - AD review Sri Gundavelli
- Re: [MEXT] GRE support in DSMIPv6 - AD review Hesham Soliman
- Re: [MEXT] GRE support in DSMIPv6 - AD review Sri Gundavelli
- Re: [MEXT] GRE support in DSMIPv6 - AD review Hesham Soliman
- Re: [MEXT] GRE support in DSMIPv6 - AD review Sri Gundavelli
- Re: [MEXT] GRE support in DSMIPv6 - AD review Hesham Soliman
- Re: [MEXT] GRE support in DSMIPv6 - AD review Sri Gundavelli
- Re: [MEXT] GRE support in DSMIPv6 - AD review Pasi.Eronen