[IPv6]Re: WG Last Call: draft-ietf-6man-enhanced-vpn-vtn-id-15 (Ends 2026-06-11)

["Zafar Ali (zali)" <[e-mail]>]

Hi Jie,

WG's comment was to generalize the HBH header for future extensions. However, while authors claim generalization, the encoding does not generalize the HBH header. This is not a new comment; the authors have been ignoring it for years (see Appendix A).
How is it a generalization of the HBH header? The entire draft is about "Network Resource” and “Context Type (CT): One-octet field used to indicate the semantics and length of the NR ID carried in the option.”

It has also been constantly highlighted that the choices made in the current proposal make it harder to implement and affect its adoption across vendors' implementations, especially in merchant SI. The way the information is encoded suggests that authors are building a control-plane-based solution, NOT something that must be implemented in the data plane.

What is needed is very simple. The goal is to define a simple and efficient encoding that all vendors can implement. As mentioned, numerous times, the current complex encoding makes it difficult for other vendors to implement the solution and harms IPv6 adoption. Look at the MPLS encoding of the NRP.

The author's comment about the TEAS design group recommendation is also off. The design team, which included proponents of this encoding, never required the data plane to carry the “Strict Match” flag. Please also see how MPLS handles it (document is with IESG): https://www.ietf.org/archive/id/draft-ietf-mpls-mna-nrp-selector-06.html#section-2.5.
Also, the entire draft/ title is about "Carrying Network Resource (NR)” and authors removed TEAS WG core reference where all the network resource work was started [https://datatracker.ietf.org/doc/draft-ietf-teas-ns-ip-mpls/]

Please collaborate with the others and respect their concerns. Ignoring the comments, or claiming they are addressed in a convoluted way, does not make them disappear.

Appendix A: Generalization Proposal Shared Earlier

A specific proposal for HBH header generalization and NRP was shared in March 2025 or earlier, but the authors ignored it.
I am resharing the core proposal for generalizing the HBH header via a generic Data Path ID HBH as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Option Type  | Option Length |    Sub-Type   | SType Specific~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And then a subtype 1 can be assigned for the NRP Selector ID:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Option Type  | Option Length |  Sub-Type = 1 |          NRP  ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~ Selector ID (24 bits)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This will still be efficient, compact, and simple as compared to the current proposal.

Thanks

Regards … Zafar

From: Dongjie (Jimmy) <[e-mail]>
Date: Wednesday, June 10, 2026 at 11:48 AM
To: Zafar Ali (zali) <[e-mail]>; Bob Hinden <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: RE: [IPv6]WG Last Call: draft-ietf-6man-enhanced-vpn-vtn-id-15 (Ends 2026-06-11)

Hi Zafar,

Thanks again for your comments and the proposal on an alternate encoding with 32-bit NRP Selector ID. I see the core functionality is the same as the one in the current draft, the difference is mainly in the fields for extensibility, which was one of the design purposes of this option.

Please see further replies inline:

From: Zafar Ali (zali) <[e-mail]>
Sent: Wednesday, June 10, 2026 10:16 PM
To: Dongjie (Jimmy) <[e-mail]>; Bob Hinden <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Cc: Zafar Ali (zali) <[e-mail]>
Subject: Re: [IPv6]WG Last Call: draft-ietf-6man-enhanced-vpn-vtn-id-15 (Ends 2026-06-11)

Hi Jie and the WG,

Following up on my earlier email and our offline discussion during the WGLC.

I do not agree that a 32-bit NRP selector ID is needed, but if the authors insist on the NRP selector ID size, I would like to share the revised encoding shared with the authors back in March 2025 or earlier (I have a written record of an alternate encoding dated March 2025, but the encoding inefficiency comment is much older):

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |  Option Type  | Opt Data Len  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         NRP Selector ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[Jie] As discussed in the WG and also on the list, it was agreed to generalize this HBH option for applications other than NRP Selector ID, that is why the context type field was there. While this alternate encoding does not allow generalization.

This gives a 32-bit fixed value that provides the size that the authors have been asking for without the other complex encoding aspects.

  *   The flags are unnecessary complications. The S-flag is actually a local policy knob and does not need to be there in the packet. The 32-bit space allows operators to carve out NRPs with and without fallback. This kind of functionality was not seen as required for MPLS (see https://www.ietf.org/archive/id/draft-ietf-mpls-mna-nrp-selector-06.html#section-2.5) which is in IESG evaluation. Most importantly, the TEAS WG document that specifies NRP Selector ID indicates that the fallback is a local policy matter and does not bring requirements for such a flag in the packet header (see https://www.ietf.org/archive/id/draft-ietf-teas-ns-ip-mpls-07.html#section-5.1.1) Despite feedback from WG participants, the authors are not willing to make this change.

[Jie] This is NOT the conclusion made by TEAS WG on the NRP selector design principles. The conclusion of TEAS on NRP Selector ID can be found at: https://mailarchive.ietf.org/arch/msg/teas/hpvVY_De48SyMWVQ3YItEUSS-HA/. And the text related to the strict-match flag was:

   “We believe that "strict match" is the default option and that having a local policy to override this behavior would cover most operational scenarios. However, encoding the "strict match indicator" in the data packet provides more granular control and can be deemed a "nice-to-have" feature. We don't
see a strong reason not to allow this. The actual encoding of this “indicator” could differ for different data plane types and must be discussed in the respective WGs (outside the scope of TEAS).”

   The MPLS NRP selector draft you mentioned does not have the Flags field due to encoding limitation and other considerations. It does not mean IPv6 cannot have this field either. As mentioned in the conclusion of TEAS, the actual encoding could differ for different data plane types.



  *   Having “Unassigned” space in the IPv6 options header encoding seems like an odd design choice when we have PAD and PADN available for alignment (if needed). This seems like something like a control plane encoding design than something that is to be processed in hardware-based forwarding.

[Jie] The role of the unassigned field is for future extensibility, which is different from the role of PAD and PANN options. There are also other IPv6 options which include unused or reserved field for future use.

In summary, removing these fields does not improve much of the encoding efficiency, but would significantly reduce the extensibility.

Unrelated to the encoding, but still important for this document’s progression is that what is carried in the HBH option is called an NRP Selector ID that is specified in draft-ietf-teas-ns-ip-mpls which also makes it a normative reference for this document.

[Jie] The NR option specified in this draft is general and can be used not just for NRP, and the introduction of data plane NRP Selector ID for scalability was specified in draft-ietf-teas-nrp-scalability, it is considered that adding draft-ietf-teas-ns-ip-mpls to normative reference is not necessary.

Best regards,
Jie


Best regards,
Jie

Thanks

Regards … Zafar

From: Zafar Ali (zali) <[e-mail]<mailto:[e-mail]>>
Date: Thursday, June 4, 2026 at 9:34 AM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Bob Hinden <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: Zafar Ali (zali) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [IPv6]WG Last Call: draft-ietf-6man-enhanced-vpn-vtn-id-15 (Ends 2026-06-11)
Hi Jie

Please see [ZA] in-line.

Thanks

Regards … Zafar
From: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Date: Thursday, June 4, 2026 at 3:31 AM
To: Zafar Ali (zali) <[e-mail]<mailto:[e-mail]>>; Bob Hinden <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [IPv6]WG Last Call: draft-ietf-6man-enhanced-vpn-vtn-id-15 (Ends 2026-06-11)
Hi Zafar,

Thanks again for your comments.

Yes it has been discussed both during the previous meetings and offline. There was some agreement and the draft has been revised accordingly.

Please find replies inline with [Jie]:

From: Zafar Ali (zali) <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, June 4, 2026 1:15 PM
To: Bob Hinden <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: Zafar Ali (zali) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [IPv6]WG Last Call: draft-ietf-6man-enhanced-vpn-vtn-id-15 (Ends 2026-06-11)

Dear chairs and the WG

I have raised this comment many times during 6man sessions and off the list with the authors of the drafts - with alternate proposals.

This needs to be implemented in hardware, hence a simpler encoding is required.

[Jie] This encoding has taken the forwarding in hardware into consideration, and it has multiple implementations.

My concern is that encoding is super complex for the use-case.

  *   Variable length NRP ID with context

[Jie] In section 2 of the current draft, the NRP ID (CT = 0) has fixed length of 4 octets, I assume this addressed your above comment.

[ZA] No - It still keeps the encoding size to large; there is no need for variable length encoding.


  *   32-bit NRP ID for a hardware function (we are not carrying a control plan ID nor a 3GPP ID in the HBH)

[Jie] It has been discussed on the list that the space of NRP-ID should not be bound to any specific NRP implementation, and 32-bit ID is a reasonable length to cover use cases both for now and for the future. Please note this is an extension to IPv6, the design principle of which is scalability. And in the operational considerations section, text has been added to guide the allocation and management of NRP selector ID in deployments where the number of NRPs is not very large.

[ZA] This is NRP value for NRP treatment in hardware. I do not see need for 2^32 = 4,294,967,296 NRPs in hardware. In fact, I am afraid that someone will hijack the large space for some other use like finding identification of applications and violate net neutrality.

Furthermore, it was suggested that as HBH option space is limited, let’s introduce a subtype in the encoding.

[Jie] Yes, and the context type field in the current encoding provides the semantic of “subtype”. It can meet the requirement of conservative usage of IPv6 option types.

[ZA] The draft defines “context" in the context of Network Resource (NR) Option to make NRP-ID variable length and not in a generic manner. So I do not think it can be used by other use-cases.

An alternate simpler encoding was proposed to the authors.

[Jie] We had some discussion of an optional light encoding of the NRP Selector ID in IPv6 HBH. The suggestion was that if there is real need for a light encoding, it can be documented in a separate draft with a new context type or a new flag, and we would be happy to discuss with you about it. But let’s try our best to avoid multiple options in one document.

[ZA] As discussed earlier, I do not see need for two drafts for the same thing. Why an encoding that is friendly to (some) hardware implementation cannot be added in this draft?

However, these comments were never addressed, and I would like authors to address these comments before the document progression.

[Jie] Please check the above replies, hope they could address your comments.

Best regards,
Jie


Thanks

Regards … Zafar

From: Bob Hinden via Datatracker <[e-mail]<mailto:[e-mail]>>
Date: Thursday, May 28, 2026 at 4:58 PM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [IPv6]WG Last Call: draft-ietf-6man-enhanced-vpn-vtn-id-15 (Ends 2026-06-11)
This message starts a WG Last Call for:
draft-ietf-6man-enhanced-vpn-vtn-id-15

This Working Group Last Call ends on 2026-06-11

Abstract:
   Virtual Private Networks (VPNs) provide different customers with
   logically separated connectivity over a common network
   infrastructure.  With the introduction of 5G and also in some
   existing network scenarios, some customers may require network
   connectivity services with advanced features comparing to
   conventional VPN services.  Such kind of network service is called
   enhanced VPNs.  Enhanced VPNs can be used, for example, to deliver
   network slice services.

   A Network Resource Partition (NRP) is a subset of the network
   resources and associated policies on each of a connected set of links
   in the underlay network.  An NRP may be used as the underlay to
   support one or a group of enhanced VPN services.  For packet
   forwarding within a specific NRP, some fields in the data packet
   (which is called NRP Selector) need to be used to identify the NRP to
   which the packet belongs.  In doing so, NRP-specific processing can
   be performed on each node along the forwarding path in the NRP.

   This document specifies a new IPv6 Hop-by-Hop option to carry Network
   Resource related information (e.g., identifier) in data packets.  The
   NR Option can be used to carry NRP Selector ID and related
   information, while it is designed to make the NR option generalized
   for other network resource semantics and functions.

File can be retrieved from:

https://datatracker.ietf.org/doc/html/draft-ietf-6man-enhanced-vpn-vtn-id-15

Please review and indicate your support or objection to proceed with the
publication of this document by replying to this email keeping [e-mail]<mailto:[e-mail]>
in copy. Objections should be explained and suggestions to resolve them are
highly appreciated.

Authors, and WG participants in general, are reminded of the Intellectual
Property Rights (IPR) disclosure obligations described in BCP 79 [1].
Appropriate IPR disclosures required for full conformance with the provisions
of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
Sanctions available for application to violators of IETF IPR Policy can be
found at [3].

Thank you.

Bob & Jen
6man chairs

[1] https://datatracker.ietf.org/doc/bcp78/
[2] https://datatracker.ietf.org/doc/bcp79/
[3] https://datatracker.ietf.org/doc/rfc6701/

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-enhanced-vpn-vtn-id/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-6man-enhanced-vpn-vtn-id-15

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-6man-enhanced-vpn-vtn-id-15

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
--------------------------------------------------------------------