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

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 9 Nov 2020 19:25:18 -0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 9 Nov 2020 16:45:22 -0500

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:
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 9 Nov 2020 22:43:07 -0000

Yes Joel,

I think "isolation" as an SLO is a shorthand for "not only do I want my SLOs met, but I don't want any of the SLIs I forgot to capture in SLOs to be impacted by other services."

But 9.1 does say:
- can be met by simple conformance with other SLOs
- isolation from other services might be only a means [an] end
I think those are probably the points you are making when you say you don't see the point of an isolation SLO.

But we might usefully strike the five lines of example:
   For example, traffic congestion (interference from other services)
   might impact on the latency experienced by an IETF network slice.
   Thus, in this example, conformance to a latency SLO would be the
   primary requirement for delivery of the IETF network slice service,
   and isolation from other services might be only a means to that end.

A

-----Original Message-----
From: Joel M. Halpern <[email-masked]> 
Sent: 09 November 2020 21:45
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] Thoughts about draft-nsdt-teas-ietf-network-slice-definition and isolation

Yours,
Joel

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 9 Nov 2020 14:43:02 -0800

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

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 9 Nov 2020 14:45:44 -0800

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

Cheers,
Jeff

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 9 Nov 2020 17:47:53 -0500

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:
> 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

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 9 Nov 2020 15:37:45 -0800

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

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 9 Nov 2020 19:01:34 -0500

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.
> 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

---

From: Jari Arkko <[email-masked]>
Date: Sun, 15 Nov 2020 22:41:24 +0200

> Thank you Adrian.  I mostly agree with what you say 

Thank you Adrian and Joel. For what it is worth, I also agree, and like Adrian’s suggested wording (and Joel’s amendment). The new text would also be more concise and alive the task we need it to do: explain the importance of the isolation concept and relate it to the concepts introduced earlier in the document.

I think this actually gives enough expressive power to do the most common things that people request. And if there’s things beyond, the model is completely extensible with the introduction of additional SLOs.

And I don’t think Adrian mentioned this, but I also thought the concept of backups/fault tolerance could be an orthogonal, and should not be mixed with the isolation question. But Adrian’s proposal solves that too by removing that part of the text.

Jari (no hats, just personal opinion)

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 17 Nov 2020 09:57:39 +0000

> On 9 Nov 2020, at 23:37, Jeff Tantsura <[email-masked]> wrote:
> 

No, but in this class of networks the interaction between customers may be a lot more sensitive and detailed than we are used to. For example the single metrics that we normally associate with delay and jitter will likely become a mask in the same way that time and frequency transfer system find necessary to completely specify and instrument the behaviour of the subs system. We will likely need something analogous to MTIE and TDEV to describe packet and network interaction.

I therefore think it is useful to have an umbrella term for concept and the set of metrics that are of necessity more complex and critical than we are used to.

A possible alternative umbrella term is network cross talk. We understand the concept of crosstalk at the physical layer. The concept here in terms of performance is that packets do not interact at the micro level as well as the more normal macro level.

However, isolation has other feature that we need to think about under this umbrella, for example the need to only mix certain types of traffic allow (or exclude) traffic to flow over certain geographies or through nodes manufactured by certain countries. We do not have to agree with these constraints, but we need to accept that they are becoming a reality.

Now we could achieve the above by buying dedicated fibre or dedicated hardware, but that that does not support economies of scale.

I would be fine with us using a term other than isolation, but I think it is worthwhile highlighting that we are not in “ordinary” SLA territory with this, but that it is more complex and more detailed, and a top level term to group these characteristics is in my view helpful.

Best regards

Stewart

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 17 Nov 2020 05:05:37 -0500

Stewart, I think you are raising an interesting question, but one where 
I got lost part way through.

Can you elaborate one what you mean by "something analogous to MTIE and 
TDEV to describe packet and network interaction".

Thank you,
Joel

On 11/17/2020 4:57 AM, Stewart Bryant wrote:
> 
> 
>> On 9 Nov 2020, at 23:37, Jeff Tantsura <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
> No, but in this class of networks the interaction between customers may 
> be a lot more sensitive and detailed than we are used to. For example 
> the single metrics that we normally associate with delay and jitter will 
> likely become a mask in the same way that time and frequency transfer 
> system find necessary to completely specify and instrument the behaviour 
> of the subs system. We will likely need something analogous to MTIE and 
> TDEV to describe packet and network interaction.
> 
> I therefore think it is useful to have an umbrella term for concept and 
> the set of metrics that are of necessity more complex and critical than 
> we are used to.
> 
> A possible alternative umbrella term is network cross talk. We 
> understand the concept of crosstalk at the physical layer. The concept 
> here in terms of performance is that packets do not interact at the 
> micro level as well as the more normal macro level.
> 
> However, isolation has other feature that we need to think about under 
> this umbrella, for example the need to only mix certain types of traffic 
> allow (or exclude) traffic to flow over certain geographies or through 
> nodes manufactured by certain countries. We do not have to agree with 
> these constraints, but we need to accept that they are becoming a reality.
> 
> Now we could achieve the above by buying dedicated fibre or dedicated 
> hardware, but that that does not support economies of scale.
> 
> I would be fine with us using a term other than isolation, but I think 
> it is worthwhile highlighting that we are not in “ordinary” SLA 
> territory with this, but that it is more complex and more detailed, and 
> a top level term to group these characteristics is in my view helpful.
> 
> Best regards
> 
> Stewart
> 
> 
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 17 Nov 2020 10:22:27 +0000

They are terms from the timing world where you look at a defect in terms of its probability within a window within a larger observation period.

http://www.chronos.co.uk/files/pdfs/itsf/2008/Day2/Packet_TDEV_MTIE_and_MATIE_for_Estimating_the_Frequency_and_Phase_Stability_of_a_Packet_Slave_Clock_(Antti_Pietilainen,_NSN).pdf <http://www.chronos.co.uk/files/pdfs/itsf/2008/Day2/Packet_TDEV_MTIE_and_MATIE_for_Estimating_the_Frequency_and_Phase_Stability_of_a_Packet_Slave_Clock_(Antti_Pietilainen,_NSN).pdf>

ITU define MTIE in G.810, but they are looking at a different class of application (frequency transfer), but I think the concept translates over here.

If you look at slide 5 “MTIE of a practical packet clock” you get the idea, but I think it needs expanding and applying to other characteristics. 

Now some of the error sources will be within the slice, but we also need to worry about error sources induced from outside the slice.

Best regards

Stewart

> On 17 Nov 2020, at 10:05, Joel Halpern Direct <[email-masked]> wrote:
> 
> Stewart, I think you are raising an interesting question, but one where I got lost part way through.
> 
> Can you elaborate one what you mean by "something analogous to MTIE and TDEV to describe packet and network interaction".
> 
> Thank you,
> Joel
> 
>>> On 9 Nov 2020, at 23:37, Jeff Tantsura <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 17 Nov 2020 05:28:38 -0500

Is this analogous to specifying a burst rate with several rates over 
several time periods (only we are talking about operator ccommitments 
rather than customer commitments)?

If so, might this be something like a multi-level delay bound 
commitment, e.g.
For a given pair of ports
99% of your traffic will get there in 10 ms, and
90% of your traffic will get there in 100 ms
(I know, sloppy example, just trying to see if I am understanding the idea.)

If that is the idea, I am missing the aspect of "from outside".  From 
the customers perspective all problems are "from outside".  Whether that 
outside is a backhoe or competing traffic.

Yours,
Joel

On 11/17/2020 5:22 AM, Stewart Bryant wrote:
> They are terms from the timing world where you look at a defect in terms 
> of its probability within a window within a larger observation period.
> 
> http://www.chronos.co.uk/files/pdfs/itsf/2008/Day2/Packet_TDEV_MTIE_and_MATIE_for_Estimating_the_Frequency_and_Phase_Stability_of_a_Packet_Slave_Clock_(Antti_Pietilainen,_NSN).pdf 
> <http://www.chronos.co.uk/files/pdfs/itsf/2008/Day2/Packet_TDEV_MTIE_and_MATIE_for_Estimating_the_Frequency_and_Phase_Stability_of_a_Packet_Slave_Clock_(Antti_Pietilainen,_NSN).pdf>
> 
> ITU define MTIE in G.810, but they are looking at a different class of 
> application (frequency transfer), but I think the concept translates 
> over here.
> 
> If you look at slide 5 “MTIE of a practical packet clock” you get the 
> idea, but I think it needs expanding and applying to other characteristics.
> 
> Now some of the error sources will be within the slice, but we also need 
> to worry about error sources induced from outside the slice.
> 
> Best regards
> 
> Stewart
> 
> 
> 
>> On 17 Nov 2020, at 10:05, Joel Halpern Direct 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Can you elaborate one what you mean by "something analogous to MTIE 
>> and TDEV to describe packet and network interaction".
>>
>> Thank you,
>> Joel
>>
>>>> <mailto:[email-masked]> <mailto:[email-masked] 
>>>> <mailto:[email-masked]>>> wrote:
>>>>
>>>> infrastructure with you, it is well understood that any changes 
>>>> within other customers should not affect you.
>>> No, but in this class of networks the interaction between customers 
>>> may be a lot more sensitive and detailed than we are used to. For 
>>> example the single metrics that we normally associate with delay and 
>>> jitter will likely become a mask in the same way that time and 
>>> frequency transfer system find necessary to completely specify and 
>>> instrument the behaviour of the subs system. We will likely need 
>>> something analogous to MTIE and TDEV to describe packet and network 
>>> interaction.
>>> I therefore think it is useful to have an umbrella term for concept 
>>> and the set of metrics that are of necessity more complex and 
>>> critical than we are used to.
>>> understand the concept of crosstalk at the physical layer. The 
>>> concept here in terms of performance is that packets do not interact 
>>> at the micro level as well as the more normal macro level.
>>> However, isolation has other feature that we need to think about 
>>> under this umbrella, for example the need to only mix certain types 
>>> of traffic allow (or exclude) traffic to flow over certain 
>>> geographies or through nodes manufactured by certain countries. We do 
>>> not have to agree with these constraints, but we need to accept that 
>>> they are becoming a reality.
>>> I would be fine with us using a term other than isolation, but I 
>>> think it is worthwhile highlighting that we are not in “ordinary” SLA 
>>> territory with this, but that it is more complex and more detailed, 
>>> and a top level term to group these characteristics is in my view 
>>> helpful.
>>> Best regards
>>> Stewart
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 17 Nov 2020 14:26:08 +0000

> On 17 Nov 2020, at 10:28, Joel M. Halpern <[email-masked]> wrote:
> 
> Is this analogous to specifying a burst rate with several rates over several time periods (only we are talking about operator ccommitments rather than customer commitments)?
> 
> If so, might this be something like a multi-level delay bound commitment, e.g.

Yes, but they do it as a rolling average, so sample every 1ms (say) sample 1..10 gives 10ms, sample 2..11 give 10ms result2, then 1..100 gives 100ms result1, 2…100 gives 100ms result2.

Now there is a cool thing in the timing world, but the slope of the curve at a point in the curve tells you the cause of the error. I am not sure if this would apply to our application, but it is worth thinking about.

> If that is the idea, I am missing the aspect of "from outside".  From the customers perspective all problems are "from outside".  Whether that outside is a backhoe or competing traffic.

I suppose you are right, but in this world it does not have to be congestion, there may be enough macro bandwidth, just not at the right ns which is on a much finer granularity than we are used to, and is more transient than we are used to.

- Stewart

>>> On 17 Nov 2020, at 10:05, Joel Halpern Direct <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>>> On 9 Nov 2020, at 23:37, Jeff Tantsura <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>>