Re: Comments on draft-herbert-ipv6-update-dest-ops

[Ole Troan <[e-mail]>]

Tom,

> Consider the folling scenario:
> 
> Someone is developing a new Destination Option that might be of
> interest for use with tunnels and might even become one of those
> options "that makes sense to support" . Maybe it's an option for the
> aforementioned insitu-OAM, or maybe a general packet CRC, etc. The
> developer dutifully uses experimental option type 0x1e for the type
> value of their option to test it. In particular, the action taken if
> the option is unknown to a receiver is to skip over it. They made that
> choice because that allows incremental deployment of the support for
> the option in any combination supporting sending side or receivers. In
> other words, they don't want a flag day for the option that requires
> all nodes to support the new option.
> 
> Now they go to test backwards comapatbility of the option by sending
> it to a node that hasn't been updated to receive it. If the receiving
> node is a Linux system, then the option is ignored and the tunneled
> packet is processed as before-- expected behavior per the spec.
> However, if it's sent to a VPP node then the packet is dropped-- not
> expected. Even if this doesn't lead to incorrectness, it does breaks
> interoperability and violates "be liberal in what you receive". This
> net effect is that this makes development, test, and pilot deployment
> of new options really hard. Just implementing the TLV loop, even if
> the implementation doesn't process any of them, would resolve this.

Absolutely. The set of _optional_ destination options would benefit from this approach.
Of which we have none. I’d much rather just implement new options as they come available (if they ever will).
If I get time, I’ll try to do some performance measurements on what the actual cost is for a software based system.

Best regards,
Ole