Re: [Nfvrg] [Detnet] Network Slicing - a suggestion that we meet to discuss in Seoul

Stewart,

Two comments on draft-dong-network-slicing-problem-statement-00 that may be of interest:

1. In your discussion of dedicated vs. hybrid vs. shared control plane, I would have added, to the sentence describing the advantages of the dedicated control plane, the expense of duplicated effort across slices, e.g.link failure detection (BFD).

2. Although not explicitly discussed in the DetNet documents, IEEE 802.1 Time-Sensitive Networking has the ability, to configure synchronized rotating input and output schedules, with nanosecond granularity, that can erect time-based barriers among a modest number of network slices.

— Norm

> On Nov 1, 2016, at 8:21 AM, Stewart Bryant <stewart.bryant@gmail.com> wrote:
> 
> 
> (Resent with correct draft alias)
> 
> Hi,
> 
> We were trying to pull together a problem statement for network slicing
> in a 5G context to understand how well the current IETF protocols address this problem, what their short comings might be, and what IETF work is necessary to have a deployable protocol suite to address this need.
> 
> We have set down our first thoughts in
> https://tools.ietf.org/html/draft-dong-network-slicing-problem-statement-00
> 
> We find that there are a number of groups doing similar work throughout the IETF.
> 
> The following comprehensive draft was directed at the ANIMA WG
> https://datatracker.ietf.org/doc/draft-galis-anima-autonomic-slice-networking/
> 
> https://tools.ietf.org/html/draft-vonhugo-5gangip-ip-issues-00
> is a detailed discussion the position of network slicing in a contest of next generation networks
> 
> https://tools.ietf.org/html/draft-xuan-dmm-multicast-mobility-slicing-00
> looks at multicasting in a sliced context
> 
> and
> 
> https://tools.ietf.org/html/draft-ietf-teas-actn-framework-01
> looks at slicing in a context of traffic engineering.
> 
> Our thoughts are that network slicing spans a number of deployment
> scenarios, and has a number of diverse applications, ranging from
> fragile applications, through to providing enhanced security and availability.
> 
> Elements of the problem and the resultant solution have a close affinity
> to DETNET. There is clearly an affinity with VPN technologies, although
> none of the existing VPNs provide the degree of isolation that we think
> is required.
> 
> We note that there seems to be no natural home for all of the aspects
> of this problem.
> 
> It therefore seems that if would be a good idea for those interested
> in this problem to get together at some point during IETF to swap notes
> and share our views on the problem space and how to move forward
> with addressing it.
> 
> Is there any interest in meeting up to discuss this in Seoul?
> 
> Best regards
> 
> Stewart/Mach/Jie
> 
> 
> 
> 
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet