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

Thank you Adrian.  I mostly agree with what you say (retained below.)

The only point where I disagree is that the proposed text fro 9.1 still 
keeps the notion that there may be an Isolation SLO.
As far as I can tell, Isolation is a mechanism.  It is one of many 
mechanisms that can be used to meet the SLOs.  I have no idea what an 
Isolation SLO element would be, or why a customer would ask for it.
So I would be inclined to go a step further and just get rid of 9.1.

Yours,
Joel

On 11/9/2020 2:25 PM, Adrian Farrel 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
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
> 