Re: [IPv6] I-D Action: draft-ietf-6man-enhanced-vpn-vtn-id-05.txt

Hi Justin, 

Thanks for your review and suggestion. 

In my understanding there is no common rule of making value 0 as reserved, it is a decision made by each specific registry. For example, in the "IPv6 Extension Header Types" registry, value 0 is allocated to Hop-by-Hop Option header. We could also see other cases in IANA where value 0 is allocated for a specific purpose. 

As for this registry, the allocation of value 0 could facilitate backward compatibility with some existing implementations. 

Taking the above aspects into consideration, the authors think it would be better to keep the code point allocation as in the current draft. 

Best regards,
Jie

> -----Original Message-----
> From: Justin Iurman <justin.iurman@uliege.be>
> Sent: Friday, July 14, 2023 11:11 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com>; ipv6@ietf.org
> Cc: 6man Chairs <6man-chairs@ietf.org>
> Subject: Re: [IPv6] I-D Action: draft-ietf-6man-enhanced-vpn-vtn-id-05.txt
> 
> Hi Jie,
> 
> I think it would make sense to keep value 0 as reserved (just like you did for value
> 255, since they are considered special values) in the "VTN Option Context Type"
> registry. So what I suggest is to move Resource ID to value 1.
> 
> OLD:
>        Value          Description       Reference
>        -----------------------------------------------
>          0            Resource ID      [this document]
>        1-254          Unassigned
>         255           Reserved         [this document]
> 
> NEW:
>        Value          Description       Reference
>        -----------------------------------------------
>          0            Reserved         [this document]
>          1            Resource ID      [this document]
>        2-254          Unassigned
>         255           Reserved         [this document]
> 
> Cheers,
> Justin
> 
> On 7/8/23 05:12, Dongjie (Jimmy) wrote:
> > Dear all,
> >
> > This update is mainly editorial to solve the review comments and suggestions
> received during the early allocation call on the IPv6 VTN Option. We also had
> constructive discussion with Med offline about the comments in detail.
> >
> > In this version, the description about the VTN Option, its semantics and the
> processing behavior are further clarified, while its format has been stable.
> >
> > The IANA section is also updated to align with the IPv6 "Destination Options
> and Hop-by-Hop Options" registry.
> >
> > With this update, the authors believe this document is ready for both the early
> allocation and the WG last call.
> >
> > Best regards,
> > Jie
> >
> >> -----Original Message-----
> >> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of
> >> internet-drafts@ietf.org
> >> Sent: Friday, July 7, 2023 10:53 AM
> >> To: i-d-announce@ietf.org
> >> Cc: ipv6@ietf.org
> >> Subject: [IPv6] I-D Action:
> >> draft-ietf-6man-enhanced-vpn-vtn-id-05.txt
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >> This Internet-Draft is a work item of the IPv6 Maintenance (6MAN) WG
> >> of the IETF.
> >>
> >>     Title           : Carrying Virtual Transport Network (VTN) Information
> in
> >> IPv6 Extension Header
> >>     Authors         : Jie Dong
> >>                       Zhenbin Li
> >>                       Chongfeng Xie
> >>                       Chenhao Ma
> >>                       Gyan Mishra
> >>     Filename        : draft-ietf-6man-enhanced-vpn-vtn-id-05.txt
> >>     Pages           : 12
> >>     Date            : 2023-07-06
> >>
> >> Abstract:
> >>     Virtual Private Networks (VPNs) provide different customers with
> >>     logically separated connectivity over a common network
> >>     infrastructure.  With the introduction and evolvement of 5G and also
> >>     in some existing network scenarios, some customers may require
> >>     network connectivity services with advanced features comparing to
> >>     conventional VPN services.  Such kind of network service is called
> >>     enhanced VPNs (VPN+).  VPN+ can be used, for example, to deliver IETF
> >>     network slice services.
> >>
> >>     A VTN is a virtual underlay network that is associated with a network
> >>     topology, and is allocated with a set of dedicated or shared
> >>     resources from the underlay physical network.  VPN+ services can be
> >>     delivered by mapping one or a group of overlay VPNs to the
> >>     appropriate VTNs as the virtual underlay.  For packet forwarding in a
> >>     specific VTN, some fields in the data packet are used to identify the
> >>     VTN the packet belongs to, so that VTN-specific processing can be
> >>     performed on each node along a VTN-specific path.
> >>
> >>     This document specifies a new IPv6 Hop-by-Hop option to carry the VTN
> >>     related information in data packets, which could be used to identify
> >>     the VTN-specific processing to be performed on the packets by each
> >>     network node along a VTN-specific path.
> >>
> >> The IETF datatracker status page for this Internet-Draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-6man-enhanced-vpn-vtn-id/
> >>
> >> There is also an htmlized version available at:
> >> https://datatracker.ietf.org/doc/html/draft-ietf-6man-enhanced-vpn-vt
> >> n-id-05
> >>
> >> A diff from the previous version is available at:
> >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-6man-enhanced-vp
> >> n-vtn-id-0
> >> 5
> >>
> >> Internet-Drafts are also available by rsync at
> >> rsync.ietf.org::internet-drafts
> >>
> >>
> >> --------------------------------------------------------------------
> >> 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
> > --------------------------------------------------------------------