Subject: RE: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 1 Feb 2022 12:39:59 +0000

Hi all,
I support the adoption of the draft.
My reasoning is the same: https://mailarchive.ietf.org/arch/msg/ipv6/JvNCp7ud19kKJgd_dSuMZPkmfak/
Slice ID should be somewhere close to the head of headers. It should be checked as easily as DSCP or Flow label.
Not deep inside like "UDP port range" (adopted by rtgwg for Mobile) or "VPN label".
Eduard
-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: Wednesday, January 26, 2022 9:49 PM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

This message starts a two week 6MAN call on adopting:

 Title:          Carrying Virtual Transport Network (VTN) Identifier in IPv6 Extension
                 Header
 Authors:        J. Dong, Z. Li, C. Xie, C. Ma, G. Mishra
 File Name:      draft-dong-6man-enhanced-vpn-vtn-id-06
 Document date:  October 24, 2021

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dong-6man-enhanced-vpn-vtn-id-06&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C6d0fe5a32a704e6af1ea08d9e158d1e6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637788593911783663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=pVqfoAtUACR8AIwQWvTA4729LasKqunE7HmPogh8McA%3D&amp;reserved=0

as a working group document.  Substantive comments and statements of support for adopting this document should be sent to the mailing list.  Editorial suggestions can be sent to the authors.  This adoption call will end on 10 February 2022.

Further, if you are willing to work on this document, either as contributor, author, or reviewer please notify the list.   This will provide the chairs with an indication of the energy level in the working group to work on this document.

Bob & Ole
6man Chairs

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 1 Feb 2022 19:45:15 -0000

Hi Bob, all,

I just read the most recent copy of this draft:

I support adoption and promise to review the document further within the
working group.

Here are some comments on the current version which, IMHO, do not need to be
fixed until after adoption.

- Admirably short!
- The BCP 14 boilerplate seems to be very slightly broken
- I think the reference to draft-hinden-6man-hbh-processing is
   important, but:
     - that draft has expired
     - fortunately there is now draft-ietf-6man-hbh-processing
        (perhaps the chairs could sort out the "replaced by" links)
     - I think the reference should actually be normative
- I looked at this draft from the perspective of
  draft-ietf-teas-ietf-network-slices, of which I am editor, and
  draft-ietf-teas-enhanced-vpn, into which I have put some effort.
     - I'm pleased to see alignment of terminology
     - It might be helpful to reference the TEAS slicing draft where
        this document mentions slicing
- I am unclear of the purpose of the editor's note in section 2, nor
  the inclusion of Figure 2.
     - The combination of those things makes it seem like the VTN
        Resource ID must be partitioned 8/24 as shown in the figure.
        I don't think that is the intention (or a good idea, in general).
     - There is not a lot of value in reproducing a figure from another
        (referenced) document.
     - The "Editor's note" and figure could perhaps be replaced with
        something like:
        Note that, if a deployment found it useful, the four-octet VTN
        Resource ID field could hold the four-octet Single Network Slice
        Selection Assistance Information (S-NSSAI) defined in 3GPP 
        [TS23501].
- Sections 3, 3.1, and 3.2 contain "SHOULD" and I don't understand
  how/why an implementation would vary from that. The text needs
  to give guidance or use "MUST".

Best,
Adrian
-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: 27 January 2022 05:49
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

 Title:          Carrying Virtual Transport Network (VTN) Identifier in IPv6
Extension
                 Header
 Authors:        J. Dong, Z. Li, C. Xie, C. Ma, G. Mishra
 File Name:      draft-dong-6man-enhanced-vpn-vtn-id-06
 Document date:  October 24, 2021

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

as a working group document.  Substantive comments and statements of support
for adopting this document should be sent to the mailing list.  Editorial
suggestions can be sent to the authors.  This adoption call will end on 10
February 2022.

Further, if you are willing to work on this document, either as contributor,
author, or reviewer please notify the list.   This will provide the chairs
with an indication of the energy level in the working group to work on this
document.

Bob & Ole
6man Chairs

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 1 Feb 2022 20:35:10 +0000

Hi Everyone,

    I read through the draft and support its adoption.

Best Regards,
Huaimo
-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: 27 January 2022 05:49
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dong-6man-enhanced-vpn-vtn-id-06&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C15728496c6bc438c9cde08d9e5bb6dae%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637793415441529229%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=b7M8o6XQC8QuDZGApUoH10gw%2Fd2tSpd0T%2Fi4y5aDWJ0%3D&amp;reserved=0

Bob & Ole
6man Chairs

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C15728496c6bc438c9cde08d9e5bb6dae%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637793415441529229%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=d36rHrks7xfma%2FOhErSL%2FO1WRHKx3yQEM0Q0FFqzxr4%3D&amp;reserved=0
--------------------------------------------------------------------

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 1 Feb 2022 18:44:01 -0800

Dear All,
apologies for the late reply.
If the VTN-ID is a piece of critical information that must be processed by
each transient node, then using HBH EH seems like a wrong choice. Firstly,
currently, packets with EH might get dropped.
Even draft-ietf-6man-hbh-processing makes the processing of an HBH EH
conditional on the traffic load and processing capability of the node fast
path.
On the other hand, if VTN-ID is not critical to the operation, then Why
bother at all?

Regards,
Greg

On Wed, Jan 26, 2022 at 9:49 PM Bob Hinden <[email-masked]> wrote:

> as a working group document.  Substantive comments and statements of
> support for adopting this document should be sent to the mailing list.
> Editorial suggestions can be sent to the authors.  This adoption call will
> end on 10 February 2022.
>
> Further, if you are willing to work on this document, either as
> contributor, author, or reviewer please notify the list.   This will
> provide the chairs with an indication of the energy level in the working
> group to work on this document.
>
> Bob & Ole
> 6man Chairs
>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Wed, 2 Feb 2022 10:28:08 +0000

Dear All,
I have read the draft and support its adoption. 

The document defines a new HBH option to carry the VTN ID. It can be processed by each node along the path in order to enable network slice services with guaranteed resources.
This proposal may also benefit from the renewed effort of 6MAN WG to make processing of IPv6 HBH options more practical.

Best Regards,

Giuseppe

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: Thursday, January 27, 2022 6:49 AM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

Bob & Ole
6man Chairs

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 4 Feb 2022 01:38:45 +0000

Hi Greg,

Thanks for your comment. Your concern about the packet drop has been considered in this document. The operational considerations section says:

“Operator needs to make sure that all the network nodes involved in a VTN can either process Hop-by-Hop Options header in the fast path, or ignore the Hop-by-Hop Option header. Since a VTN is associated with a logical network topology, it is practical to ensure that all the network nodes involved in that logical topology support the processing of the HBH options header and the VTN option. In other word, packets steered into a VTN MUST NOT be dropped due to the existence of the Hop-by-Hop Options header.”

As you mentioned draft-ietf-6man-hbh-processing is working to make HBH EH practical and help its deployment in the network, and the WG has agreed on this direction. Thus for the VTN per-hop processing behavior, using HBH EH would be the most suitable approach for IPv6 data plane.

Best regards,
Jie

From: ipv6 [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Wednesday, February 2, 2022 10:44 AM
To: Bob Hinden <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: Re: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

Dear All,
apologies for the late reply.
If the VTN-ID is a piece of critical information that must be processed by each transient node, then using HBH EH seems like a wrong choice. Firstly, currently, packets with EH might get dropped. Even draft-ietf-6man-hbh-processing makes the processing of an HBH EH conditional on the traffic load and processing capability of the node fast path.
On the other hand, if VTN-ID is not critical to the operation, then Why bother at all?

Regards,
Greg

On Wed, Jan 26, 2022 at 9:49 PM Bob Hinden <[email-masked]<mailto:[email-masked]>> wrote:
This message starts a two week 6MAN call on adopting:

Bob & Ole
6man Chairs

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 3 Feb 2022 17:54:42 -0800

Hi Jie,
thank you for your response. I have some follow-up questions:

   - It appears to me that if a node skips the HBH EH that carries the
   VTN-ID, the node cannot apply policies required for the VTN. As a result,
   the SLA of the VTN might be violated. If conforming to the SLA is required,
   skipping the HBH EH seems as damaging as dropping a packet.
   - Also, it is not clear how an operator can verify that all nodes in an
   VTN domain are capable of processing the HBH EH in the fast path. Consider
   that the number of HBH EHs changes over time and thus the ability to
   process them in the fast path. Perhaps a node should periodically report on
   handling of HBH EH.

Regards,
Greg

On Thu, Feb 3, 2022 at 5:38 PM Dongjie (Jimmy) <[email-masked]> wrote:

> Hi Greg,
>
>
>
> Thanks for your comment. Your concern about the packet drop has been
> considered in this document. The operational considerations section says:
>
>
>
> “Operator needs to make sure that all the network nodes involved in a VTN
> can either process Hop-by-Hop Options header in the fast path, or ignore
> the Hop-by-Hop Option header. Since a VTN is associated with a logical
> network topology, it is practical to ensure that all the network nodes
> involved in that logical topology support the processing of the HBH options
> header and the VTN option. In other word, packets steered into a VTN MUST
> NOT be dropped due to the existence of the Hop-by-Hop Options header.”
>
>
>
> As you mentioned draft-ietf-6man-hbh-processing is working to make HBH EH
> practical and help its deployment in the network, and the WG has agreed on
> this direction. Thus for the VTN per-hop processing behavior, using HBH EH
> would be the most suitable approach for IPv6 data plane.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* ipv6 [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Greg Mirsky
> *Sent:* Wednesday, February 2, 2022 10:44 AM
> *To:* Bob Hinden <[email-masked]>
> *Cc:* IPv6 List <[email-masked]>
> *Subject:* Re: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>
>
>
>
> Dear All,
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 5 Feb 2022 03:02:26 +0000

Hi Adrian,

Thanks for your support and comment. Please see some replies inline:

> From: ipv6 [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, February 2, 2022 3:45 AM
> To: 'Bob Hinden' <[email-masked]>; 'IPv6 List' <[email-masked]>
> Subject: RE: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>
> 
> Hi Bob, all,
> 
> Here are some comments on the current version which, IMHO, do not need to
> be fixed until after adoption.
> 
> - Admirably short!

Thanks for pointing this out, we will fix the boilerplate in next version. 

>      - I think the reference should actually be normative

We will refer to the recently adopted draft-ietf-6man-hbh-processing in next version. 

>         this document mentions slicing

Agreed and we can add some text and a reference to the teas slicing draft. 

>         I don't think that is the intention (or a good idea, in general).

No, that was not our intention. It is just to show that the length of the S-NSSAI is 4 octets.

>      - There is not a lot of value in reproducing a figure from another

Agreed. We can remove that figure in next version.

>         Selection Assistance Information (S-NSSAI) defined in 3GPP

Thanks for the suggestion. It looks good to me. 

>   to give guidance or use "MUST".

We will review the whole document and replace the "SHOULD" with "MUST" where appropriate. 

Many thanks,
Jie

> Editorial suggestions can be sent to the authors.  This adoption call will end
> on 10 February 2022.
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 5 Feb 2022 01:32:25 -0500

Hi Greg

Here are some possible answers in-line to your questions.

Kind Regards

On Thu, Feb 3, 2022 at 8:55 PM Greg Mirsky <[email-masked]> wrote:

>         Gyan> The primary use case for TEAS Network Slicing framework is
for MBB 5G UE fixed wireless access N6 interface network slicing over RAN
x-haul for slice services to CN 5G Edge compute Data Centers.  So this HBH
processing would be within a closed or limited domain.  As  all nodes would
be within the same administrative control with a common policy can be
applied to ensure a standard processing of HBH in the fast path policy.
HBH processing has been widely successful in closed domains for a long time
now.  The major gap that the Hinden HBH draft addresses as well as v6OPS
draft below of which I am Co-Author are both related to the problem
statement with HBH processing is over the internet.

https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-hbh-00

This was mentioned by Pascal Thubert during the Hinden HBH adoption call
use case today of HBH in limited domains RFC 6553 RPL Routing Protocol for
Low Powered Networks.

“See also RFC 6553 (used by millions of deployed nodes in IoT networks) and
https://datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh, which
allows ot signal DetNet at L3, the alternate being above UDP.”

>    - Also, it is not clear how an operator can verify that all nodes in
>    an VTN domain are capable of processing the HBH EH in the fast path.
>    Consider that the number of HBH EHs changes over time and thus the ability
>    to process them in the fast path. Perhaps a node should periodically report
>    on handling of HBH EH.
>
>       Gyan> Similar answer ad above and the key here is limited domain for
5G slicing use case. So the number of EHs can be limited to this single EH
option as a standard policy.  Also as is transport underlay layer closed
domain the customer traffic is the one that is worrisome and that sits in
the overlay payload so no impact to the transport underlay outer IPv6
header HBH processing of VTN ID.

Regards,
>> If the VTN-ID is a piece of critical information that must be processed
>> by each transient node, then using HBH EH seems like a wrong choice.
>> Firstly, currently, packets with EH might get dropped.
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: 庞冉(联通集团中国联通研究院-本部) <[email-masked]>
Date: Sun, 6 Feb 2022 13:55:03 +0000

Hi all,

I have read this document and support its adoption.

It provides a useful and straightforward mechanism to identify different set of network resources allocated to virtual underlay networks, which could be used to provide network slice services.

Best regards,
Pang Ran.

From: Bob Hinden<mailto:[email-masked]>
Date: 2022-01-27 13:49
To: IPv6 List<mailto:[email-masked]>
CC: Bob Hinden<mailto:[email-masked]>
Subject: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>
This message starts a two week 6MAN call on adopting:

Bob & Ole
6man Chairs

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 7 Feb 2022 03:15:32 +0000

Hi Greg,

Thanks for your comments, please see further replies inline:

From: Greg Mirsky [mailto:[email-masked]]
Sent: Friday, February 4, 2022 9:55 AM
To: Dongjie (Jimmy) <[email-masked]>
Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

Hi Jie,

  *   It appears to me that if a node skips the HBH EH that carries the VTN-ID, the node cannot apply policies required for the VTN. As a result, the SLA of the VTN might be violated. If conforming to the SLA is required, skipping the HBH EH seems as damaging as dropping a packet.
[Jie] As described further in the operational considerations section: For network scenarios where conforming to VTN specific processing is required, it is recommended to configure all the network nodes involved in a VTN to process the Hop-by-Hop Options header and the VTN option if there is a nob for this. As mentioned by Gyan, this can be achieved for networks in a limited domain.
For other network scenarios where the HBH EH may be skipped, the packet can still be delivered with best effort service, which ensures backward compatibility and is usually a better choice than packet drop.

  *   Also, it is not clear how an operator can verify that all nodes in an VTN domain are capable of processing the HBH EH in the fast path. Consider that the number of HBH EHs changes over time and thus the ability to process them in the fast path. Perhaps a node should periodically report on handling of HBH EH.
[Jie] Similar to other capabilities of the network nodes,  operator could obtain the HBH EH capability either via the management system or some capability advertisement mechanism. The details of such mechanisms are out of the scope of this document. We could add brief description about this if the WG thinks it is helpful.
Best regards,
Jie

Regards,
Greg

On Thu, Feb 3, 2022 at 5:38 PM Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Best regards,
Jie

Dear All,

Regards,
Greg

Bob & Ole
6man Chairs

---

From: Yingzhen Qu <[email-masked]>
Date: Sun, 6 Feb 2022 21:20:25 -0800

Hi,

I’ve read the draft and I support the adoption.

This is a good use of the IPv6 HBH Options Header to achieve guaranteed services with resource reservation. 

I’ll review the document further within the WG.

Thanks,
Yingzhen

> On Jan 26, 2022, at 9:49 PM, Bob Hinden <[email-masked]> wrote:
>

---

From: Fred Baker <[email-masked]>
Date: Sun, 6 Feb 2022 21:49:14 -0800

I’m scratching my head on this one. My issue is not 5G etc, it is what the fact of IPv6 packets being carried in a slice has nothing obvious to do with IPv6. Carrying the VTN ID in a hop-by-hop option appears to mostly facilitate ignoring the rest of the very large IPv6 header, which is a waste of space relegated to supporting the packet when the provider has not built a circuit-switch network supporting slices.

What is the argument in favor of this?  

Sent from my iPad

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 7 Feb 2022 09:29:33 +0000

Hi Fred, 

Thanks for your review and interest in this document. 

As described in section 3.2, with the mechanism defined in this document, the packet forwarding is based on both the destination IP address and the VTN Resource ID. More specifically, the destination IP address is used to determine the next-hop and the outgoing interface, and VTN Resource ID is used to determine the set of network resources on the outgoing interface which are reserved to the VTN for processing and sending the packet. Thus it is still IP based forwarding paradigm and circuit-switching is not required. Since it needs to ensure that on each hop the packet is processed and forwarded using the network resources allocated to the corresponding VTN, the HBH EH is a good fit for the required behavior. 

Hope this helps.

Best regards,
Jie

> From: ipv6 [mailto:[email-masked]] On Behalf Of Fred Baker
> Sent: Monday, February 7, 2022 1:49 PM
> To: Bob Hinden <[email-masked]>
> Cc: IPv6 List <[email-masked]>
> I’m scratching my head on this one. My issue is not 5G etc, it is what the fact
> of IPv6 packets being carried in a slice has nothing obvious to do with IPv6.
> Carrying the VTN ID in a hop-by-hop option appears to mostly facilitate
> ignoring the rest of the very large IPv6 header, which is a waste of space
> relegated to supporting the packet when the provider has not built a
> circuit-switch network supporting slices.
> 
> author, or reviewer please notify the list.   This will provide the chairs with an
> indication of the energy level in the working group to work on this document.
> >
> > Bob & Ole
> > 6man Chairs
> >

---

From: <[email-masked]>
Date: Tue, 8 Feb 2022 09:09:43 +0800 (CST)

Hi Greg & Gyan，

I agree with Greg, the VTN-ID of this draft needs more discussion before adoption. Here are my additional concerns:

If we consider the sceneriars of 5G Slice, it is more normal to use the identifier such as VLAN ID. It's not very clear to use IPv6 HBH header.

As my understanding, IETF Slicing DT is still discussing the related topics. It might be more reasonable to adopt this draft after IETF Slicing DT's work have done.

原始邮件

发件人：GyanMishra
收件人：Greg Mirsky;
抄送人：Bob Hinden;IPv6 List;
日 期 ：2022年02月05日 14:33
主 题 ：Re: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

Hi Greg 

Kind Regards 

Hi Jie,thank you for your response. I have some follow-up questions:
It appears to me that if a node skips the HBH EH that carries the VTN-ID, the node cannot apply policies required for the VTN. As a result, the SLA of the VTN might be violated. If conforming to the SLA is required, skipping the HBH EH seems as damaging as dropping a packet.

        Gyan> The primary use case for TEAS Network Slicing framework is for MBB 5G UE fixed wireless access N6 interface network slicing over RAN x-haul for slice services to CN 5G Edge compute Data Centers.  So this HBH processing would be within a closed or limited domain.  As  all nodes would be within the same administrative control with a common policy can be applied to ensure a standard processing of HBH in the fast path policy.  HBH processing has been widely successful in closed domains for a long time now.  The major gap that the Hinden HBH draft addresses as well as v6OPS draft below of which I am Co-Author are both related to the problem statement with HBH processing is over the internet.  

This was mentioned by Pascal Thubert during the Hinden HBH adoption call use case today of HBH in limited domains RFC 6553 RPL Routing Protocol for Low Powered Networks.

“See also RFC 6553 (used by millions of deployed nodes in IoT networks) and https://datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh, which allows ot signal DetNet at L3, the alternate being above UDP.”

Also, it is not clear how an operator can verify that all nodes in an VTN domain are capable of processing the HBH EH in the fast path. Consider that the number of HBH EHs changes over time and thus the ability to process them in the fast path. Perhaps a node should periodically report on handling of HBH EH.

      Gyan> Similar answer ad above and the key here is limited domain for 5G slicing use case. So the number of EHs can be limited to this single EH option as a standard policy.  Also as is transport underlay layer closed domain the customer traffic is the one that is worrisome and that sits in the overlay payload so no impact to the transport underlay outer IPv6 header HBH processing of VTN ID.

Regards,

Greg

Hi Greg,

 

 

 

Best regards,

Jie

 

Dear All,

 

Regards,

Greg

 

 
 
 Bob & Ole
 6man Chairs

-- 

Gyan Mishra

Network Solutions Architect 

Email [email-masked]

M 301 502-1347

---

From: Erik Kline <[email-masked]>
Date: Mon, 7 Feb 2022 17:22:43 -0800

Liu,

Which IETF slicing DT are you referring to?  The one I was aware of from
TEAS [1] doesn't seem to have seen any traffic since March 2021, if I read
that archive link correctly.

Thanks,
-ek

[1] https://mailarchive.ietf.org/arch/browse/teas-ns-dt/

On Mon, Feb 7, 2022 at 5:10 PM <[email-masked]> wrote:

>
> Hi Greg & Gyan，
>
> I agree with Greg, the VTN-ID of this draft needs more discussion before
> adoption. Here are my additional concerns:
>
>    1.
>
>    If we consider the sceneriars of 5G Slice, it is more normal to use
>    the identifier such as VLAN ID. It's not very clear to use IPv6 HBH header.
>    2.
>
>    As my understanding, IETF Slicing DT is still discussing the related
>    topics. It might be more reasonable to adopt this draft after IETF Slicing
>    DT's work have done.
>
>
> 原始邮件
> *发件人：*GyanMishra
> *收件人：*Greg Mirsky;
> *抄送人：*Bob Hinden;IPv6 List;
> *日 期 ：*2022年02月05日 14:33
> *主 题 ：**Re: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>*
>>    -
>>    It appears to me that if a node skips the HBH EH that carries the
> “See also RFC 6553 (used by millions of deployed nodes in IoT networks)
> and https://datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh,
> which allows ot signal DetNet at L3, the alternate being above UDP.”
>
>
>>    -
>>
>>    Also, it is not clear how an operator can verify that all nodes in an
>>       Gyan> Similar answer ad above and the key here is limited domain
> for 5G slicing use case. So the number of EHs can be limited to this single
> EH option as a standard policy.  Also as is transport underlay layer closed
>>> “Operator needs to make sure that all the network nodes involved in a
>>> VTN can either process Hop-by-Hop Options header in the fast path, or
>>> ignore the Hop-by-Hop Option header. Since a VTN is associated with a
>>> logical network topology, it is practical to ensure that all the network
>>> nodes involved in that logical topology support the processing of the HBH
>>> options header and the VTN option. In other word, packets steered into a
>>> VTN MUST NOT be dropped due to the existence of the Hop-by-Hop Options
>>> header.”
>>>
>>>
>>>
>>> As you mentioned draft-ietf-6man-hbh-processing is working to make HBH
>>> EH practical and help its deployment in the network, and the WG has agreed
>>> on this direction. Thus for the VTN per-hop processing behavior, using HBH
>>> EH would be the most suitable approach for IPv6 data plane.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Jie
>>>
>>>   <http://null>
>>>

---

From: <[email-masked]>
Date: Tue, 8 Feb 2022 09:55:52 +0800 (CST)

Yes, I refer to that one from TEAS. I think the DT is discussing the high level of IETF network slicing, so I suggest other detail drafts including this one to wait the DT's progress.

原始邮件

发件人：ErikKline
收件人：刘爱华10024999;
抄送人：Gyan Mishra;Greg Mirsky;IPv6 List;Bob Hinden;
日 期 ：2022年02月08日 09:23
主 题 ：Re: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

Liu,

Which IETF slicing DT are you referring to?  The one I was aware of from TEAS [1] doesn't seem to have seen any traffic since March 2021, if I read that archive link correctly.

Thanks,
-ek

Hi Greg & Gyan，

原始邮件

发件人：GyanMishra
收件人：Greg Mirsky;

Hi Greg 

Kind Regards 

Regards,

Greg

Hi Greg,

 

 

 

Best regards,

Jie

 

Dear All,

 

Regards,

Greg

 

 
 
 Bob & Ole
 6man Chairs

-- 

Gyan Mishra

M 301 502-1347

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 7 Feb 2022 21:07:26 -0500

As far as I know, that design team has completed it's work.  After a 
working group adoption call, an editor (Adrian) edited the document 
according to the WG agreements.  And the WG is now working on the 
document (and other related documents.)

Yours,
Joel

On 2/7/2022 8:55 PM, [email-masked] wrote:
> Yes, I refer to that one from TEAS. I think the DT is discussing the 
> high level of IETF network slicing, so I suggest other detail drafts 
> including this one to wait the DT's progress.
> 
> 
> 原始邮件
> *发件人：*ErikKline
> *收件人：*刘爱华10024999;
> *抄送人：*Gyan Mishra;Greg Mirsky;IPv6 List;Bob Hinden;
> *日 期 ：*2022年02月08日 09:23
> TEAS [1] doesn't seem to have seen any traffic since March 2021, if I 
> read that archive link correctly.
> 
> Thanks,
> -ek
> 
> <https://mailarchive.ietf.org/arch/browse/teas-ns-dt/>
> 
> On Mon, Feb 7, 2022 at 5:10 PM <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     Hi Greg & Gyan，
> 
>     I agree with Greg, the VTN-ID of this draft needs more discussion
>     before adoption. Here are my additional concerns:
> 
>      1.
> 
>         If we consider the sceneriars of 5G Slice, it is more normal to
>         use the identifier such as VLAN ID. It's not very clear to use
>         IPv6 HBH header.
> 
>      2.
> 
>         As my understanding, IETF Slicing DT is still discussing the
>         related topics. It might be more reasonable to adopt this draft
>         after IETF Slicing DT's work have done.
> 
> 
>     原始邮件
>     *发件人：*GyanMishra
>     *收件人：*Greg Mirsky;
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ipv6>
>     On Thu, Feb 3, 2022 at 8:55 PM Greg Mirsky <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi Jie,
>           *
>             It appears to me that if a node skips the HBH EH
>             that carries the VTN-ID, the node cannot apply policies
>             required for the VTN. As a result, the SLA of the VTN might
>             be violated. If conforming to the SLA is required, skipping
>             the HBH EH seems as damaging as dropping a packet.
> 
>              Gyan> The primary use case for TEAS Network Slicing
>     framework is for MBB 5G UE fixed wireless access N6 interface
>     network slicing over RAN x-haul for slice services to CN 5G Edge
>     compute Data Centers.  So this HBH processing would be within a
>     closed or limited domain.  As  all nodes would be within the same
>     administrative control with a common policy can be applied to ensure
>     a standard processing of HBH in the fast path policy.  HBH
>     processing has been widely successful in closed domains for a long
>     time now.  The major gap that the Hinden HBH draft addresses as well
>     as v6OPS draft below of which I am Co-Author are both related to the
>     problem statement with HBH processing is over the internet.
> 
>     <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-hbh-00>
> 
>     This was mentioned by Pascal Thubert during the Hinden HBH adoption
>     call use case today of HBH in limited domains RFC 6553 RPL Routing
>     Protocol for Low Powered Networks.
> 
>     https://datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh
>     <https://datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh>,
>           *
>             Also, it is not clear how an operator can verify that all
>             nodes in an VTN domain are capable of processing the HBH EH
>             in the fast path. Consider that the number of HBH EHs
>             changes over time and thus the ability to process them in
>             the fast path. Perhaps a node should periodically report on
>             handling of HBH EH.
> 
>            Gyan> Similar answer ad above and the key here is limited
>     domain for 5G slicing use case. So the number of EHs can be limited
>     to this single EH option as a standard policy.  Also as is transport
>     underlay layer closed domain the customer traffic is the one that is
>     worrisome and that sits in the overlay payload so no impact to the
>     transport underlay outer IPv6 header HBH processing of VTN ID.
> 
>         Regards,
>         Greg
> 
>         On Thu, Feb 3, 2022 at 5:38 PM Dongjie (Jimmy)
>         <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             Hi Greg,
> 
>             Thanks for your comment. Your concern about the packet drop
>             has been considered in this document. The operational
>             considerations section says:
> 
>             “Operator needs to make sure that all the network nodes
>             involved in a VTN can either process Hop-by-Hop Options
>             header in the fast path, or ignore the Hop-by-Hop Option
>             header. Since a VTN is associated with a logical network
>             topology, it is practical to ensure that all the network
>             nodes involved in that logical topology support the
>             processing of the HBH options header and the VTN option. In
>             other word, packets steered into a VTN MUST NOT be dropped
>             due to the existence of the Hop-by-Hop Options header.”
> 
>             As you mentioned draft-ietf-6man-hbh-processing is working
>             to make HBH EH practical and help its deployment in the
>             network, and the WG has agreed on this direction. Thus for
>             the VTN per-hop processing behavior, using HBH EH would be
>             the most suitable approach for IPv6 data plane.
> 
>             Best regards,
> 
>             Jie
> 
>             <http://null>
> 
>             *From:*ipv6 [mailto:[email-masked]
>             <mailto:[email-masked]>] *On Behalf Of *Greg Mirsky
>             *To:* Bob Hinden <[email-masked]
>             <mailto:[email-masked]>>
>             *Cc:* IPv6 List <[email-masked] <mailto:[email-masked]>>
>             If the VTN-ID is a piece of critical information that must
>             be processed by each transient node, then using HBH EH seems
>             like a wrong choice. Firstly, currently, packets with EH
>             might get dropped. Even draft-ietf-6man-hbh-processing makes
>             the processing of an HBH EH conditional on the traffic load
>             and processing capability of the node fast path.
> 
>             On Wed, Jan 26, 2022 at 9:49 PM Bob Hinden
>             <[email-masked] <mailto:[email-masked]>> wrote:
> 
>                 <https://datatracker.ietf.org/doc/html/draft-dong-6man-enhanced-vpn-vtn-id-06>
> 
>                 as a working group document.  Substantive comments and
>                 statements of support for adopting this document should
>                 be sent to the mailing list.  Editorial suggestions can
>                 be sent to the authors.  This adoption call will end on
>                 10 February 2022.
> 
>                 Further, if you are willing to work on this document,
>                 either as contributor, author, or reviewer please notify
>                 the list.   This will provide the chairs with an
>                 [email-masked] <mailto:[email-masked]>
>                 Administrative Requests:
>                 https://www.ietf.org/mailman/listinfo/ipv6
>                 <https://www.ietf.org/mailman/listinfo/ipv6>
>         [email-masked] <mailto:[email-masked]>
>         Administrative Requests:
>         https://www.ietf.org/mailman/listinfo/ipv6
>         <https://www.ietf.org/mailman/listinfo/ipv6>
>     /Network Solutions A//rchitect /
> 
>     /Email [email-masked] <mailto:[email-masked]>//
>     /
> 
>     /M 301 502-1347
> 
>     /
> 
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: <[email-masked]>
Date: Tue, 8 Feb 2022 10:27:25 +0800 (CST)

Many thanks for updating the work of DT, My point is the IETF Slice ID needs more discussion in current phase.

原始邮件

发件人：JoelM.Halpern
收件人：刘爱华10024999;[email-masked];
抄送人：[email-masked];[email-masked];
日 期 ：2022年02月08日 10:07
主 题 ：Re: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

Yours,
Joel

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 8 Feb 2022 04:50:00 +0000

I agree that it is too early to adopt this work and we need to see if HbH is the right place to identify the slice ID.

From: ipv6 <[email-masked]> on behalf of [email-masked] <[email-masked]>
Date: Tuesday, 8 February 2022 at 03:28
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re:Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

原始邮件
发件人：JoelM.Halpern

Yours,
Joel

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 8 Feb 2022 06:27:58 +0000

So, here, 6MAN is the right place to discuss where to accommodate the slice ID.
IMO, HbH is the right place.

From: ipv6 [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Tuesday, February 8, 2022 12:50 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Re:Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 8 February 2022 at 03:28
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re:Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

原始邮件
发件人：JoelM.Halpern
抄送人：[email-masked];[email-masked]<mailto:[email-masked];[email-masked]>;

Yours,
Joel

<mailto:[email-masked] %20%0b>> <mailto:[email-masked]>> wrote:
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
<mailto:[email-masked]%0b>>     <mailto:[email-masked]>> wrote:
>         <[email-masked] <mailto:[email-masked]<mailto:[email-masked] %3cmailto:[email-masked]>>> wrote:
>
>             Hi Greg,
>
>             <mailto:[email-masked]><mailto:[email-masked]%0b%3e             %3cmailto:[email-masked]%3e>] *On Behalf Of *Greg Mirsky
<mailto:[email-masked]%0b>>             <mailto:[email-masked]>>
>             *Cc:* IPv6 List <[email-masked] <mailto:[email-masked]<mailto:[email-masked] %3cmailto:[email-masked]>>>
>             <[email-masked] <mailto:[email-masked]<mailto:[email-masked] %3cmailto:[email-masked]>>> wrote:
>
>                 [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>                 Administrative Requests:
>         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>         Administrative Requests:
>     /Email [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>//
>     /
>
>     /M 301 502-1347
>
>     /
>
>
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 8 Feb 2022 07:52:39 +0000

Hi all,
I was very surprised last year when I have understood that 5 years after the heavy promotion of Slicing
IETF has not defined yet the data plane label for it.
It is going to be the situation when every WG is defining something special.
The VLAN ID is not the worst.
The prize should go to draft-ietf-dmm-tn-aware-mobility where slice ID is the “UDP source port range”
That is already supported and proliferated to other WGs: rtgwg-extension-tn-aware-mobility.

Hence, IETF is 5 years late with the “Unified Slice ID” definition. A lot of harm is already done.

PS: Why I am not happy about the VLAN ID:

1.       It is L2 but we are talking about slicing at L3.

2.       VLAN is not universally available, for example, wireless
Eduard
From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, February 8, 2022 4:10 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re:Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

Hi Greg & Gyan，

1.    If we consider the sceneriars of 5G Slice, it is more normal to use the identifier such as VLAN ID. It's not very clear to use IPv6 HBH header.

2.    As my understanding, IETF Slicing DT is still discussing the related topics. It might be more reasonable to adopt this draft after IETF Slicing DT's work have done.

原始邮件
发件人：GyanMishra
收件人：Greg Mirsky;

Kind Regards

On Thu, Feb 3, 2022 at 8:55 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jie,
thank you for your response. I have some follow-up questions:

· It appears to me that if a node skips the HBH EH that carries the VTN-ID, the node cannot apply policies required for the VTN. As a result, the SLA of the VTN might be violated. If conforming to the SLA is required, skipping the HBH EH seems as damaging as dropping a packet.
        Gyan> The primary use case for TEAS Network Slicing framework is for MBB 5G UE fixed wireless access N6 interface network slicing over RAN x-haul for slice services to CN 5G Edge compute Data Centers.  So this HBH processing would be within a closed or limited domain.  As  all nodes would be within the same administrative control with a common policy can be applied to ensure a standard processing of HBH in the fast path policy.  HBH processing has been widely successful in closed domains for a long time now.  The major gap that the Hinden HBH draft addresses as well as v6OPS draft below of which I am Co-Author are both related to the problem statement with HBH processing is over the internet.

· Also, it is not clear how an operator can verify that all nodes in an VTN domain are capable of processing the HBH EH in the fast path. Consider that the number of HBH EHs changes over time and thus the ability to process them in the fast path. Perhaps a node should periodically report on handling of HBH EH.
      Gyan> Similar answer ad above and the key here is limited domain for 5G slicing use case. So the number of EHs can be limited to this single EH option as a standard policy.  Also as is transport underlay layer closed domain the customer traffic is the one that is worrisome and that sits in the overlay payload so no impact to the transport underlay outer IPv6 header HBH processing of VTN ID.

Regards,
Greg

Best regards,
Jie
 <null>

Dear All,

Regards,
Greg

Bob & Ole
6man Chairs

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Chongfeng Xie <[email-masked]>
Date: Tue, 8 Feb 2022 18:40:04 +0800

Hi, Wim,
 
VPN+ and network slicing have been discussed in IETF for a long time (since 2017) , now operators want to deploy the technology in their networks for 5G and other applications. Thus it is necessary to determine the mechanism used to carry the identifier in the data packet. 
 
IMO HBH is the right place for realizing VPN+/network slices in IPv6 networks, and we appreciate technical discussion and considerations to help improve the IPv6-based approach. 

Thanks!
 
Best regards!

Chongfeng

> 2022年2月8日 下午12:50，Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]> 写道：
> 
> From: ipv6 <[email-masked] <mailto:[email-masked]>> on behalf of [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> 收件人：刘爱华10024999;[email-masked] <mailto:[email-masked]>;
> 抄送人：[email-masked] <mailto:[email-masked]>;[email-masked] <mailto:[email-masked]>;
> 日 期 ：2022年02月08日 10:07
> On 2/7/2022 8:55 PM, [email-masked] <mailto:[email-masked]> wrote:
> > [1] https://mailarchive.ietf.org/arch/browse/teas-ns-dt/ <https://mailarchive.ietf.org/arch/browse/teas-ns-dt/>  
> > <https://mailarchive.ietf.org/arch/browse/teas-ns-dt/ <https://mailarchive.ietf.org/arch/browse/teas-ns-dt/>> 
> >  
> > On Mon, Feb 7, 2022 at 5:10 PM <[email-masked] <mailto:[email-masked]>  
> > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >  
> >  
> >     Hi Greg & Gyan，
> >  
> >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> 
> >     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> >     <https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>> 
> >     On Thu, Feb 3, 2022 at 8:55 PM Greg Mirsky <[email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >  
> >         Hi Jie,
> >     https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-hbh-00 <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-hbh-00>
> >     <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-hbh-00 <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-hbh-00>> 
> >  
> >     https://datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh <https://datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh>
> >     <https://datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh <https://datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh>>,
> >         <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >  
> >             Hi Greg,
> >  
> >             <http://null <http://null/>> 
> >  
> >             *From:*ipv6 [mailto:[email-masked] <mailto:[email-masked]>
> >             <mailto:[email-masked] <mailto:[email-masked]>>] *On Behalf Of *Greg Mirsky
> >             *To:* Bob Hinden <[email-masked] <mailto:[email-masked]>
> >             <mailto:[email-masked] <mailto:[email-masked]>>> 
> >             *Cc:* IPv6 List <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> 
> >             <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >  
> >                 https://datatracker.ietf.org/doc/html/draft-dong-6man-enhanced-vpn-vtn-id-06 <https://datatracker.ietf.org/doc/html/draft-dong-6man-enhanced-vpn-vtn-id-06>
> >                 <https://datatracker.ietf.org/doc/html/draft-dong-6man-enhanced-vpn-vtn-id-06 <https://datatracker.ietf.org/doc/html/draft-dong-6man-enhanced-vpn-vtn-id-06>> 
> >  
> >                 [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> 
> >                 Administrative Requests:
> >                 https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> >                 <https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>> 
> >         [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> 
> >         Administrative Requests:
> >         https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> >         <https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>> 
> >     <http://www.verizon.com/ <http://www.verizon.com/>> 
> >  
> >     *Gyan Mishra*
> >  
> >     /Email [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>//
> >     /
> >  
> >     /M 301 502-1347
> >  
> >     /
> >  
> >  
> >  
> >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> 
> >     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> >     <https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>> 
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 8 Feb 2022 09:02:31 -0500

You seem to assume facts not in evidence.

It is not at all clear that we need a per-end-to-end network slice 
identification in the packet.
Fortunately, this document does not propose such a thing.

Without commenting on where the information goes, it does seem that 
having information in the packet to represent what resource set it needs 
to use (which is what I understand this document proposes in a 
particular way) is useful.

Yours,
Joel

On 2/8/2022 2:52 AM, Vasilenko Eduard wrote:
> 1.It is L2 but we are talking about slicing at L3.
> 
> 2.VLAN is not universally available, for example, wireless
> 
> Eduard
> 
> *From:*ipv6 [mailto:[email-masked]] *On Behalf Of 
> [email-masked]
> *Sent:* Tuesday, February 8, 2022 4:10 AM
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re:Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>
> 
> Hi Greg & Gyan，
> 
> 1.If we consider the sceneriars of 5G Slice, it is more normal to use 
> 2.As my understanding, IETF Slicing DT is still discussing the related 
> topics. It might be more reasonable to adopt this draft after IETF 
> Slicing DT's work have done.
> 
> 原始邮件
> 
> *发件人：*GyanMishra
> 
> *收件人：*Greg Mirsky;
> 
> *日 **期 * *：*2022年02月05日 14:33
> 
> *主 **题 **：Re: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>*
> 
>     ·It appears to me that if a node skips the HBH EH that carries the
>     VTN-ID, the node cannot apply policies required for the VTN. As a
>     result, the SLA of the VTN might be violated. If conforming to the
>     SLA is required, skipping the HBH EH seems as damaging as dropping a
>     packet.
> 
>          Gyan> The primary use case for TEAS Network Slicing framework 
> is for MBB 5G UE fixed wireless access N6 interface network slicing over 
> RAN x-haul for slice services to CN 5G Edge compute Data Centers.  So 
> this HBH processing would be within a closed or limited domain.  As  all 
> nodes would be within the same administrative control with a common 
> policy can be applied to ensure a standard processing of HBH in the fast 
> path policy.  HBH processing has been widely successful in closed 
> domains for a long time now.  The major gap that the Hinden HBH draft 
> addresses as well as v6OPS draft below of which I am Co-Author are both 
> related to the problem statement with HBH processing is over the internet.
> 
> use case today of HBH in limited domains RFC 6553 RPL Routing Protocol 
> for Low Powered Networks.
> 
> and https://datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh 
>     ·Also, it is not clear how an operator can verify that all nodes in
>     Consider that the number of HBH EHs changes over time and thus the
>     ability to process them in the fast path. Perhaps a node should
>     periodically report on handling of HBH EH.
> 
> for 5G slicing use case. So the number of EHs can be limited to this 
> single EH option as a standard policy.  Also as is transport underlay 
> layer closed domain the customer traffic is the one that is worrisome 
> and that sits in the overlay payload so no impact to the transport 
> underlay outer IPv6 header HBH processing of VTN ID.
> 
>     Regards,
> 
>     Greg
> 
>         Thanks for your comment. Your concern about the packet drop has
>         been considered in this document. The operational considerations
>         section says:
> 
>         “Operator needs to make sure that all the network nodes involved
>         in a VTN can either process Hop-by-Hop Options header in the
>         fast path, or ignore the Hop-by-Hop Option header. Since a VTN
>         is associated with a logical network topology, it is practical
>         to ensure that all the network nodes involved in that logical
>         topology support the processing of the HBH options header and
>         the VTN option. In other word, packets steered into a VTN MUST
>         As you mentioned draft-ietf-6man-hbh-processing is working to
>         make HBH EH practical and help its deployment in the network,
>         and the WG has agreed on this direction. Thus for the VTN
>         per-hop processing behavior, using HBH EH would be the most
>         suitable approach for IPv6 data plane.
> 
>         Best regards,
> 
>         Jie
> 
>         <null>
> 
>         If the VTN-ID is a piece of critical information that must be
>         processed by each transient node, then using HBH EH seems like a
>         wrong choice. Firstly, currently, packets with EH might get
>         dropped. Even draft-ietf-6man-hbh-processing makes the
>         processing of an HBH EH conditional on the traffic load and
>         processing capability of the node fast path.
> 
>             statements of support for adopting this document should be
>             sent to the mailing list.  Editorial suggestions can be sent
>             to the authors.  This adoption call will end on 10 February
>             2022.
> 
>             Further, if you are willing to work on this document, either
>             as contributor, author, or reviewer please notify the list. 
>               This will provide the chairs with an indication of the
>             energy level in the working group to work on this document.
> 
>             Bob & Ole
>             6man Chairs
> 
> /Network Solutions Architect /
> 
> /Email [email-masked] <mailto:[email-masked]>/
> 
> /M 301 502-1347/
> 
>

---

From: [email-masked]
Date: Tue, 8 Feb 2022 16:28:00 +0100

> Without commenting on where the information goes, it does seem that having information in the packet to represent what resource set it needs to use (which is what I understand this document proposes in a particular way) is useful.

If we want to make IPv6 an underlay protocol in limited domains like what MPLS is, then assign a number to an arbitrary tag.
But do the IETF and particularly 6man need to standardise how it's used?

- Is it a single value or is it a stack?
- Is it best encoded in the HBH header or a new protocol type?
- Could one of the plethora of existing tunnel protocols be used instead of defining a new?

O.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 8 Feb 2022 10:48:18 -0500

If we want that tag to be interoperable, we need to define what it means.

And preferably pick a place for it to appear.  Having an encoding in the 
SRH, one in the flow label, one in an extension header, and one in a 
carried protocol seems a recipe for disaster.

Yours,
Joel

---

From: [email-masked]
Date: Tue, 8 Feb 2022 17:14:22 +0100

> And preferably pick a place for it to appear.  Having an encoding in the SRH, one in the flow label, one in an extension header, and one in a carried protocol seems a recipe for disaster.

Many forms of "forwarding affecting mid-layer tags" exist already. So this is presumably just adding another...
I think it's fine to specify the format here, I'm also fine with that done in other working groups who has the use case.
I don't think the semantics of the tag should be done here.

O.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 8 Feb 2022 08:56:13 -0800

> - Is it best encoded in the HBH header or a new protocol type?
 Ole,

I support adoption. The primary purpose of HBH header is to allow
hosts to signal the network for services to be applied to packets. For
that POV, this use of HBH options seems appropriate (it's also similar
in intent to network tokens draft-yiakoumis-network-tokens and FAST
draft-herbert-fast). Also, the draft explicitly states that support of
HBH options is not required by every node in the path so if a node
doesn't support HBH options it can still forward the packet correctly
(this means there is no dependency between this draft and
draft-hinden-6man-hbh-processing).

> - Could one of the plethora of existing tunnel protocols be used instead of defining a new?

I don't believe this draft is defining a new tunnel protocol, just a
new HBH option.

Tom

---

From: Mark Smith <[email-masked]>
Date: Wed, 9 Feb 2022 04:39:07 +1100

Hi Ole,

On Wed, 9 Feb 2022, 02:28 , <[email-masked]> wrote:

> having information in the packet to represent what resource set it needs to
> use (which is what I understand this document proposes in a particular way)
> is useful.
>
> If we want to make IPv6 an underlay protocol in limited domains like what
> MPLS is, then assign a number to an arbitrary tag.
>

I think IPv6 is too bloated for limited domain/local network use. We'll
again see further attempts to hack it to debloat it as for example SPRING
have done with EH insertion.

For limited domains/local networks ideally we would have a different
general purpose protocol with smaller addresses e.g. 24 or 32 bit addresses.

MPLS is the closest existing thing we have to that, although I wouldn't say
it is as general purpose as would be ideal.

I think we're really missing a layer in our protocol models. We jump from a
link layer to an internetworking layer. There should be a local network
layer between.

MPLS being known as a "layer 2.5" protocol shows that there is a layer
missing.

Regards,
Mark.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 8 Feb 2022 10:38:09 -0800

On Tue, Feb 8, 2022 at 9:39 AM Mark Smith <[email-masked]> wrote:
> I think IPv6 is too bloated for limited domain/local network use. We'll again see further attempts to hack it to debloat it as for example SPRING have done with EH insertion.
>
> For limited domains/local networks ideally we would have a different general purpose protocol with smaller addresses e.g. 24 or 32 bit addresses.
>
> MPLS is the closest existing thing we have to that, although I wouldn't say it is as general purpose as would be ideal.
>
> I think we're really missing a layer in our protocol models. We jump from a link layer to an internetworking layer. There should be a local network layer between.
>
> MPLS being known as a "layer 2.5" protocol shows that there is a layer missing.

Hi Mark,

MPLS and other tunneling make perfect sense as an underlying mechanism
to implement network slices, but the problem is these are confined to
a specific local physical domain; for instance in the internal network
of a provider. While a smart phone attached to a 5G network could
conceptually participate in a provider's MPLS or internal tunneling,
it seems more likely and a lot simpler that connected devices just
have IP connectivity using addresses provided by the provider. In this
case, the device communicates just with IP, and the first hop router
in the provider network can map traffic into service classes or
network slices which could be supported by MPLS or encapsulation. The
service mapping function is critical here, it needs to determine what
services a user desires and is allowed based on the contents of the
packets. We know that TOS and DSCP aren't rich enough or reliable for
this, and performing DPI to determine service based on some port
mapping or other application information in the packets only works to
the extent that a service is able to parse through transport layers
and otherwise contributes to ossification of the Internet. What we
_really_ want is for end hosts to be able to express the services they
want from their network in a rich and secure format-- the most
generic, ubiquitous, and extensible mechanism for that does seem to be
HBH options.

Tom

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 8 Feb 2022 13:00:26 -0800

Hi Tom,
if the use case is, as you've described, mapping a subscriber traffic to
the most appropriate network slice based on the service requirements and
the subscription, then I don't see a benefit of using HbH EH by the
subscriber. As I understand it, the provider's gateway will map the user
traffic to a network slice for which all resources have been already
allocated. If that is the case, what is the use of  the VTN ID in the
subscriber packet carried over the provider network slice?

Regards,
Greg

On Tue, Feb 8, 2022 at 10:38 AM Tom Herbert <[email-masked]> wrote:

> >> If we want to make IPv6 an underlay protocol in limited domains like
> what MPLS is, then assign a number to an arbitrary tag.
> >
> >
> > MPLS is the closest existing thing we have to that, although I wouldn't
> say it is as general purpose as would be ideal.
> >
> > I think we're really missing a layer in our protocol models. We jump
> from a link layer to an internetworking layer. There should be a local
> network layer between.
> >

---

From: Tom Herbert <[email-masked]>
Date: Tue, 8 Feb 2022 13:48:26 -0800

On Tue, Feb 8, 2022 at 1:00 PM Greg Mirsky <[email-masked]> wrote:
>
> Hi Tom,
> if the use case is, as you've described, mapping a subscriber traffic to the most appropriate network slice based on the service requirements and the subscription, then I don't see a benefit of using HbH EH by the subscriber. As I understand it, the provider's gateway will map the user traffic to a network slice for which all resources have been already allocated. If that is the case, what is the use of  the VTN ID in the subscriber packet carried over the provider network slice?
>
Grep,

If all user traffic is mapped to the same slice then that works, but
in the case different flows from the user map to different slices then
some means is needed to differentiate classes within the user's
traffic. One way or another, it seems like the network has map packets
based on its contents which means either implicitly or explicitly the
source is creating input to the mapping function.  Also, given that
this is being brought to IETF, I'm assuming that the goal is a
solution that works across all different technologies of the Internet,
not just 3GPP or MPLS networks for instance.

Tom

---

From: Mark Smith <[email-masked]>
Date: Wed, 9 Feb 2022 08:51:49 +1100

> if the use case is, as you've described, mapping a subscriber traffic to the most appropriate network slice based on the service requirements and the subscription, then I don't see a benefit of usi…

I too am thinking of the IPv6 being used as an underlay.

I wrote this draft a while ago which has a number of ideas of how to
use IPv6 capabilities to enhance virtual network encapsulation. One
idea is to encode the virtual network identifier in the flow label
field (as long as you allocate VNI values in accordance with flow
label requirements, and protect it with a checksum carried in some
other header):

Enhancing Virtual Network Encapsulation with IPv6
https://datatracker.ietf.org/doc/html/draft-smith-enhance-vne-with-ipv6-07

Also an AusNOG presentation on it:
https://www.slideshare.net/markzzzsmith/nvtkaipv6-50785685

A lot of those ideas are about trying to minimise IPv6 header
overhead. I'm not entirely against using IPv6 for an underlay, however
I do wonder if it just isn't a good enough of a fit - a limited
domain/local network scope protocol doesn't to be able to address
anywhere near 2^128 devices, and if those 128 bit IPv6 addresses cause
people to try to jump through hoops to reduce overhead (EH insertion,
what I've suggested in that ID), IPv6 is probably the wrong tool for
the job.

Regards,
Mark.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 8 Feb 2022 17:11:42 -0500

Tom, I read the draft as describing a completely different space than 
you are addressing.

My colleagues have been working on ways of providing more notifications 
fro the user to the network about needs (something better than dyncast, 
which seems the wrong approach to this problem.)

Assuming the draft is still doing what it ws when I last looked, and 
talked to the authors, this document is about marking the packets inside 
the network (not over the communication between the user and the 
network) as to which resource sets the packet is supposed to use.  (I 
hope the authors will correct me if I have misunderstood.)

Defending the work for a different task than they want to address, with 
a different result, makes for a very confusing conversation.

Yours,
Joel

---

From: Tarek Saad <[email-masked]>
Date: Tue, 8 Feb 2022 22:32:47 +0000

Hi all,

I’ve read through the draft. I understand the motivation to carry an ID in an IPv6 Hop-by-Hop option to allow transit IPv6 routers to associate the packet with a set of resources and to enforce a specific forwarding treatment along the path.

Without precluding other possible options to carry the ID in the IPv6 header, I have the following comments on this draft. I appreciate if authors can comment or address them before adoption:

  *   I do not think the ID needs to be qualified to a “VTN”. It can simply be an ID or a tag that is used to select the set of network resources assigned to the packet
  *   Multiple such IDs or tags can potentially be used to select the same set of network resources. So again, I am not in favor of restricting single ID to a single set of resources.
  *   Some agreement was reached in TEAS WG to refer to the set of network resources as “Network Resource Partition (NRP)”. If qualifying the ID is indeed required, I’d like to see it as an NRP selector. Ideally, we do not need to define multiple IPv6 HbH options (carrying an ID and that serve a similar purpose) only give them different names.
  *   A note in the draft mentions that the size of ID selected in accordance to the 5G network slice ID (S-NSSAI). IMO, there is no such requirement to map/tie S-NSSAI to a tag or ID used to select the NRP resources, and hence I prefer such a statement be clarified and/or removed.

Regards,
Tarek

From: ipv6 <[email-masked]> on behalf of "庞冉(联通集团中国联通研究院-本部)" <[email-masked]>
Date: Sunday, February 6, 2022 at 8:55 AM
To: Bob Hinden <[email-masked]>, IPv6 List <[email-masked]>
Subject: Re: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

Hi all,

Best regards,
Pang Ran.

Bob & Ole
6man Chairs

---

From: Tom Herbert <[email-masked]>
Date: Tue, 8 Feb 2022 14:57:58 -0800

> a different result, makes for a very confusing conversation.

Joel,

Note that Hop-by-Hop can only be created by hosts, so saying that this
document is about marking packets inside the network is technically a
bit misleading :-). HBH options can only be created at ingress, but
can be updated infight. So when I look at the different use cases from
a network layer POV, say subscriber access to a network or ingress
into a tunnel, it seems like the same basic operation is happening--
hosts are sending signals into the network in packets that request
service for those packets. Given that it's a common problem, then why
not try for a common solution (wrt to IPv6 that common solution for a
mechanism is HBH options)?

Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 8 Feb 2022 18:16:16 -0500

The HBH (or other marking) can be created by an encapsulating node. 
WHich is the case that the draft describes.

Yours,
Joel

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 8 Feb 2022 19:16:33 -0500

Hi Aihua

Adrian and the TEAS DT combined the NS Slice Framework and NS slice
definition into a new combined draft called “Network Slices” which was
completed April of last year and adopted the current version 5 was last
updated in October of last year.

A lot of progress has been made by the DT on network slicing over the last
year.  I believe a lot of the high level concepts have been ironed out,
however there are still ongoing discussion topics related to the details of
provisioning network slicing.

https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/05/

Kind Regards

Gyan

On Mon, Feb 7, 2022 at 8:56 PM <[email-masked]> wrote:

> Yes, I refer to that one from TEAS. I think the DT is discussing the high
> level of IETF network slicing, so I suggest other detail drafts including
> this one to wait the DT's progress.
>
>
> 原始邮件
> *发件人：*ErikKline
> *收件人：*刘爱华10024999;
>>>    Also, it is not clear how an operator can verify that all nodes in

*Gyan Mishra*

*M 301 502-1347*

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 9 Feb 2022 04:05:30 +0000

Hi Bob, I read the draft and it’s straight forward.  It could probably be further simplified, however I don’t think it’s quite ready for 6man adoption given the comments in section 6 of https://www.ietf.org/archive/id/draft-ietf-6man-hbh-processing-00.txt about when new HBH options MUST NOT be defined.

I would be interested to hear about implementation experience from a few others, and whether this use of a HBH option meets those requirements.

Thanks
  Darren

On 2022-01-27, 12:51 AM, "ipv6" <[email-masked]> wrote:

Bob & Ole
6man Chairs

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 9 Feb 2022 05:13:12 +0000

Hi Tarek,

Thanks for your review and comments. Please see some replies inline:

From: ipv6 [mailto:[email-masked]] On Behalf Of Tarek Saad
Sent: Wednesday, February 9, 2022 6:33 AM
To: 庞冉(联通集团中国联通研究院-本部) <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

Hi all,

Without precluding other possible options to carry the ID in the IPv6 header, I have the following comments on this draft. I appreciate if authors can comment or address them before adoption:
-         I do not think the ID needs to be qualified to a “VTN”. It can simply be an ID or a tag that is used to select the set of network resources assigned to the packet

[Jie] In the context of this document, the VTN resource ID is used by all the nodes in the VTN to determine the set of network resource allocated for the packet processing, which means the set of network resources identified by this ID is always associated with a VTN. While this does not preclude the possibility that the semantics of this ID may be extended for other cases in future.

-         Multiple such IDs or tags can potentially be used to select the same set of network resources. So again, I am not in favor of restricting single ID to a single set of resources.

[Jie] In this document, there is no limitation on having multiple VTN resource IDs identify the same set of network resources. This is possible when a set of resources on specific links or nodes are shared among multiple VTNs.

-         Some agreement was reached in TEAS WG to refer to the set of network resources as “Network Resource Partition (NRP)”. If qualifying the ID is indeed required, I’d like to see it as an NRP selector. Ideally, we do not need to define multiple IPv6 HbH options (carrying an ID and that serve a similar purpose) only give them different names.

[Jie] As discussed earlier in this thread, the coordination and alignment on terminology (VTN, NRP, etc.) is needed and could be done based on the decision of the TEAS WG. It is better to spend the 6man expert’s valuable time on the functionality and protocol extensions.

-         A note in the draft mentions that the size of ID selected in accordance to the 5G network slice ID (S-NSSAI). IMO, there is no such requirement to map/tie S-NSSAI to a tag or ID used to select the NRP resources, and hence I prefer such a statement be clarified and/or removed.

[Jie] This is also pointed out by Adrian, we will revise the description about the 5G network slice ID and remove the figure about S-NSSAI.

Best regards,
Jie

Regards,
Tarek

From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of "庞冉(联通集团中国联通研究院-本部)" <[email-masked]<mailto:[email-masked]>>
Date: Sunday, February 6, 2022 at 8:55 AM
To: Bob Hinden <[email-masked]<mailto:[email-masked]>>, IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: Re: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

Hi all,

Best regards,
Pang Ran.

Bob & Ole
6man Chairs

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除<mailto:[email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除>。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked]<mailto:[email-masked]> ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 9 Feb 2022 06:40:07 +0000

[Without the AD hat]

I have read this short and easy-to-read IETF draft and I object the adoption based on its *current* content.

My objection is based on:
1/ the use case (5G slices) is too specific, many other use cases would benefit by a bespoken tag to be processed by intermediate nodes
2/ follow-up of 1/, let's have a variable length for this 'tag' 

I would even suggest to:
a/ allow for this generic variable-length tag option to be used by several use cases/applications by putting a structure in this HbH option, i.e., allowing several semantics to different tags (with possibly several such tag HbH options in the same IPv6 packet) [1]
b/ the original 5G slide use case could then select either to use this new HbH tag or any other technique

Regards

-éric

[1] this would be similar to the universal RA draft

On 27/01/2022, 06:51, "ipv6 on behalf of Bob Hinden" <[email-masked] on behalf of [email-masked]> wrote:

    Bob & Ole
    6man Chairs

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 9 Feb 2022 06:57:58 +0000

Hi Joel and Tom, 

Thanks a lot for the comments and discussion. 

The current document focuses on the mechanisms and procedures of network ingress nodes which encapsulate this new HBH option to data packets entering the IPv6 domain where VTNs are provisioned, and this field is used by the transit nodes to determine the set of network resources for packet processing. 

While as Tom mentioned, in some cases it may also be possible to use this information for the communication between the hosts and the network. Such use cases are not covered in this document and can be discussed further in the WG. 

Best regards,
Jie

> From: ipv6 [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Wednesday, February 9, 2022 7:16 AM
> To: Tom Herbert <[email-masked]>
> Cc: 6man WG <[email-masked]>
> >> My colleagues have been working on ways of providing more
> >> notifications fro the user to the network about needs (something
> >> better than dyncast, which seems the wrong approach to this problem.)
> >>
> >> talked to the authors, this document is about marking the packets
> >> inside the network (not over the communication between the user and
> >> the
> >> Defending the work for a different task than they want to address,
> >> with a different result, makes for a very confusing conversation.
> >>
> >
> > Joel,
> >
> the subscription, then I don't see a benefit of using HbH EH by the subscriber.
> As I understand it, the provider's gateway will map the user traffic to a
> network slice for which all resources have been already allocated. If that is
> the case, what is the use of  the VTN ID in the subscriber packet carried over
> the provider network slice?
> >>>>
> >>> Grep,
> >>>
> >>> in the case different flows from the user map to different slices
> >>> then some means is needed to differentiate classes within the user's
> >>> traffic. One way or another, it seems like the network has map
> >>> packets based on its contents which means either implicitly or
> >>> explicitly the source is creating input to the mapping function.
> >>> Also, given that this is being brought to IETF, I'm assuming that
> >>> the goal is a solution that works across all different technologies
> >>> of the Internet, not just 3GPP or MPLS networks for instance.
> >>>
> >>> Tom
> >>>
> >>>> Regards,
> >>>> Greg
> >>>>
> >>>>>>>> Without commenting on where the information goes, it does
> seem that having information in the packet to represent what resource set it
> needs to use (which is what I understand this document proposes in a
> >>>>>>> If we want to make IPv6 an underlay protocol in limited domains
> like what MPLS is, then assign a number to an arbitrary tag.
> >>>>>>
> >>>>>>
> >>>>>> I think IPv6 is too bloated for limited domain/local network use.
> We'll again see further attempts to hack it to debloat it as for example
> SPRING have done with EH insertion.
> >>>>>>
> >>>>>> For limited domains/local networks ideally we would have a
> different general purpose protocol with smaller addresses e.g. 24 or 32 bit
> addresses.
> >>>>>>
> >>>>>> MPLS is the closest existing thing we have to that, although I
> wouldn't say it is as general purpose as would be ideal.
> >>>>>>
> from a link layer to an internetworking layer. There should be a local network
> layer between.
> >>>>>>
> >>>>> MPLS and other tunneling make perfect sense as an underlying
> >>>>> mechanism to implement network slices, but the problem is these
> >>>>> are confined to a specific local physical domain; for instance in
> >>>>> the internal network of a provider. While a smart phone attached
> >>>>> to a 5G network could conceptually participate in a provider's
> >>>>> MPLS or internal tunneling, it seems more likely and a lot simpler
> >>>>> that connected devices just have IP connectivity using addresses
> >>>>> provided by the provider. In this case, the device communicates
> >>>>> just with IP, and the first hop router in the provider network can
> >>>>> map traffic into service classes or network slices which could be
> >>>>> supported by MPLS or encapsulation. The service mapping function
> >>>>> is critical here, it needs to determine what services a user
> >>>>> desires and is allowed based on the contents of the packets. We
> >>>>> know that TOS and DSCP aren't rich enough or reliable for this,
> >>>>> and performing DPI to determine service based on some port
> mapping
> >>>>> or other application information in the packets only works to the
> >>>>> extent that a service is able to parse through transport layers
> >>>>> _really_ want is for end hosts to be able to express the services
> >>>>> they want from their network in a rich and secure format-- the
> >>>>> most generic, ubiquitous, and extensible mechanism for that does
> seem to be HBH options.
> >>>>>
> >>>>> Tom
> >>>>>
> >>>>>>
> >>>>>> Regards,
> >>>>>> Mark.
> >>>>>>
> >>>>>>> ----------------------------------------------------------------
> >>>>>>> ---- IETF IPv6 working group mailing list [email-masked]
> >>>>>>> Administrative Requests:
> >>>>>> -----------------------------------------------------------------
> >>>>>> --- IETF IPv6 working group mailing list [email-masked]
> >>>>>> Administrative Requests:
> >>>>> ------------------------------------------------------------------
> >>>>> -- IETF IPv6 working group mailing list [email-masked]
> >>>>> Administrative Requests:
> >>> IETF IPv6 working group mailing list [email-masked] Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 9 Feb 2022 09:50:26 +0000

Hi Darren,

My reading of section 6 of draft-ietf-6man-hbh-processing-00 is:

New HBH options should be designed to be straight forward to process, and the size of the option should not beyond the capability of the processing node.

The format of the VTN option defined in this draft is straightforward and the length is reasonably short, thus IMO it meets the requirements of draft-ietf-6man-hbh-processing-00 very well.

BTW, I support the adoption.

Best regards,
Cheng

From: ipv6 [mailto:[email-masked]] On Behalf Of Darren Dukes (ddukes)
Sent: Wednesday, February 9, 2022 12:06 PM
To: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Re: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

Hi Bob, I read the draft and it's straight forward.  It could probably be further simplified, however I don't think it's quite ready for 6man adoption given the comments in section 6 of https://www.ietf.org/archive/id/draft-ietf-6man-hbh-processing-00.txt about when new HBH options MUST NOT be defined.

Thanks
  Darren

On 2022-01-27, 12:51 AM, "ipv6" <[email-masked]<mailto:[email-masked]>> wrote:

Bob & Ole
6man Chairs

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 9 Feb 2022 12:07:03 +0000

Hi Eric, 

Thanks a lot for your interest and comments. Please see some replies inline: 

> From: ipv6 [mailto:[email-masked]] On Behalf Of Eric Vyncke (evyncke)
> Sent: Wednesday, February 9, 2022 2:40 PM
> 1/ the use case (5G slices) is too specific, many other use cases would benefit
> by a bespoken tag to be processed by intermediate nodes 2/ follow-up of 1/,
> let's have a variable length for this 'tag'

5G slicing is just one use case of the VPN+/VTN mechanism, and this document provides a generic approach to encode a network wide identifier to determine the set of network resources allocated in the network for the processing of a group of traffic. It can be applied to various types of services. I think you agree that HBH is a suitable approach for it. 

I understand there could be other use cases of carrying "tag" in HBH, at current stage this document targeted on carrying the resource ID information, because we've seen requirements for it. Later as the requirements for other use cases become clear, it may be extended to also cover those use cases. And since the HBH option has a length field, it is possible to support different or variable length.

> 
> I would even suggest to:
> a/ allow for this generic variable-length tag option to be used by several use
> cases/applications by putting a structure in this HbH option, i.e., allowing
> several semantics to different tags (with possibly several such tag HbH
> options in the same IPv6 packet) [1] b/ the original 5G slide use case could
> then select either to use this new HbH tag or any other technique

I agree that structural format could make the HBH option more flexible and can be used for different use cases. While as described in draft-ietf-6man-hbh-processing-00, the HBH option should be straightforward to process, and the length should not exceed a certain limit. Thus there is some tradeoff between the flexibility and the processing efficiency. Maybe we could start with a basic format to meet the current requirement, while keep the extensibility to accommodate new requirements in the future. 

I also agree that for the 5G slice use case, either this HBH based mechanism or other mechanisms could be used to identify the set of resources for packet processing. 

Best regards,
Jie

> On 27/01/2022, 06:51, "ipv6 on behalf of Bob Hinden"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
>     as a working group document.  Substantive comments and statements
> of support for adopting this document should be sent to the mailing list.
> contributor, author, or reviewer please notify the list.   This will provide the
> chairs with an indication of the energy level in the working group to work on
> this document.
> 
>     Bob & Ole
>     6man Chairs
> 
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 9 Feb 2022 11:45:03 -0800

> Hi Bob, I read the draft and it’s straight forward.  It could probably be further simplified, however I don’t think it’s quite ready for 6man adoption given the comments in section 6 of https://www…

Darren,

Note that draft-ietf-6man-hbh-processing is itself an I-D and so the
requirements specified therein do not yet have consensus of the WG nor
IETF, and hence I don't believe it could procedurally block WG
adoption of this draft. That being said, which of the requirements in
section 6 of that draft do you think wouldn't or couldn't be met?

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 10 Feb 2022 14:24:55 +0800

support the adoption of this
 
Using IPv6 HBH to carry the VTN resource ID makes sense to me, and it can help to reduce the overhead in supporting a large number of VTNs for different 5G or vertical applications.
 
Best regards,

[email-masked]
 
From: Bob Hinden
Date: 2022-01-27 13:49
To: IPv6 List
CC: Bob Hinden

 

Bob & Ole
6man Chairs

---

From: Lizhenbin <[email-masked]>
Date: Thu, 10 Feb 2022 08:14:53 +0000

Hi All,

I support the adoption as the co-author. After years of discussion, there has been consensus that carrying the identifier of network resource in packet is useful for network slicing and other use cases, and HBH is the suitable approach for IPv6 data plane. In addition, after several rounds of refining, the draft is well written and ready for the adoption.

Best Regards,
Zhenbin (Robin)

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Thursday, January 27, 2022 1:49 PM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

Bob & Ole
6man Chairs

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 10 Feb 2022 11:57:09 +0000

Jie

Still wearing no hat.

Thank you for your reply. While I agree that such a HbH option could be useful, I sincerely believe that the I-D should broaden its scope beyong 5G and should be more flexible than a 32-bit ID.

If the I-D is revised with the above points, then I will be happy to support its adoption.

Regards

-éric

On 09/02/2022, 13:07, "Dongjie (Jimmy)" <jie.dong=[email-masked]> wrote:

    Hi Eric, 

    Best regards,
    Jie

---

From: Aijun Wang <[email-masked]>
Date: Thu, 10 Feb 2022 21:25:48 +0800

Hi,Eric:
I think the length of the ID and the application of this draft can also be extended after the adoption. Right?
I support its adoption and wish the authors can incorporate the comments in next version.

Aijun Wang
China Telecom

> 在 2022年2月10日，19:58，Eric Vyncke (evyncke) <evyncke=[email-masked]> 写道：
> 
> Jie
> 
> Still wearing no hat.
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 10 Feb 2022 14:50:09 +0000

Hi Eric, 

Thanks again for your further comment, and it is good to know that you agree this HBH option is useful, which means it is in the right direction. 

I confirmed that the scope of this document is broader than 5G and network slicing, and following the guidance from you and the WG, we would be happy to make it a more generic mechanism.

As for the length of the ID, it is easy to make it flexible based on the length field in the option, and with further input from the WG, we may figure out several practical length values. 

To summarize, I believe this document is a good starting point of defining a HBH option to be used for both 5G and other generic use cases, and it can be flexible to accommodate IDs with different size. 

Thus I'd agree with Aijun that we could adopt this document and continue polishing it towards the target solution. Hope this is also OK to you.

Many thanks,
Jie

> From: Eric Vyncke (evyncke) [mailto:evyncked =[email-masked]]
> Sent: Thursday, February 10, 2022 7:57 PM
> To: Dongjie (Jimmy) <[email-masked]>; Bob Hinden
> <[email-masked]>; IPv6 List <[email-masked]>
> Thank you for your reply. While I agree that such a HbH option could be useful,
> I sincerely believe that the I-D should broaden its scope beyong 5G and should
> be more flexible than a 32-bit ID.
> 
> On 09/02/2022, 13:07, "Dongjie (Jimmy)"
> <jie.dong=[email-masked]> wrote:
> 
>     Hi Eric,
> 
>     > I have read this short and easy-to-read IETF draft and I object the
> adoption
>     > based on its *current* content.
>     >
>     5G slicing is just one use case of the VPN+/VTN mechanism, and this
> document provides a generic approach to encode a network wide identifier to
> determine the set of network resources allocated in the network for the
> processing of a group of traffic. It can be applied to various types of services. I
> think you agree that HBH is a suitable approach for it.
> 
>     I understand there could be other use cases of carrying "tag" in HBH, at
> current stage this document targeted on carrying the resource ID information,
> because we've seen requirements for it. Later as the requirements for other
> use cases become clear, it may be extended to also cover those use cases. And
> since the HBH option has a length field, it is possible to support different or
> variable length.
> 
>     >
>     > I would even suggest to:
>     I agree that structural format could make the HBH option more flexible
> and can be used for different use cases. While as described in
> draft-ietf-6man-hbh-processing-00, the HBH option should be straightforward
> to process, and the length should not exceed a certain limit. Thus there is some
> tradeoff between the flexibility and the processing efficiency. Maybe we could
> start with a basic format to meet the current requirement, while keep the
> extensibility to accommodate new requirements in the future.
> 
>     I also agree that for the 5G slice use case, either this HBH based
> mechanism or other mechanisms could be used to identify the set of resources
> for packet processing.
> 
>     Best regards,
>     Jie
> 
>     >
>     > Regards
>     >
>     > -éric
>     >
>     >      Title:          Carrying Virtual Transport Network (VTN)
> Identifier in
>     > IPv6 Extension
>     >                      Header
> statements
> end

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 10 Feb 2022 18:06:43 +0000

Hi Cheng, the definition is straight forward. I can’t tell if the processing is straight forward and achievable at line rate.

The draft doesn’t mention any implementations experience from which I can get that understanding. Thus the ask to hear about implementation experience from a few others.

Darren

On 2022-02-09, 4:50 AM, "Chengli (Cheng Li)" <c.l=[email-masked]> wrote:

Hi Darren,

Best regards,
Cheng

Thanks
  Darren

Bob & Ole
6man Chairs

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 10 Feb 2022 18:19:43 +0000

Hi Tom.

I do appreciate that draft-ietf-6man-hbh-processing is still a draft without consensus (I wrote this sentence in my original email then deleted it :). I’m not suggesting there is a procedural block to draft-dong WG adoption.

However, there was a good deal of discussion and experience that went into the hbh draft text and that made me think, when I read draft-dong, how it could be applied.

The relevant text would be:
1 – “New options MUST NOT be defined that are not reasonably expected to be executed at full forwarding rates”
2 – “Straight forward to process.  That is, they should be designed to keep the time to process low.”
3 – “New Hop-by-Hop options should be designed to be the first option in a Hop-by-Hop options header.”

Hearing some ASIC implementation experience could answer #1 and #2 and could speak to what would happen if #3 was not met (eg when combined with other HBH headers).

Thanks
  Darren

On 2022-02-09, 2:45 PM, "Tom Herbert" <[email-masked]> wrote:

Darren,

Tom

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 10 Feb 2022 12:29:06 -0800

Hi Robin,
I think that we're looking at two issues here:

   - carrying an identifier to enable transit nodes to apply QoS policies
   according to SLOs
   - using the HbH EH to carry such identifier

It seems to me that there are no concerns with the former but there are
different opinions on the latter. In other words, I agree that the draft
solves the real problem but I don't think that it proposes the right
solution.

Regards,
Greg

On Thu, Feb 10, 2022 at 12:16 AM Lizhenbin <lizhenbin=
[email-masked]> wrote:

> Hi All,
>
> I support the adoption as the co-author. After years of discussion, there
> has been consensus that carrying the identifier of network resource in
> packet is useful for network slicing and other use cases, and HBH is the
> suitable approach for IPv6 data plane. In addition, after several rounds of
> refining, the draft is well written and ready for the adoption.
>
>
> Best Regards,
> Zhenbin (Robin)
>
>
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 11 Feb 2022 06:47:45 +0000

Hi Greg,

It is good to know that you agree with the semantic and functionality described in this document.

As for how to carry this identifier in IPv6 packet, the analysis about several other options (e.g. IPv6 address, flow label, etc.) has been done and the result was presented in a previous 6man session, there was also related discussion happened on the mailing list. Based on the analysis and the received feedbacks, we believe HBH is the reasonable approach for carrying the identifier in IPv6.

Best regards,
Jie

From: ipv6 [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Friday, February 11, 2022 4:29 AM
To: Lizhenbin <lizhenbin=[email-masked]>
Cc: IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

Hi Robin,

  *   carrying an identifier to enable transit nodes to apply QoS policies according to SLOs
  *   using the HbH EH to carry such identifier
It seems to me that there are no concerns with the former but there are different opinions on the latter. In other words, I agree that the draft solves the real problem but I don't think that it proposes the right solution.

Regards,
Greg

On Thu, Feb 10, 2022 at 12:16 AM Lizhenbin <lizhenbin=[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

Best Regards,
Zhenbin (Robin)

-----Original Message-----
From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bob Hinden
Sent: Thursday, January 27, 2022 1:49 PM
To: IPv6 List <[email-masked]<mailto:[email-masked]>>
Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>
Subject: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

Bob & Ole
6man Chairs

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 11 Feb 2022 07:57:41 +0000

Hi Darren,

My understanding is implementation status may be helpful as supplementary information, while I don't think it could be the major factor in considering the WG adoption of a document.

The format of this option is very simple, the opinion from the hardware colleagues is that it will not add much complexity to the processing of the HBH EH. And as the capability of hardware keeps increasing, this should not be a big concern.

Best regards,
Cheng

From: Darren Dukes (ddukes) [mailto:ddukes=[email-masked]]
Sent: Friday, February 11, 2022 2:07 AM
To: Chengli (Cheng Li) <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Re: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>

Hi Cheng, the definition is straight forward. I can't tell if the processing is straight forward and achievable at line rate.

The draft doesn't mention any implementations experience from which I can get that understanding. Thus the ask to hear about implementation experience from a few others.

Darren

On 2022-02-09, 4:50 AM, "Chengli (Cheng Li)" <c.l=[email-masked]<mailto:c.l=[email-masked]>> wrote:

Hi Darren,

Best regards,
Cheng

To: Bob Hinden <[email-masked]<mailto:[email-masked]>>; IPv6 List <[email-masked]<mailto:[email-masked]>>

Thanks
  Darren

Bob & Ole
6man Chairs

---

From: "Stefano Previdi (IETF)" <[email-masked]>
Date: Sat, 12 Feb 2022 13:44:12 +0100

<re-sending>

Hi,

I support the adoption of this document as WG item of the 6man WG so that the draft can be further improved by the WG considering some of the useful comments that have been made during the adoption call.

Thanks.
s.

> On Jan 27, 2022, at 6:49 AM, Bob Hinden <[email-masked]> wrote:
>