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

[[e-mail]]

Hi Jie, all,

Thanks for taking care of many of the comments. 

On the option format itself, I still think we lack justification to encode in the extension the behavior to follow when no matching entry is found. A simple approach would be to get rid of the "S" bit and leave this as a configuration knob. I would swap the Context and flag fields to have the flags near the reserved bits.

Although the discussion in Section 5, it is somehow still vague what is eligible to be conveyed in this option. For example, I understand that some sort of slice id is not excluded but is that only when a slice involves a VTN? 

==
   Note that, in the context of 5G network slicing, if a deployment
   found it useful, the four-octet VTN ID field may be derived from the
   four-octet Single Network Slice Selection Assistance Information
   (S-NSSAI) defined in 3GPP [TS23501].
==

On a side note, as you mentioned "buffering" and "queuing" in few places, I wonder whether you are aware of implementations that are able to identify subset of these based on a network-wide ID.

Thank you.

Cheers,
Med

(*) Right after I reviewed draft-ietf-6man-enhanced-vpn-vtn-id, I edited draft-boucadair-teas-ietf-slicing-overview which elaborates further some of the points that I think are worth to be discussed before freezing message formats. These are summarized in the introduction of that draft, especially:

===
   Also, there is a lack of cross-WG communications in some cases when a
   slicing-related specification is candidate for adoption or adopted by
   a WG.  This lack of global view at the IETF level and lack of early
   cross-WG communications may induce some inconsistency.  For example,
   some proposals argue in favor of specifying extensions to convey
   specific identifiers in packets.  However, distinct identifiers are
   being proposed: slice identifier, NRP Selector, NRP identifier, VTN
   identifier, VTN resource identifier, etc.  The need and relationship
   between these identifiers are worth to be discussed independent of
   the channels that are used to convey these identifiers.

   This document provides an overview of slicing activities in the IETF
   to hopefully ease coordination and ensure that specifications that
   are developed in many WGs are consistent, e.g.:

   *  Position the various concepts: network slice, network resource
      partition, virtual transport network, etc.

   *  Clarify the need of the various identifiers introduced so far and
      soften redundant/duplicate uses.

   *  Harmonize the definition of relevant identifiers (length,
      encoding, usage, etc.) rather than having the specification of the
      same identifier repeated in many places.  For example, current
      specifications use distinct encoding length of the same attribute
      (variable, 16-bit, 32-bit).

   *  Clarify the relationship and co-existence of identifiers if more
      than one is needed.
===

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 <[e-mail]> De la part de Dongjie (Jimmy)
> Envoyé : samedi 8 juillet 2023 05:12
> À : [e-mail]
> Cc : 6man Chairs <[e-mail]>
> Objet : Re: [IPv6] I-D Action: draft-ietf-6man-enhanced-vpn-vtn-
> id-05.txt
> 
> 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 <[e-mail]> On Behalf Of
> > [e-mail]
> > Sent: Friday, July 7, 2023 10:53 AM
> > To: [e-mail]
> > Cc: [e-mail]
> > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> data
> > tracker.ietf.org%2Fdoc%2Fdraft-ietf-6man-enhanced-vpn-vtn-
> id%2F&data=0
> >
> 5%7C01%7Cmohamed.boucadair%40orange.com%7C09e07e4c86434916051e08db
> 7f61
> >
> 2f28%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6382438275969156
> 25%7
> >
> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1
> >
> haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aVySJMO%2FWEWRFoZRnE%2BZ
> CPwG
> > pJ25buHnkgiVNt8I75U%3D&reserved=0
> >
> > There is also an htmlized version available at:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> data
> > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-6man-enhanced-vpn-
> vtn-id-05
> >
> &data=05%7C01%7Cmohamed.boucadair%40orange.com%7C09e07e4c864349160
> 51e0
> >
> 8db7f612f28%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638243827
> 5969
> >
> 15625%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJB
> >
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=e%2F0%2BaC2F0rob5
> rKIn
> > M9qGejRzpPI%2FbAZqo402loQAbU%3D&reserved=0
> >
> > A diff from the previous version is available at:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> auth
> > or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-6man-enhanced-
> vpn-vtn-i
> > d-
> 0&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C09e07e4c86434916
> 05
> >
> 1e08db7f612f28%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638243
> 8275
> >
> 97071858%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiL
> >
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qbMYnFLU%2BQVo
> tNxF
> > %2F5DbyXJa%2FqBUmJnspZbNQ1M16%2BM%3D&reserved=0
> > 5
> >
> > Internet-Drafts are also available by rsync at
> > rsync.ietf.org::internet-drafts
> >
> >
> > ----------------------------------------------------------------
> ----
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=05%7C01%7Cmohamed.boucad
> air%
> >
> 40orange.com%7C09e07e4c86434916051e08db7f612f28%7C90c7a20af34b40bf
> bc48
> >
> b9253b6f5d20%7C0%7C0%7C638243827597071858%7CUnknown%7CTWFpbGZsb3d8
> eyJW
> >
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> 000%
> >
> 7C%7C%7C&sdata=6LZ8YF3S7dH1YOcL%2Bg2e2g2J1EGbC30JsSZKwrYrPes%3D&re
> serv
> > ed=0
> > ----------------------------------------------------------------
> ----
> 
> ------------------------------------------------------------------
> --
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=05%7C01%7Cmohamed.bo
> ucadair%40orange.com%7C09e07e4c86434916051e08db7f612f28%7C90c7a20a
> f34b40bfbc48b9253b6f5d20%7C0%7C0%7C638243827597071858%7CUnknown%7C
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6LZ8YF3S7dH1YOcL%2Bg2e2g2J1EGbC
> 30JsSZKwrYrPes%3D&reserved=0
> ------------------------------------------------------------------
> --
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.