[IPv6]Gorry Fairhurst's Discuss on draft-ietf-6man-vpn-dest-opt-03: (with DISCUSS and COMMENT)

[Gorry Fairhurst via Datatracker <[e-mail]>]

Gorry Fairhurst has entered the following ballot position for
draft-ietf-6man-vpn-dest-opt-03: 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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-vpn-dest-opt/



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

This EXP specification seeks to place normative requirements on configuring
nodes, but is very general as to where the option configuration needs to be
applied.

1.: The document says:

   It MUST NOT appear in any other extension header.
   If VPN Service option appears in another extension
   header, the receiver MUST discard the packet.

This adds a requirement to drop a packet if the new option appears in a HBH EH,
whereas the processing defined in RFC 9673 would skip this option if present in
a HBH EH, and therefore would require explicit configuration to drop this
packet. Can the rule for the HBH EH be to ignore this option?

2. I understand the intent is to specify a new DO for use by a router at the PE
edge. However, I cannot tell from the text whether this experiment is also
scoped to require filtering of destination options that are processed by the
final destination of the packet (host) (see Section 4.1., Note 2) of RFC 8200.
This does not seem to be quite what was intended.

3. Section 7 assumes that the only processing of this option is by an egress PE
device. It says “It cannot be deployed where one or both of the PEs does not
support MPLS.”  Would scoping the receiver processing rules only to egress PE
devices reduce the deployment challenges in using an experimental number?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. Section 9 does not explain how to clean-up after the experiment. Section 1.1
of RFC 3692 includes text that I thought was helpful, and I’m surprised that
this text (preferably quoted as-is) did not appear in this document’s
deployment section.

   When protocols that use experimental numbers are included in
   products, the shipping versions of the products must disable
   recognition of protocol experimental numbers by default -- that is,
   the end user of the product must explicitly "turn on" the
   experimental protocol functionality.

2. The text in section 8 only seems to assume “care” about potentially
overlapping use. I recognise that the experimental numbers are not guaranteed
to be unique in any environment, however could this format include a prefix
that could help distinguish this experiment from other uses. For example, I’m
curious why the option does not include an identifier to associate it with the
closed domain in which it is intended to operate? That might reduce the
potential for accidental misinterpretation if a packet was forwarded to another
closed domain. Even a short randomly chosen identifier could help reduce any
confusion if this same code point was to be used by another experimental option
(or perhaps more significantly were to remain deployed at the end of the
experiment).

4. Please could you fix the following NiTs:
/OAM mechanism/OAM mechanisms/
/If VPN Service option/If the VPN Service option/
/Was there a need to synchronize configurations at each node or could nodes be
configured independently/ please add a question mark.