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

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 <liu.aihua@zte.com.cn> 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/
>
> On Mon, Feb 7, 2022 at 5:10 PM <liu.aihua@zte.com.cn> 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
>> ipv6@ietf.org
>> Administrative Requests: 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 <gregimirsky@gmail.com> 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
>>
>> 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
>>>
>>> On Thu, Feb 3, 2022 at 5:38 PM Dongjie (Jimmy) <jie.dong@huawei.com>
>>> 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:ipv6-bounces@ietf.org <ipv6-bounces@ietf.org>] *On
>>>> Behalf Of *Greg Mirsky
>>>> *Sent:* Wednesday, February 2, 2022 10:44 AM
>>>> *To:* Bob Hinden <bob.hinden@gmail.com>
>>>> *Cc:* IPv6 List <ipv6@ietf.org>
>>>> *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 <bob.hinden@gmail.com>
>>>> 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
>>>>
>>>> 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
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>>
>>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>
>>
>>
>> *M 301 502-1347*
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*