Re: [tsvwg] Rregarding soft-state and UDP options

[Joe Touch <[e-mail]>]

Ps - and explain how to differentiate both required and mandatory for legacy receivers. Without frag+lite, because once you have that you’re done and don’t need the bit. 

On Jan 3, 2020, at 11:30 AM, Joe Touch <[e-mail]> wrote:
> 
> How about an example of any *deployed* *transport* option with this property?
> 
> Joe
> 
>>> On Jan 3, 2020, at 11:22 AM, Tom Herbert <[e-mail]> wrote:
>>> 
>>> On Fri, Jan 3, 2020 at 11:04 AM Joe Touch <[e-mail]> wrote:
>>> 
>>> Tom,
>>> 
>>> How about providing text of an example of any deployed transport option that modifies content (other than encryption, which is already handled). That was asked several IETFs ago and remains unanswered.
>>> 
>> 
>> Joe,
>> 
>> Payload compression for example. But, I think you're equating options
>> that can't be ignored with options that modify the data. They are not
>> the same thing, the latter is a proper subset of the first. An option
>> cannot be ignored if it is required to be processed by the receiver
>> for the packet to be correctly received. For instance, if someone were
>> to put a virtual network identifier in an option then the option MUST
>> processed or the packet MUST be dropped. If the receiver ignores the
>> virtual network identifier and accepts the packet anyway it is
>> breaking the isolation requirement of virtual networking.
>> 
>> Tom
>> 
>>> Joe
>>> 
>>>> On Jan 3, 2020, at 8:07 AM, Tom Herbert <[e-mail]> wrote:
>>>> 
>>>> On Thu, Jan 2, 2020 at 8:21 PM Joe Touch <[e-mail]> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On Jan 2, 2020, at 7:00 PM, C. M. Heard <[e-mail]> wrote:
>>>>> 
>>>>>> On Thu, Jan 2, 2020 at 6:23 PM Joe Touch wrote:
>>>>>> 
>>>>>> On Jan 2, 2020, at 6:03 PM, Tom Herbert wrote:
>>>>>>> IPv6 options
>>>>>>> solve this problem by the "drop if unrecognized" bit so no negotiation
>>>>>>> is ever necessary.
>>>>>> 
>>>>>> That is ONE way to solve things, but its hardly “solved" when nearly nobody uses it.
>>>>>> 
>>>>>> But it’s also not relevant here because IPv6 baked that rule in from the start. We can’t - there’s NOTHING we can do to make a legacy receiver drop packets with unknown options, regardless of the flags per se. All we can do is design them so the options and data are invisible together, which LITE+FRAG already supports.
>>>>> 
>>>>> 
>>>>> Joe, I think that you are missing an important point here, namely that the "drop if unrecognized" flag (or Option Kind encoding rule) is proposed for the benefit of ***option aware*** receivers, not for the benefit of legacy receivers.
>>>>> 
>>>>> 
>>>>> FRAG+LITE already provides the behavior you want. The flag option fails to provide correct behavior for unidirectional or failed soft-state receivers - both of which are non-starters. A key requirement is that legacy receivers can silently ignore all options.
>>>> 
>>>> Here is the necessary requirements and text:
>>>> 
>>>> "
>>>> Options that cannot be ignored by a receiver due to side effects or
>>>> other requirements MAY be sent. An option that cannot be ignored is
>>>> indicated by the high order of the option type being set to 1 (if the
>>>> high order bit of the option type is 0 then the option can be safely
>>>> ignored).
>>>> 
>>>> If an option that cannot be ignored is received by a node that does
>>>> not recognize the option then the packet MUST be dropped. The
>>>> following requirements ensure this:
>>>> 
>>>> - Options that cannot be ignored MUST NOT be sent in packets that do
>>>> not use FRAG+LITE format. This prevents a legacy receiver from
>>>> incorrectly ignoring an unknown option.
>>>> - If an option is received with the high order bit of the bit of the
>>>> option type set to 1 and the receiver does not recognize the option,
>>>> then the packet MUST be dropped. This covers the case where a receiver
>>>> that processes UDP options however doesn't support a particular
>>>> received option that cannot be ignored.
>>>> "
>>>> 
>>>> This requirements yield a correct protocol for ALL CASES including
>>>> unidirectional, failed soft-state receivers, multicast, NAT
>>>> transitions, anycast, and simple unicast.
>>>> 
>>>> Tom
>>>> 
>>>>> 
>>>>> …
>>>>> 
>>>>> I do agree in principle that use of FRAG+LITE (in a form that includes OCS over the entire surplus area) plus post-reassembly options addresses (a) and (b) of my message (though I still reserve the right to comment when I see the details).
>>>>> 
>>>>> 
>>>>> AOK. And point taken that the soft state section needs clarification.
>>>>> 
>>>>> Joe
>>>> 
>>> 
>