Subject: FW: New Version Notification for draft-dong-6man-enhanced-vpn-vtn-id-05.txt

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 9 Sep 2021 03:21:52 +0000

Dear WG, 

We just submitted a new version of draft-dong-6man-enhanced-vpn-vtn-id to solve the comments received during the recent mail list discussion. 

The major change is "VTN resource ID" is used to replace the "VTN ID" in previous versions. This helps to clarify the functionality of this new data plane identifier, and also aligns with the description and discussion in TEAS WG. 

There are also editorial changes to improve the readability. 

It is encouraged to take a quick review of the diffs with the previous version, and comments are always welcome. 

Diff: https://www.ietf.org/rfcdiff?url2=draft-dong-6man-enhanced-vpn-vtn-id-05

Many thanks,
Jie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, September 9, 2021 11:08 AM
To: Chenhao Ma <[email-masked]>; Chongfeng Xie <[email-masked]>; Gyan Mishra <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Lizhenbin <[email-masked]>
Subject: New Version Notification for draft-dong-6man-enhanced-vpn-vtn-id-05.txt

A new version of I-D, draft-dong-6man-enhanced-vpn-vtn-id-05.txt
has been successfully submitted by Jie Dong and posted to the IETF repository.

Name:		draft-dong-6man-enhanced-vpn-vtn-id
Revision:	05
Title:		Carrying Virtual Transport Network Identifier in IPv6 Extension Header
Document date:	2021-09-09
Group:		Individual Submission
Pages:		8
URL:            https://www.ietf.org/archive/id/draft-dong-6man-enhanced-vpn-vtn-id-05.txt
Status:         https://datatracker.ietf.org/doc/draft-dong-6man-enhanced-vpn-vtn-id/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dong-6man-enhanced-vpn-vtn-id
Diff:           https://www.ietf.org/rfcdiff?url2=draft-dong-6man-enhanced-vpn-vtn-id-05

Abstract:
   A Virtual Transport Network (VTN) is a virtual network which has a
   customized network topology and a set of dedicated or shared network
   resources allocated from the physical network.  A VTN can be used as
   the underlay for one or a group of overlay VPNs to provide enhanced
   VPN (VPN+) services.  In packet forwarding, some fields in the data
   packet needs to be used to identify the VTN the packet belongs to, so
   that the VTN-specific processing can be performed on each node the
   packet traverses.

   This document proposes a new Hop-by-Hop option of IPv6 extension
   header to carry the VTN Resource ID, which is used to identify the
   set of network resources allocated to a VTN for packet processing.
   The procedure for processing the VTN option is also specified.

The IETF Secretariat

---

From: 庞冉(联通集团中国联通研究院-本部) <[email-masked]>
Date: Sat, 11 Sep 2021 12:59:33 +0000

Hi authors,

Thanks for resolving my comments in this update, The term “VTN resource ID” and the related descriptions are much clearer.

Best regards,
Pang Ran

From: Dongjie (Jimmy)<mailto:[email-masked]>
Date: 2021-09-09 11:21
To: 6MAN<mailto:[email-masked]>
CC: 6man Chairs<mailto:[email-masked]>
Subject: FW: New Version Notification for draft-dong-6man-enhanced-vpn-vtn-id-05.txt
Dear WG,

Many thanks,
Jie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, September 9, 2021 11:08 AM
To: Chenhao Ma <[email-masked]>; Chongfeng Xie <[email-masked]>; Gyan Mishra <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Lizhenbin <[email-masked]>
Subject: New Version Notification for draft-dong-6man-enhanced-vpn-vtn-id-05.txt

Abstract:

The IETF Secretariat

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 18 Sep 2021 14:24:25 +0800

Hi all,

This revision makes the purpose and the function defined in this document much clearer, personally I think it is ready to move forward.

Best regards,
Cong Li

From: Dongjie (Jimmy)
Date: 2021-09-09 11:21
To: 6MAN
CC: 6man Chairs

 

 
Many thanks,
Jie
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, September 9, 2021 11:08 AM
To: Chenhao Ma <[email-masked]>; Chongfeng Xie <[email-masked]>; Gyan Mishra <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; Lizhenbin <[email-masked]>
Subject: New Version Notification for draft-dong-6man-enhanced-vpn-vtn-id-05.txt

 
Abstract:

 
 
The IETF Secretariat

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 18 Sep 2021 12:28:13 -0400

The change in terminology with this revision adddresses most of my 
concerns with this draft.
Coupled with the text in the forwarding considerations section which 
makes clear that this information is purely about local resource 
handling, I think it is a good starting point for the work.

I expect that we will want to add text over time cclarifying how this 
work relates to things like flex-algo, and also to needed routing 
advertisements (which would be defined separately.)  I believe those 
will help make it clear why a hop-by-hop option is likely workable for 
this task, in spite of the usual concerns with such.

Yours,
Joel

>     *From:* Dongjie (Jimmy) <mailto:[email-masked]>
>     *Date:* 2021-09-09 11:21
>     *To:* 6MAN <mailto:[email-masked]>
>     *CC:* 6man Chairs <mailto:[email-masked]>
>     *Subject:* FW: New Version Notification for
>     draft-dong-6man-enhanced-vpn-vtn-id-05.txt

>     Dear WG,
>     We just submitted a new version of
>     draft-dong-6man-enhanced-vpn-vtn-id to solve the comments received
>     during the recent mail list discussion.
>     The major change is "VTN resource ID" is used to replace the "VTN
>     ID" in previous versions. This helps to clarify the functionality of
>     this new data plane identifier, and also aligns with the description
>     and discussion in TEAS WG.
>     It is encouraged to take a quick review of the diffs with the
>     previous version, and comments are always welcome.
>     Diff:
>     https://www.ietf.org/rfcdiff?url2=draft-dong-6man-enhanced-vpn-vtn-id-05
>     Many thanks,
>     Jie

>     To: Chenhao Ma <[email-masked]>; Chongfeng Xie
>     <[email-masked]>; Gyan Mishra <[email-masked]>;
>     Dongjie (Jimmy) <[email-masked]>; Lizhenbin <[email-masked]>
>     Subject: New Version Notification for
>     draft-dong-6man-enhanced-vpn-vtn-id-05.txt
>     URL:           
>     https://www.ietf.org/archive/id/draft-dong-6man-enhanced-vpn-vtn-id-05.txt
>     Status:        
>     https://datatracker.ietf.org/doc/draft-dong-6man-enhanced-vpn-vtn-id/
>     Htmlized:      
>     https://datatracker.ietf.org/doc/html/draft-dong-6man-enhanced-vpn-vtn-id
>     Diff:          
>     https://www.ietf.org/rfcdiff?url2=draft-dong-6man-enhanced-vpn-vtn-id-05
>     Abstract:

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 20 Sep 2021 01:33:27 +0000

Hi Joel,

Thanks for your feedback, and glad to know this update solves most of your concerns.

I agree that some text about the related control plane mechanisms to constrain the topology and compute the path where the HBH option is applicable could be added, and the details of the control plane would be specified in a separate document.

Best regards,
Jie

> From: ipv6 [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Sunday, September 19, 2021 12:28 AM
> To: 6MAN <[email-masked]>
> Subject: Re: FW: New Version Notification for
> The change in terminology with this revision adddresses most of my concerns
> with this draft.
> Coupled with the text in the forwarding considerations section which makes
> clear that this information is purely about local resource handling, I think it is a
> good starting point for the work.
> 
> I expect that we will want to add text over time cclarifying how this work
> relates to things like flex-algo, and also to needed routing advertisements
> (which would be defined separately.)  I believe those will help make it clear
> why a hop-by-hop option is likely workable for this task, in spite of the usual
> concerns with such.
> 
> Yours,
> Joel
>

---

From: tom petch <[email-masked]>
Date: Fri, 24 Sep 2021 15:59:46 +0000

From: ipv6 <[email-masked]> on behalf of Dongjie (Jimmy) <[email-masked]>
Sent: 20 September 2021 02:33

Hi Joel,

<tp>
I had a look and do not understand what a VTN is; I think that that needs more  explanation in the body of the I-D. I am well acquainted with your Normative References!  Searching the 100 or so I-D I take an interest, VPN occurs in many of them, VTN in only one and that as part of the title of an I-D Reference.  vn-id is slightly more common, as in TEAS, but it is VPN that dominates.

Either way, the identifiers are mostly modelled as a string of unspecified character set and unspecified length whereas you have a four octet identifier .

Tom Petch

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 27 Sep 2021 03:50:44 +0000

Hi Tom, 

Thanks for your review and comments. 

The VTN concept was introduced and described in draft-ietf-teas-enhanced-vpn, which is listed as one of the Informative References of this document. Perhaps it could be listed as Normative References in next revision?

The abstract and introduction section of this document give a brief description of VTN: it is a virtual transport network with a customized network topology and a set of dedicated or shared network resources allocated from the physical network. 

VPN as you mentioned is usually considered as the overlay virtual network, and a VTN can be used as a virtual underlay for carrying the overlay VPN services.

As to the format of the VTN resource ID, since it is carried in the HBH options header of the IPv6 packet, it is designed as a 4-octet ID. The string format maybe more suitable for the modeling for management purpose. 

Hope this helps. 

Best regards,
Jie

> From: tom petch [mailto:[email-masked]]
> Sent: Saturday, September 25, 2021 12:00 AM
> To: Dongjie (Jimmy) <[email-masked]>; Joel M. Halpern
> <[email-masked]>; 6MAN <[email-masked]>
> I had a look and do not understand what a VTN is; I think that that needs
> more  explanation in the body of the I-D. I am well acquainted with your
> Normative References!  Searching the 100 or so I-D I take an interest, VPN
> occurs in many of them, VTN in only one and that as part of the title of an I-D
> Reference.  vn-id is slightly more common, as in TEAS, but it is VPN that
> dominates.
> 
> Either way, the identifiers are mostly modelled as a string of unspecified
> character set and unspecified length whereas you have a four octet
> identifier .
> 
> Tom Petch
> 
> I agree that some text about the related control plane mechanisms to
> constrain the topology and compute the path where the HBH option is
> applicable could be added, and the details of the control plane would be
> specified in a separate document.
> 
> Best regards,
> Jie
> 
> > >         VPN (VPN+) services.  In packet forwarding, some fields in
> > > the
> > data
> > >         that the VTN-specific processing can be performed on each
> > > node
> > the
> > >         packet traverses.

---

From: Erik Kline <[email-masked]>
Date: Sun, 26 Sep 2021 21:29:28 -0700

>
> As to the format of the VTN resource ID, since it is carried in the HBH
> options header of the IPv6 packet, it is designed as a 4-octet ID. The
> string format maybe more suitable for the modeling for management purpose.
>

<no hats>

I see that section 2 describes the 4-octet length choice to match the
3GPP S-NSSAI, which brought to mind a question: is this known to be large
enough in practice?

I have no reason to choose any different size, but since this is the first
time I've read any rationale on the size of the "slice id" numberspace (I
haven't been paying close attention) I became curious to know how it has
been working out operationally.

Thanks,
-Erik

Other random thoughts from a quick scan:

* section 3.1 probably doesn't need 2119/8174 style keywords, because if
any operator is going to do the encap and use this option they'll just do
it.  =)
* there probably needs to be some text about this option /not/ be applied
by general purpose hosts, otherwise this could revive the extensive APN
debates

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 27 Sep 2021 07:57:03 +0000

Hi Erik,

Thanks for your comments, please see some replies inline with [Jie]:

From: Erik Kline [mailto:[email-masked]]
Sent: Monday, September 27, 2021 12:29 PM
To: Dongjie (Jimmy) <[email-masked]>
Cc: tom petch <[email-masked]>; Joel M. Halpern <[email-masked]>; 6MAN <[email-masked]>
Subject: Re: FW: New Version Notification for draft-dong-6man-enhanced-vpn-vtn-id-05.txt

<no hats>

I see that section 2 describes the 4-octet length choice to match the 3GPP S-NSSAI, which brought to mind a question: is this known to be large enough in practice?

[Jie] Good question. The length of the 3GPP S-NSSAI is 4-octet. Thus we propose to also use a 4-octet ID to allow the possible matching and mapping between 3GPP network slices and the VTNs

I have no reason to choose any different size, but since this is the first time I've read any rationale on the size of the "slice id" numberspace (I haven't been paying close attention) I became curious to know how it has been working out operationally.

[Jie] Understood.

Best regards,
Jie

Thanks,
-Erik

* section 3.1 probably doesn't need 2119/8174 style keywords, because if any operator is going to do the encap and use this option they'll just do it.  =)
* there probably needs to be some text about this option /not/ be applied by general purpose hosts, otherwise this could revive the extensive APN debates

---

From: tom petch <[email-masked]>
Date: Mon, 27 Sep 2021 16:03:21 +0000

From: Dongjie (Jimmy) <[email-masked]>
Sent: 27 September 2021 04:50

Hi Tom,

<tp>

Right and that is where I think that this I-D goes wrong whereas  enhanced-vpn gets it right  It is the Abstract here that is wrong when it dives into VTN, which is likely to be unfamiliar, without saying what it is and without showing the relationship to VPN, VPN+.  I think that you need what is in the Terminology section of enhance-vpn but as text, in the Introduction before going into the technical detail of what is added here.  And yes, enhanced-vpn needs to be a Normative Reference. 

Reading the current Abstract, my reaction was along the lines of 'Since you are talking about a VPN why are you using the wrong terminology:-)'  I think that the Abstract here needs to go from VPN to VPN+ to VTN to the need for a HBH option, a sentence on each with more plus Normative References in the Introduction.

As to its length, then that is the greater challenge since, as I said, a string of indeterminate length is the usual identifier

Tom Petch

Hope this helps.

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 29 Sep 2021 15:02:46 +0000

Hi Tom,

Thanks again for your comments and suggestions. Please see inline with [Jie]:

> Sent: Tuesday, September 28, 2021 12:03 AM
> The VTN concept was introduced and described in
> draft-ietf-teas-enhanced-vpn, which is listed as one of the Informative
> References of this document. Perhaps it could be listed as Normative
> References in next revision?
> 
> The abstract and introduction section of this document give a brief
> description of VTN: it is a virtual transport network with a customized
> network topology and a set of dedicated or shared network resources
> allocated from the physical network.
> 
> <tp>
> 
> Right and that is where I think that this I-D goes wrong whereas
> enhanced-vpn gets it right  It is the Abstract here that is wrong when it
> dives into VTN, which is likely to be unfamiliar, without saying what it is and
> without showing the relationship to VPN, VPN+.  I think that you need what
> is in the Terminology section of enhance-vpn but as text, in the Introduction
> before going into the technical detail of what is added here.  And yes,
> enhanced-vpn needs to be a Normative Reference.
>
> Reading the current Abstract, my reaction was along the lines of 'Since you
> are talking about a VPN why are you using the wrong terminology:-)'  I think
> that the Abstract here needs to go from VPN to VPN+ to VTN to the need for
> a HBH option, a sentence on each with more plus Normative References in
> the Introduction.

I got your point. We will add some text to describe the relationship between VTN and VPN+. We have the terminology section of enhanced VPN in draft-ietf-teas-enhanced-vpn, which will be made a normative reference in next version. 

> 
> As to its length, then that is the greater challenge since, as I said, a string of
> indeterminate length is the usual identifier

As I said in my previous reply, I understand that a string with indeterminate length could be the choice for the YANG model and management plane. The VTN resource ID in this draft is carried in the IPv6 packet header, and needs to be processed Hop-by-Hop in the forwarding plane, thus an identifier with fixed length would be hardware friendly. 

Best regards,
Jie

> 
> Tom Petch
> 
> VPN as you mentioned is usually considered as the overlay virtual network,
> and a VTN can be used as a virtual underlay for carrying the overlay VPN
> services.
> 
> As to the format of the VTN resource ID, since it is carried in the HBH options
> header of the IPv6 packet, it is designed as a 4-octet ID. The string format
> maybe more suitable for the modeling for management purpose.
> 
> Hope this helps.
> 
> Best regards,
> Jie
> 
> > I had a look and do not understand what a VTN is; I think that that
> > needs more  explanation in the body of the I-D. I am well acquainted
> > with your Normative References!  Searching the 100 or so I-D I take an
> > interest, VPN occurs in many of them, VTN in only one and that as part
> > of the title of an I-D Reference.  vn-id is slightly more common, as
> > in TEAS, but it is VPN that dominates.
> >
> > Either way, the identifiers are mostly modelled as a string of
> > unspecified character set and unspecified length whereas you have a
> > four octet identifier .
> >
> > Tom Petch
> >
> > applicable could be added, and the details of the control plane would
> > be specified in a separate document.
> >
> > Best regards,
> > Jie
> >
> > > I expect that we will want to add text over time cclarifying how
> > > this work relates to things like flex-algo, and also to needed
> > > routing advertisements (which would be defined separately.)  I
> > > believe those will help make it clear why a hop-by-hop option is
> > > likely workable for this task, in spite of the usual concerns with such.
> > >
> > > Yours,
> > > Joel
> > >
> > > https://www.ietf.org/rfcdiff?url2=draft-dong-6man-enhanced-vpn-vtn-i
> > > d-
> > > 05
> > > >     Many thanks,
> > > >     Jie
> > >
> > > >     has been successfully submitted by Jie Dong and posted to the
> IETF
> > > >     repository.
> > > https://www.ietf.org/archive/id/draft-dong-6man-enhanced-vpn-vtn-id-
> > > 05
> > > .txt
> > > >     Status:
> > > >
> > > https://datatracker.ietf.org/doc/html/draft-dong-6man-enhanced-vpn-v
> > > tn
> > > -id
> > > >     Diff:
> > > >
> > > https://www.ietf.org/rfcdiff?url2=draft-dong-6man-enhanced-vpn-vtn-i
> > > d-
> > > 05
> > > >     Abstract:
> > > >         A Virtual Transport Network (VTN) is a virtual network
> > > > which
> > has a
> > > >         customized network topology and a set of dedicated or
> > > > shared
> > > network
> > > >         resources allocated from the physical network.  A VTN can
> > > > be
> > > used as
> > > >         packet needs to be used to identify the VTN the packet
> belongs
> > > >     to, so
> > > >         header to carry the VTN Resource ID, which is used to
> > > > identify
> > the
> > > IETF IPv6 working group mailing list [email-masked] Administrative
> > > Requests: https://www.ietf.org/mailman/listinfo/ipv6