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

[Tom Herbert <[e-mail]>]

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

> 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
>