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

[Joel Halpern Direct <[e-mail]>]

You raised the dedicated fiber question.
If one has an end-to-end system with multiple components, there are many 
places where there simply will not be dedicated fiber.

More importantly, I see no way to meaningfully express "the customer 
wants as much dedication as possible" in the interface we are 
discussing.  Such a declaration will be dealt with in different ways by 
different people / systems / adminstrations, meaning that it gives no 
reliable behavior to the customer.

I agree that Isolation is not an SLO.   But if it is not an SLO, I do 
not know how it fits with the rest of what the definitions draft lays out.

Yours,
Joel

On 11/9/2020 6:37 PM, Jeff Tantsura wrote:
> Joel,
> 
> There’s no buying of any fibers, a slice is a service provided by a 
> provider to a consumer. A fiber between point A and point B is a valid 
> example of a slice, as much as an LSP, lambda, or any other technology.
> We are talking about defintions (terminology) applicable.
> 
> Would the following definitions work for you?
> dedicated infra (in any way or form) - for example some vendors allow 
> you to have a dedicated NPU on router.
> disjointed infra, where backup path is isolated (non fate sharing) from 
> primary, e.g. SRLGs, common devices, etc
> 
> I don’t think mixing performance objectives with isolation is a great 
> idea though,
> an SLA doesn’t change because there’s someone else sharing 
> infrastructure with you, it is well understood that any changes within 
> other customers should not affect you.
> 
> Joel - my last objective in the world would be to have you to object the 
> same draft again, please bear with us in preparing for the adoption.
> 
> Cheers,
> Jeff
> On Nov 9, 2020, 2:47 PM -0800, Joel Halpern Direct 
> <[e-mail]>, wrote:
>> If your security policy requires dedicated fiber, buy dedicated fiber.
>> If you are going through shared routers, shared roadMs, etc. then
>> dedicating the fiber seems to me to completely miss the point.
>>
>> And none of the definitions I have seen for what "Isolation" could mean
>> go to the requisite level of detail. If it means "the entire
>> infrastructure must be dedicated", then I do not think it belongs in the
>> IETF. If it means "dedicate something, please", then it is not an SLO.
>>
>> The definitions and framework draft are explicit that they are
>> technology agnostic. So it is really hard to see how you can express
>> any meaningful and useful isolation, assuming that there is such a thing.
>>
>> More importantly, I would want to see an actual definition of what is to
>> be described if we are to include it.
>>
>> I am not asking that the placeholders be removed. There may be a
>> definition that is useful. But what is there isn't it. Saying that
>> there may be some as yet undefined SLO that relates to som as yet
>> undefined meaning of Isolation does not cut it for me.
>>
>> And yes, I am getting tired of refighting the same discussion. We
>> agreed on leaving placeholders in the document. I was hoping and
>> expecting that we could get the result of that adopted. I do not like
>> having to object to the same draft again.
>>
>> Yours,
>> Joel
>>
>> On 11/9/2020 5:43 PM, Jeff Tantsura wrote:
>>> Joel,
>>>
>>> Thanks for your comments.
>>> I respectively disagree with you, if my security policies require use of
>>> dedicated infrastructure (fiber is a common one), it is a valid service
>>> objective.
>>>
>>> Cheers,
>>> Jeff
>>> On Nov 9, 2020, 1:45 PM -0800, Joel M. Halpern <[e-mail]>, 
>>> wrote:
>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/teas
>>>>>