Re: [tsvwg] Options larger than 255 (was RE: draft-ietf-udp-options issues from IETF 104)

[Gorry Fairhurst <[e-mail]>]

On 18/07/2019, 17:34, Tom Herbert wrote:
> On Thu, Jul 18, 2019 at 9:21 AM Gorry Fairhurst<[e-mail]>  wrote:
>> On 18/07/2019, 17:13, Tom Herbert wrote:
>>> On Thu, Jul 18, 2019 at 5:45 AM Gorry Fairhurst<[e-mail]>   wrote:
>>>> Ah so, I guess the document editors canm work out what is best to do.
>>>>
>>>> My wish was to systematically allow larger options to be possible.
>>>>
>>> Gorry,
>>>
>>> This is a good example of how a variant/type field in the surplus
>>> header allows the format to be extensible. If a large option length is
>>> needed then a variant could be created for that. Since the format is
>>> extensible we don't have to specify all possibilities for the protocol
>>> up front.
>>>
>>> Tom
>> Yes, I see that as an option. In relaity though for this case we have a
>> 1 byte len or a 2 byte len. Personally, I would not be in favour of a
>> longer length... that another story (see,
>> draft-jones-6man-historic-rfc2675-00) ;-)
>>
> Probably not just length field that will be a target :-). For
> instance, I could imagine the Geneve proponets might want longer type
> fields (e.g. maybe they want to move some Geneve options into UDP
> options for some reason).
>
> I am curious though, how would options bigger than 255 bytes help? It
> doesn't seem like this was ever an issue with other dataplane
> protocols that have options.
>
> Tom
>
So one place where options > 255 help, is when you put a fragment 
payload (upto however big you can send in a PMTU) into an option to 
transport it, so that the fragment payload and header arrive and are 
processed together - likely this results in a zero-length UDP datagram 
and an option field.

Gorry

>> Gorry
>>>> Gorry
>>>>
>>>> On 18/07/2019, 13:41, [e-mail] wrote:
>>>>> Re-,
>>>>>
>>>>> 0/1 are illegal values. These values MUST NOT be used. A receiver will discard them systematically.
>>>>>
>>>>> With the proposed approach: 254/255 are legal values... but with a special meaning.
>>>>>
>>>>> Cheers,
>>>>> Med
>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Gorry Fairhurst [mailto:[e-mail]]
>>>>>> Envoyé : jeudi 18 juillet 2019 14:26
>>>>>> À : BOUCADAIR Mohamed TGI/OLN
>>>>>> Objet : Re: Options larger than 255 (was RE: [tsvwg] draft-ietf-udp-
>>>>>> options issues from IETF 104)
>>>>>>
>>>>>> I don't mind the choice of codepoint, my understaning was zero was an
>>>>>> invalid length, and an easy thing to test in code. Choosing 254 or 255
>>>>>> seems less obvious to me, but if there are good reasons, just say...
>>>>>>
>>>>>> Gorry
>>>>>>
>>>>>> On 18/07/2019, 12:48, [e-mail] wrote:
>>>>>>> Re-,
>>>>>>>
>>>>>>> Associating a meaning with Len=0 as proposed by Joe may not be
>>>>>> intuitive. An alternate approach would be:
>>>>>>> * 'Len' only covers the option data field (that is, 'kind' and 'Len'
>>>>>> fields are not covered. The overall option length can be easily inferred).
>>>>>>> * Associate a meaning with one of the two values we grabbed:
>>>>>>>      - 254 or 255: a 16-bit extended length field follows
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Med
>>>>>>>
>>>>>>>> -----Message d'origine-----
>>>>>>>> De : tsvwg [mailto:[e-mail]] De la part de Gorry
>>>>>> Fairhurst
>>>>>>>> Envoyé : jeudi 18 juillet 2019 12:22
>>>>>>>> À : [e-mail]
>>>>>>>> Cc : tsvwg
>>>>>>>> Objet : Re: [tsvwg] draft-ietf-udp-options issues from IETF 104
>>>>>>>>
>>>>>>>>> Gorry
>>>>>>>> P.S. I like the idea to explicitly allow options longer than 255 bytes?
>>>>>>>> - This seems useful for fragmentation and would be an easy addition,
>>>>>>>> someone suggested using 0 option length to indicate a 16b length field,
>>>>>>>> which could make total sense. As in:
>>>>>>>>
>>>>>>>> https://mailarchive.ietf.org/arch/msg/tsvwg/B4oeZkpagdl4gkAMDCFW7F1A7_8
>>>>>>>>
>>>>>>>> Gorry