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

[Adrian Farrel <[e-mail]>]

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