[IPv6]Re: Gunter Van de Velde's Discuss on draft-ietf-6man-vpn-dest-opt-05: (with DISCUSS)

[Ron Bonica <[e-mail]>]

Gunter, Eric, Ketan,

Section 3 of DISCUSS Criteria in IESG Review<https://datatracker.ietf.org/doc/statement-iesg-discuss-criteria-in-iesg-review-20140507/> enumerates discuss criteria for IESG reviews. So that I may better address your DISCUSS issues, can you please map each or them to a criteria in Section 3.1 of this document?

                                                          Ron


Juniper Business Use Only

________________________________
From: Gunter Van de Velde via Datatracker <[e-mail]>
Sent: Tuesday, April 15, 2025 7:26 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Gunter Van de Velde's Discuss on draft-ietf-6man-vpn-dest-opt-05: (with DISCUSS)

[External Email. Be cautious of content]


Gunter Van de Velde has entered the following ballot position for
draft-ietf-6man-vpn-dest-opt-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!F7NW8Qm2zpubX7Qc4lckt0yOGNFN2Zo1yU5zaB7sY1nAWI6qrkGTAC-tSKu-utjpzkZ3Cuv_ktlkCVk$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6man-vpn-dest-opt/__;!!NEt6yMaO-gk!F7NW8Qm2zpubX7Qc4lckt0yOGNFN2Zo1yU5zaB7sY1nAWI6qrkGTAC-tSKu-utjpzkZ3Cuv_AVDFG9U$



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks so much for putting this document together and for clearly laying out
the intent behind it. I  appreciate the effort to capture experimental work,
it's always valuable to explore new approaches and understand how they might
complement or improve upon existing solutions.

That said, after reviewing the draft, I’ve decided to ballot a DISCUSS, based
on two specific observations. I also want to express support for the technical
concerns raised by Ketan and Med, which I believe are valid and worth
addressing.

At a high level, this proposal does seem to outline a mechanism capable of
transporting payloads from one domain to another across a backbone (such as the
Internet or another independent domain). From a conceptual standpoint, I don’t
see any technical flaws that would prevent this from working as an experiment.

However, I do have a blocking concern that the document gives the impression
that VPNs are exclusively MPLS-based (DISCUSS-1), and it fails to acknowledge
other existing IP-based VPN technologies (DISCUSS-2). This leads to two
specific DISCUSS points:

DISCUSS-1:
The introduction seems to suggest that IPv6-based VPN solutions must use an
MPLS data plane. This overlooks the fact that both MPLS and SRv6 are capable of
supporting VPNs. The document would benefit from referencing Segment Routing
over IPv6 (SRv6) Network Programming (RFC 8986), and better positioning the
proposed IPv6 VPN Service Destination Option in relation to existing SRv6-based
VPN solutions. I realized that similar observation was made by Sue Hares
OPS-DIR review. It might not be a beauty contest, as Adrian noted in his
response to the OPS-DIR review, but adding some context about where this
solution applies, and how it compares to alternative approaches, would really
help readers/implementors to better understand the relevance and potential
value of the experiment outcome on a future standard track procedure.

DISCUSS-2:
There are several IP-based VPN solutions, particularly in the data center
space. It would be useful to acknowledge these existing technologies. A helpful
reference here is RFC 9638 ("Network Virtualization over Layer 3 (NVO3)
Encapsulation Considerations"), which offers a good comparison of technologies
in this area. Including such a comparison, or at least recognizing the
existence of these alternatives, would provide better context for the proposed
solution.

Once these DISCUSS items are addressed, I’d be happy to update my ballot to
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’m definitely open to further discussion and look forward to seeing how the
document continues to develop

Thanks again for the work on this.

Gunter Van de Velde
RTG Area Director