[Teas] Review of draft-ietf-teas-5g-ns-ip-mpls

[[e-mail]]

Authors, WG,

 

I reviewed draft-ietf-teas-5g-ns-ip-mpls. Please find below some comments:

 

*	General: This is applicable in general to all the network slicing
drafts: I don't really like the usage of "RFC XXXX Network Slice". The term
will need to be used both in IETF and mostly outside the IETF, it needs to
be more intuitive. I'm happy with TN network slice, IETF network slice, but
not RFC XXXX, it doesn't provide context for an external user. The term
Transport Network is controversial due to different meaning, but the in the
draft is extensively used, then why not using it also to identify the slice?
Moreover, if one day the RFC will be obsoleted? We'll need to update the
name of the network slices?
*	Abstract: s/This feature covers slicing requirements/This feature
introduces new requirements for all the domains.
*	Introduction: "(NRP), which is simply a collection of   resources
identified in the underlay network" - which underlay network? Underlay WRT
to the NRP? It needs to be explained a bit better.
*	Introduction:  "This document describes an RFC XXXX Network Slice
realization model in IP/MPLS networks, using a single NRP and with a focus
on fulfilling 5G slicing connectivity requirement" - Unsing a single NRP is
a choice of the authors or there is a 1:1 mapping between Slice and NRP?
*	Section 3.3 and related: The definition of transport network scope
and reference design is very useful, but would have been more appropriate in
the framework (too late now.). Why does the transport network go from NF to
NF and not from CE to CE? Isn't the NF typically part of the RAN or the PC
domains? 
*	Customer site orchestration domain: is this aligned with the
framework? From the framework I understood that the NSC manages the RFCXXXX
network slice, but here the orchestraion of the TN is done by the RFCXXXX +
customer site orchestrators. Does this mean that the TN slice and the RFC
XXXX slice are different things? In this case it should be stated clearly
before in the text (maybe it is but it took me 12 pages to understand it?)
Maybe anticipating figure 5 to the beginning as clearly defining the scope
of RFC XXX slice and TN slice helps. I went back to check the framework and
couldn't find any relationship between the RFC XXXX network slice and the TN
network slice, shouldn't it be there?
*	Section 3.5. Why 1 to N mapping? Are you sure the split between UP
and CP would lead to a single 5G slice mapped into multiple RFC XXXX slices?
The number of RFC XXXX should be significantly lower than the number of 5G
slices otherwise we risk to have serious scalability issues.
*	One interesting topic to address would be the case of TN slices
composed by multiple segments (I sent some text to describe it a while
back). The stitching of the different segments would be a nice problem to be
addressed.

 

Thanks,

Daniele