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

[Tianran Zhou <[e-mail]>]

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


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

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 <[e-mail]<mailto:[e-mail]>> on behalf of [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 8 February 2022 at 03:28
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re:Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>



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


原始邮件
发件人：JoelM.Halpern
收件人：刘爱华10024999;[e-mail];
抄送人：[e-mail];[e-mail]<mailto:[e-mail];[e-mail]>;
日 期 ：2022年02月08日 10:07
主 题 ：Re: Adoption Call for <draft-dong-6man-enhanced-vpn-vtn-id>
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, [e-mail]<mailto:[e-mail]> 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
> *主 题 ：**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
>
> [1] 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 <[e-mail]
<mailto:[e-mail] %20%0b>> <mailto:[e-mail]>> 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>*
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail]<mailto:[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]%0b>>     <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]<mailto:[e-mail] %3cmailto:[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
>
>             <http://null>
>
>             *From:*ipv6 [mailto:[e-mail]
>             <mailto:[e-mail]><mailto:[e-mail]%0b%3e             %3cmailto:[e-mail]%3e>] *On Behalf Of *Greg Mirsky
>             *Sent:* Wednesday, February 2, 2022 10:44 AM
>             *To:* Bob Hinden <[e-mail]
<mailto:[e-mail]%0b>>             <mailto:[e-mail]>>
>             *Cc:* IPv6 List <[e-mail] <mailto:[e-mail]<mailto:[e-mail] %3cmailto:[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]<mailto:[e-mail] %3cmailto:[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]> <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]> <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 A//rchitect /
>
>     /Email [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>//
>     /
>
>     /M 301 502-1347
>
>     /
>
>
>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail]<mailto:[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
> --------------------------------------------------------------------