Re: [MEXT] GRE support in DSMIPv6 - AD review

[Henrik Levkowetz <[e-mail]>]

Hi Pasi,

On 2009-01-15 21:59 [e-mail] 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
[e-mail]
https://www.ietf.org/mailman/listinfo/mext