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

["C. M. Heard" <[e-mail]>]

On Sun, Aug 19, 2018 at 1:30 PM, Tom Herbert <[e-mail]> wrote:
> On Sat, Aug 18, 2018 at 1:22 PM, C. M. Heard <[e-mail]> wrote:
>> On Sat, Aug 18, 2018 at 11:06 AM, Tom Herbert <[e-mail]> wrote:
>>> On Sat, Aug 18, 2018 at 10:16 AM, C. M. Heard <[e-mail]> wrote:
>>>> First, the proposal makes processing of a Destination Options header that
>>>> precedes a routing header optional for the final destination node, to
>>>> which the stated rationale clearly does not apply.
>>
>> Would you care to address this objection?
>
> The allowance would have to cover all destination nodes including the
> last one because there is no way to to know a node is last in the
> routing list without processing the routing header which would violate
> RFC8200. I would note that this wouldn't impact DestOpts after a
> Routing header which must be processed only by the final destination.

True, but surely a node that can process a Destination Options header that
follows a Routing Header -- which an end node must be able to do -- also has
the capability to process a Destination Options header that precedes a
Routing Header. It should not matter whether or not it is the final
destination of the packet.

[ ... ]

>> Do you know how that
>> all works for the implementations(other than Linux) that are listed in
>> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-14#section-8?
>
> Linux properly implements Destination Options (both before and after
> Routing header), including handling of unknown TLV types. It also now
> limits the number of TLVs per the recommendations of RFC6434bis (eight
> is default limit).
>
> I looked at FD.io VPP code. AFAICT they do NOT implement compliant
> support for Destination Options. It appears that the Routing header is
> being fished for using the function ip6_ext_header_find_t. That
> function will skip over Destination Options before the Routing header.
> There are only two inconsequential references to
> IP_PROTOCOL_IP6_DESTINATION_OPTIONS (nexthdr constant) in all the VPP
> code, and I can't find any evidence that Destination Options TLVs are
> ever parsed.
>
> I looked for information on P4 how implements this an couldn't find
> much of relevance. As I understand it, P4 does not natively support
> loops so parsing an unlimited list of TLVs might not be feasible,
> although maybe it's possible to parse a small number of them.
>
> For commercial implementations, like Cisco and Juniper, I'll let it up
> to the vendors to report whether or not they have proper support for
> Destination Options and how much they have tested that.

Thanks for providing that information.

Mike Heard