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

["Joel M. Halpern" <[e-mail]>]

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:
> 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:[e-mail]] *On Behalf Of 
> *[e-mail]
> *Sent:* Tuesday, February 8, 2022 4:10 AM
> *To:* [e-mail]; [e-mail]
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re:Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>
> 
> 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>*
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail] <mailto:[e-mail]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> <https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------
> 
> 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 <[e-mail] 
> <mailto:[e-mail]>> 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.
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-hbh-00 
> <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 
> <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
> 
>     On Thu, Feb 3, 2022 at 5:38 PM Dongjie (Jimmy) <[e-mail]
>     <mailto:[e-mail]>> 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
> 
>         <null>
> 
>         *From:*ipv6 [mailto:[e-mail]
>         <mailto:[e-mail]>] *On Behalf Of *Greg Mirsky
>         *Sent:* Wednesday, February 2, 2022 10:44 AM
>         *To:* Bob Hinden <[e-mail]
>         <mailto:[e-mail]>>
>         *Cc:* IPv6 List <[e-mail] <mailto:[e-mail]>>
>         *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 <[e-mail]
>         <mailto:[e-mail]>> wrote:
> 
>             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://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>
> 
>             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
>             [e-mail] <mailto:[e-mail]>
>             Administrative Requests:
>             https://www.ietf.org/mailman/listinfo/ipv6
>             <https://www.ietf.org/mailman/listinfo/ipv6>
>             --------------------------------------------------------------------
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>
>     --------------------------------------------------------------------
> 
> -- 
> 
> <http://www.verizon.com/>
> 
> *Gyan Mishra*
> 
> /Network Solutions Architect /
> 
> /Email [e-mail] <mailto:[e-mail]>/
> 
> /M 301 502-1347/
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------