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

["Dongjie (Jimmy)" <[e-mail]>]

Hi Med, 

Thanks for your feedback, please see inline:

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Friday, September 8, 2023 12:09 AM
> To: Dongjie (Jimmy) <[e-mail]>; [e-mail]
> Cc: 6man Chairs <[e-mail]>
> Subject: RE: [IPv6] I-D Action: draft-ietf-6man-enhanced-vpn-vtn-id-05.txt
> 
> Hi Jie, all,
> 
> Thanks for taking care of many of the comments.

It is good to know we've resolved many of them. 

> 
> 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.

The reason to make it encoded in the option is that such behavior could be changed per-packet. Depends on some policy on the headend node, the behavior represented by the S bit could be set for a specific set of packet on the specified path/VTN , while for the rest of traffic on the same path/VTN, the S bit is unset. Making it a configuration knob would either lose such flexibility, or introduce complex configuration on every node along the path. 

In this design the flags fields are generic and can apply to VTN IDs with different Context Types. That's why the flags are preceding the Context field. 

> 
> 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].
> ==

The text here just provides an option that when VTN is used for the transport part of 5G network slicing, there could be mapping relationship between the 5G Slice ID (S-NSSAI) and the VTN ID of this option. Then according to the S-NSSAI of a 5G network slice, the VTN ID could be derived, and the packet could be encapsulated with an outer IPv6 header with the corresponding VTN ID value in the VTN option. 


> 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.

Yes, there are implementations of using network-wide IDs to identify the buffer and queue resources on local interfaces. 

Hope this helps to solve your remaining questions. 

Best regards,
Jie

> 
> 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%7C09e07e4c86434916051e
> 08db
> > 7f61
> > >
> >
> 2f28%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638243827596
> 9156
> > 25%7
> > >
> >
> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> I
> > 6Ik1
> > >
> >
> haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aVySJMO%2FWEWRFo
> ZRnE%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%7C09e07e4c86434
> 9160
> > 51e0
> > >
> >
> 8db7f612f28%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63824
> 3827
> > 5969
> > >
> >
> 15625%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIi
> > LCJB
> > >
> >
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=e%2F0%2BaC2F
> 0rob5
> > 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%7C09e07e4c8643
> 4916
> > 05
> > >
> >
> 1e08db7f612f28%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63
> 8243
> > 8275
> > >
> >
> 97071858%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luM
> > 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%7C90c7a20af34b4
> 0bf
> > bc48
> > >
> >
> b9253b6f5d20%7C0%7C0%7C638243827597071858%7CUnknown%7CTWFpb
> GZsb3d8
> > 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%7C90c7a2
> 0a
> >
> f34b40bfbc48b9253b6f5d20%7C0%7C0%7C638243827597071858%7CUnkno
> wn%7C
> >
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> >
> JXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6LZ8YF3S7dH1YOcL%2Bg2e2g2J
> 1EGbC
> > 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.
>