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

[Adrian Farrel <[e-mail]>]

I confirm agreement.

Ron has the pen, so I'll wait for him to ack that he has this in the buffer.

A

On 25/03/2025 12:00 GMT Gorry Fairhurst <[e-mail]> wrote:

 

 

On 25/03/2025 11:35, Adrian Farrel wrote:

Hi Gorry,

Welcome to the joy of reviewing documents for AD evaluation, and thanks for this review.

Thanks Adrian for getting back, and for being gentle and quick in answering my first AD evaluation that resulting in questions!

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?

Hmmm, there is a conflict of order of processing going on here, I think.
If a router is configured to ignore whole EHs then, I guess, it never looks inside to find the option that would cause it to drop the packet.

Indeed.

I think the point is that the high order bits are set to 01 meaning that if the processing router doesn't understand the option it must discard the packet. Then, if the option appears in another EH it cannot be understood so the packet will be discarded. 

Perhaps we can...
OLD
   The VPN Service Option MAY appear in a Destination Options header
   that precedes an upper-layer header.  It MUST NOT appear in any other
   extension header.  If VPN Service option appears in another extension
   header, the receiver MUST discard the packet.
NEW
   The VPN Service Option MAY appear in a Destination Options header
   that precedes an upper-layer header.  It MUST NOT appear in any other
   extension header.  If a receiver finds the VPN Service option in another
   extension header that it is processing, the option will be unrecognized,
   and according to the setting of the two highest order bits of the Option
   Type (see below), the receiver MUST discard the packet.
END

For me, this text is better, beause it explains this does not require a configured ACL. I have one niggle, that the HBH EH was changed by 6man, in RFC 9673, so that these "action bits" for the HBH do not need to result in drop. Would something like this be acceptable?

NEW
   The VPN Service Option MAY appear in a Destination Options header
   that precedes an upper-layer header.  It MUST NOT appear in any other
   extension header.  If a receiver finds the VPN Service option in another
   extension header that it is processing, the option will be unrecognized,
   and the packet MUST be processed according to the setting of the two highest 
   order bits of the Option Type (see below). 
END

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.

Hmm. Not sure. I think a DO is a DO. That is, it applies to the node identified by the destination address.
In our cases, there is IP-in-IP encapsulation. That is, the outer header has a DA that identifies the PE and carries the new DO. The inner header has a DA that identifies the "final destination" (host).
I think the host would not recognise the new DO if it showed up (and so would drop the packet), but there is no reason why it would show up.

I think no change needed here, but happy to hear suggestions.

OK (1) above improves this, and now I don't think this implies hosts have to do any special processing.

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?

First, the quote you picked is describing pre-existing MPLS VPN solutions. So not really applicable to this solution.
But it is true that the intention (i.e., the whole point of VPNs?) is that the target of the DO is the remote PE. This is a PE-to-PE communication of the VPN ID.
I don't see any substantial benefits to scoping this down to PE deployments. Practically, it is true that support only needs to be implemented on PEs. But we need to specify for what would happen if another node accidentally found the DO (errors do happen!).
The issue of nodes that are not part of the experiment is easy: the high order bits take care of it because such nodes will not recognise the Option Type.
The risk is what happens if there are two experiments going on at the same time - they need to use different experimental Option Types. But we expect a network to know which experiments are running.

I don't believe any change is needed here, but happy to hear suggestions.

Again, the text in (1) addresses this mostly, and I'm OK to clear the discuss if we have removed any implication that special processing needs to be configured in non-participating nodes.

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.

We can certainly include something like that.

Thanks.

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).

IP VPNs are widely deployed "across the Internet" and section 8 notes this as a target for deployment. In that context, I don't know what a "closed domain" is in this context. 

Perhaps, to set a context, imagine a TCP experiment. You would happily run this across the Internet and not need to limit the IP addresses to which you run it (I think).

Now, another way to think about this is how VPNs are configured in any case. Not all PEs participate in every VPN, they need to be configured for participation. So this is really pretty much the same thing.

I struggled a little to understand what would happen if multiple entities used the same experimental numbers, but if the WG was fine with this, then so am I for an experimental spec.

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.

Ack to all those.

Many thanks.
Do come back with discussion as you feel.

Adrian

Please confirm if we're in agreement,

Gorry