The IPv6 VPN Service Destination Option
draft-ietf-6man-vpn-dest-opt-11

Thanks for addressing my previous DISCUSS and COMMENTS. See:
https://mailarchive.ietf.org/arch/msg/ipv6/svN9H-NuO4BQ5hYx7GQdZ2ssZn0/

I am balloting an ABSTAIN because while the document is technically sound, I cannot refrain from wondering whether the IETF and the industry need yet another VPN technology. Of course, running an experiment is always nice.

[I accidently set a wrong ballot and am correcting this now]

Many thanks for resolving my DISCUSS items.
(DISCUSS comments: https://mailarchive.ietf.org/arch/msg/ipv6/cp-mlQZyo68v17FF5SdH63Wg7R4/ )

My ballot is Abstain rather than No Objection. I’m choosing to abstain because I’m not yet
fully convinced of the added value this experiment brings compared to existing,
well-established solutions. That said, from a conceptual standpoint, the
proposal seems sound and I don’t see any major issues that would prevent it
from functioning as described, so I have no intention of blocking its progress.

I would like to thank the authors for engaging in discussions as we worked on bringing more clarity to the document and framing the experiment in an appropriate context. I hope this has improved the document.

One of the key purpose of my discussion was to ascertain the unique proposition or innovation of this experiment that is beyond the bits and bytes of the packet header. I have been unable to identify any such key benefits or advantages over existing VPN technologies both from a feature capabilities or operational aspects. 

Given that this document is on an experimental track where the bar is lower (as compared to standards track), I am changing my ballot to Abstain.

I also agree with most of what Med has conveyed in his Abstain comments.

Hi Ron, Xing, Adrian, Yuji, and Luay,

Thank you for the work put into this specification. 

Also, thanks to Susan Hares for the OPSDIR review and to Adrian for the prompt reply.

Let me first insist that I’m supportive of nurturing experiments and iterate in our process. Also, I understand that an experiment does not need to cover every aspect of a solution and that a goal of an experiment is to feed that tweaking process. I won’t thus complain that the control plane considerations (which are key here) are under-specified. So, you have my sympathy for the approach being proposed here. 

That’s said, I’m not comfortable with the experiment as set, for various reasons:

* It does not solve an operator problem (at least, what I’m aware of)

* It does not introduce a unique feature to the already-saturated VPN solution space 

  + I won’t enumerate all the technologies we do already have out there. The authors are very familiar with this

  + It is not clear what is the value of this approach and what does it bring in term of innovation

* The experiment is too generic and can be applied to any IPv6 dst option.

  + The pattern used in the spec can be generalized to any similar option independent of the information it carries. Really.

* We don’t need to coin an RFC to run another experiment to see how IPv6 dst options are handled on the Internet.

* The technical foundations are questionable. For example, 

  + The base spec RFC2473 was removed from the IPv6 node requirements (was used to be cited in RFC4294 but removed from RFC6434/RFC8504). Support by routers is thus not given.

  + I’m aware of deployments based on RFC2473 but mainly for establishing individual tunnels (DS-lite, for example), though.

  + We don’t have evidence that there are current deployments where RFC2473 is used as an underly tunnel protocol for VPN purposes or whether there are operators asking for this.

      - Adding an EH is a matter of details, but the core question is elsewhere.

      -	BTW, I failed to find records where OPS area was solicited for feedback for this matter early in the process. It is too late to have that as this stage, though.

* The solution is not reliable as it depends on on-path devices behavior (e.g., discard packets with such option). 

  + An operator cannot rely on such solutions to deliver VPN services, especially that strict commitments are usually associated with such service offerings.

  + Given that dependency, deployability is really a concern. This specific experiment won’t change how IPv6 EH are handled on the Internet. Note that the document has this right (even if this can be seen as an internal inconsistency) as it says that "it is safe to deploy the VPN Service Option across the Internet" and then "However, some networks discard packets that include IPv6 Destination Options. This is an impediment to deployment".

I’m not balloting DISCUSS because I’m afraid that changes to the document won’t help me reconsider my position.

For all these reasons, I’m balloting ABSTAIN as I don’t think it is good idea to publish this document in the IETF stream.

Cheers,
Med

After dicsussion with authors, I realized that I don't think we are on a converging path. While I don't believe this document is actively harmul, like Med I am also not convinced of its use cases. Additionally, I find the naming to be too misleading. I have updated my DISCUSS to an ABSTAIN.