Re: Next steps with draft-dong-6man-enhanced-vpn-vtn-id

I support WG adoption of this draft as it is a critical component of 5G
network slice provisioning of VPN+  Enhanced VPN coupling of VPN overlay
resources to underlay Virtual Transport Network(VTN) resource reservation
underpinning.

As VPN+ sits in the overlay, it’s the VPN+ Overlay underpinnings to the now
virtualization of the transport underlay mapping and resources provisioning
of the E2E underlay hop by hop resources, is what the VTN ID provides,
which is a critical component of the overall Enhanced VPN framework
architecture of network slice (NS) provisioning process by the NS
controller which utilizes the S-NSSAI slice differentiator now encoded into
the HBH VTN ID per this draft.

https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/

https://datatracker.ietf.org/doc/draft-drake-bess-enhanced-vpn/

Kind Regards

Gyan

On Tue, Aug 10, 2021 at 1:06 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:

> I have to disagree.  Slicing is not particularly fundamental.
> Resource allocation (including queueing) and packet forwarding are low
> level constructs.
> Slicing is a way of talking about using those and other tools to deliver
> an externally understandable set of behaviors.
> An easily accessible identifier in the packet is useful for actual low
> level operations.   But we have those.  I have not yet seen any
> explanation of why we need an explicit identifier associated with the
> end-to-end slice in an easily accessible portion of the packet.
>
> Many iterations of trying to do fine grained control in the middle of
> the network teach us that what we need in the middle is aggregated /
> aggregatable state that can be used to deliver the needed behaviors.
> MPLS labels, DSCP code points, and similar tools give us that.
>
> Yours,
> Joel
>
> On 8/10/2021 12:38 PM, Vasilenko Eduard wrote:
> > Hi all,
> >
> > Slicing is something fundamental/low_level. Slice ID should not be
> > buried deep into the label or SID stack like VPN is.
> >
> > HbH is the proper place for it. Hence, support for this draft.
> >
> > Eduard
> >
> > *From:*ipv6 [mailto:ipv6-bounces@ietf.org] *On Behalf Of *Chongfeng Xie
> > *Sent:* Tuesday, August 10, 2021 9:07 AM
> > *To:* Dongjie (Jimmy) <jie.dong@huawei.com>
> > *Cc:* 6MAN <6man@ietf.org>; 6man Chairs <6man-chairs@ietf.org>
> > *Subject:* Re: Next steps with draft-dong-6man-enhanced-vpn-vtn-id
> >
> > Hi，folks,
> >
> > I think the extension to HBH header in this document is valuable.  It
> > aligns with the HBH header processing, and provide an approach to
> > efficiently identify the resources used for packet forwarding. This
> > mechanism will be useful in IPv6 networks where a large number of
> > network slices will be deployed.
> >
> > Chongfeng
> >
> >     2021年8月5日 上午9:56，Dongjie (Jimmy) <jie.dong@huawei.com
> >     <mailto:jie.dong@huawei.com>> 写道：
> >
> >     Hi WG,
> >
> >     In last week’s IETF 111 meeting, we presented the update of
> >     draft-dong-6man-enhanced-vpn-vtn-id. Due to limited meeting time, we
> >     didn’t have chance for comments and discussion.
> >
> >     As mentioned in the presentation, this version solves the comments
> >     received both in previous IETF meetings and on the mail list.
> >     Further review and comments are appreciated.
> >
> >     The authors believe this document is in the right direction of using
> >     HBH for per-hop forwarding treatment with a specific set of
> >     resources, and the content has become stable. Thus we would like to
> >     request for WG adoption of this document, thanks.
> >
> >     Best regards,
> >
> >     Jie
> >
> >     --------------------------------------------------------------------
> >     IETF IPv6 working group mailing list
> >     ipv6@ietf.org <mailto:ipv6@ietf.org>
> >     Administrative Requests:https://www.ietf.org/mailman/listinfo/ipv6
> >     <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
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> 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*