Re: [Teas] Thoughts about draft-nsdt-teas-ietf-network-slice-definition and isolation

[Jeff Tantsura <[e-mail]>]

Thanks for your comments Adrian.
The co-authors will review and come back to you ASAP.

Cheers,
Jeff
On Nov 9, 2020, 11:25 AM -0800, Adrian Farrel <[e-mail]>, wrote:
> Hi,
>
> I'm not sure where the right place to discuss this document is. Since it
> replaces the previous terminology document, and since that was proposed for
> adoption on the TEAS list, I think this is probably the right place (feel
> free to redirect me).
>
> I'd like to focus this email just on Section 9 - the text on isolation. I
> suspect that this is the largest remaining obstacle to WG adoption.
>
> Firstly, we have to recall that this is a terminology document, not a
> broader architecture. Therefore we should aim to reduce the text to clear
> and simple definitions: further text belongs in some other document such as
> the framework draft or a focus-specific document that describes some facet
> in detail. So I guess I agree with the Editor's statement at the top of
> Section 9...
> > Editor's note: This content is a work in progress. The section on
> > isolation is too descriptive.
>
> A way to reduce this would be...
>
> == Section 9 ==
>
> OLD
> An IETF Network Slice consumer may request, that the IETF Network
> Slice delivered to them is isolated from any other network slices of
> services delivered to any other customers. It is expected that the
> changes to the other network slices of services do not have any
> negative impact on the delivery of the IETF Network Slice. In a more
> general sense, isolation can be classified in the following ways:
>
> Traffic Separation: Traffic of one network slice should not be
> subjected to policies and forwarding rules of other network
> slices.
>
> Interference Avoidance: Changes in other network slices should not
> impact to the SLOs of the network slice. Here the changes in
> other network slice may include the changes in connectivity,
> traffic volume, traffic pattern, etc.
>
> Service Assurance: In case service degradation is unacceptable due
> to unpredictable network situations producing service degradation
> (e.g., major congestion events, etc.), explicit reservation of
> resources in the network maybe requested for a reduces set IETF
> network slices.
> NEW
> An IETF Network Slice consumer may request, that the IETF Network
> Slice delivered to them is isolated from any other network slices of
> services delivered to any other customers. It is expected that the
> changes to the other network slices of services do not have any
> negative impact on the delivery of the IETF Network Slice.
> END
>
> In making this change I'd note that while these three principles are an
> important part of the discussion of isolation they are out of context here.
> Traffic separation is a feature of how isolation may be achieved, but it is
> not something that a consumer can or should specifically ask for: they have
> no way of measuring it and, indeed, since they don't know the purpose of
> policies and forwarding rules within an operator's network they shouldn't
> ask for control over them. Interference avoidance is a fine goal for a
> consumer to ask for, but you already have this captured in the preceding
> paragraph. Service assurance seems to capture two things: that the consumer
> may wish for protection of their service in the event of network failure
> (that's not really an isolation thing) and that a way to protect against
> failure situations is to reserve resources (that's not necessarily an
> isolation thing, and is certainly a question of realisation).
>
> == Section 9.1 ==
>
> I think that this section is a little over-stated. Maybe:
> OLD
> Isolation is an important requirement of IETF network slices for
> services like critical services, emergencies, etc. A consumer may
> express this request through the description of SLOs.
> NEW
> Isolation may be an important requirement of IETF network slices
> for some critical services. A consumer may express this request as
> an SLO.
> END
>
> == Section 9.2 ==
>
> While I think there is value in having this section to note that there is a
> concept of isolation in the realisation of a network slice, I don't think
> you should get into details with examples etc. If you want to talk about how
> realisation of network slices works, that should be in another document.
>
> Thus, I think you could drop the whole of the fist paragraph: it just
> duplicates some of the ideas in the second paragraph which says it more
> clearly.
>
> Furthermore, the final paragraph in the section seems to be all about
> realisation. I think you should drop it partly because it is technically
> suspect (an L3VPN does not achieve traffic separation in the network, that
> is exactly the point of an L3VPN), but mainly because it is a discussion of
> the details and technologies of realisation.
>
> == Section 9.3 ==
>
> I tend to think that there will be value in a full and careful discussion of
> how IETF network slices meet the requirements of 3GPP transport slices, but
> I don't think it should be in this document. Thus, I agree with the editor's
> note that the section should be removed. Maybe interested parties could
> start a new document "Applicability of IETF Network Slices to 3GPP Transport
> Slices."
>
>
> Thanks,
> Adrian
>