Re: [Teas] SFC and slicing

Adrian Farrel <> Mon, 24 May 2021 12:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7BEDA3A2730 for <>; Mon, 24 May 2021 05:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XqbZrJIj2mif for <>; Mon, 24 May 2021 05:49:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 246483A272F for <>; Mon, 24 May 2021 05:49:15 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 14OCn85E030693; Mon, 24 May 2021 13:49:08 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id C80F146050; Mon, 24 May 2021 13:49:07 +0100 (BST)
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id BBEB64604D; Mon, 24 May 2021 13:49:07 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS; Mon, 24 May 2021 13:49:07 +0100 (BST)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 14OCn6TY031240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 May 2021 13:49:07 +0100
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Igor Bryskin'" <>, <>
References: <006e01d74ffa$aec567b0$0c503710$> <>
In-Reply-To: <>
Date: Mon, 24 May 2021 13:49:06 +0100
Organization: Old Dog Consulting
Message-ID: <011101d7509b$2fa58a90$8ef09fb0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0112_01D750A3.916A8ED0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGbTatocC6Qov/J66rgPtoMHdyZMgGD1ldMq154AyA=
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--21.359-10.0-31-10
X-imss-scan-details: No--21.359-10.0-31-10
X-TMASE-Result: 10--21.359100-10.000000
X-TMASE-MatchedRID: Z/tjqhsgM6dgwvPAcjnVh6OCzEVIgcGWTLVep7PbHDXgQZnNOyLmAjSu jLTQ30U9ApIb11Bs8jePR2u912hYRMo0g7hj5evQLX3qyf3ewG/Q8w9je4hrWcJ9PGIFQ6FTVCH lgT24MfsUN/8aAzvyJfRUId35VCIeGUqOjzOC7IqsZuPCI7d/32lF7OhYLlctK+Kql5dIzC847S 9T5Rr62Trl7gPhTJMP48SQ1JLtjzYYOnQDwWp0xMicqvB+icULWOUUKH0w1Vt3IxPw+LiObANGy /kheZJci4naEPbO9CKLeoWRUsfdQAILzOoe9wbaUHcBn70iJQfcK5HifN4uLgbY6r19VcuV3zjC 7JWzWrkOdJolmghCjElyMZ48GKwUj22EYl7ISJnNWDA/tkxh/5z/bBwW32ikaxE9Kn8Vayoi7mQ JNagMTotUkiO6jsmxY1bQMCMvmn4m4lf0t+giOESbbPTiMagTI6o3RbrH6CQA2Lbnp0k4zrqWSG GxvQz8RsDhaybAY03FOknc5CNvd/6lpfpte41hFTuQoTKiFmTzWhIpvgX1cDAhjB2UzQV1jIIhM lejU+5HW+94FA8JF8G0UNgaZpYq2gp+A6golza2M1wsSbtrkeV05r5vXH4svz00KMC0SEliWc3N HA3wJUNa5QnT8mQ0nQrZDK7DrTq87rU89eLPKUV2EP27j48ExOv8bbijtGuFZCZln65Hjqopduk EoenVpd9eRR8QtJVFH6oTiImwh3s0iNyjUNXyjh8W55J4iKeQiqvU3Pp26LRCsFR6IHb7neJDF5 gQeXG7gAzWLdoW9i+PrAd8gbHJOS0bT53qXdWbKItl61J/yWckPgNWUELAGt7mdu4lvE4/3GZ+d Hsx6g+SekUzknWgYXlfnK7BOiEMFsa+1wyh/Efd/icPiGBU7G6xu1rIKd0HHB+ej6HJRRbBVfSZ jmufz3y/aC6T2S4=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Teas] SFC and slicing
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 May 2021 12:49:23 -0000

It's an interesting question : "What would happen if the different parts of
the SFC needed different SLOs?"  But that is an "if". I wonder whether we
can decide whether this is likely.


Consider an end-to-end flow. We can easily decide on the end-to-end SLOs.
For example, there may be an end-to-end latency requirement. But it seems
unlikely that there is a special latency requirement between a pair of SFs.
Is there an example, where the SF-to-SF SLO needs to be specific?





From: Igor Bryskin <> 
Sent: 24 May 2021 13:22
Subject: Re: [Teas] SFC and slicing


Hi Adrian, 

Thanks for giving to this some thoughts. 

I see a problem with the suggested plan if it turns out along the road that
in a requested by a client SFC SF1-> SF2->...->SFn different sets  of SLOs
are required for each/some SFi->SFj links, as well as e2e across the slice.
I suggested one way to address this by describing slices as SF aware
abstract topologies. 



Get Outlook for Android <> 



From: Teas <> on behalf of Adrian Farrel
< <> >
Sent: Sunday, May 23, 2021 1:40:11 PM
To: <>  <
<> >
Cc: <>  <
<> >
Subject: [Teas] SFC and slicing 



Igor raised the question of "reconciling" the IETF work on service function
chaining and network slicing.

Some of the early discussions on network slicing considered not just
connectivity resources (buffers and bandwidth), but also other resources
that might be found in the network (like storage and compute). I was one of
the people suggesting this, and I know there were others. This would
certainly go some way to bridge the gap to SFC.

However, my understanding is that the design team (and others in the WG)
wanted to push ahead with the definitions for the connectivity resources
first, and consider adding other resources later.

I think this is wise. We have taken quite a long time to get to this point
(especially if you consider the early network slicing BoF), and it is
certainly the case that the first deployment drive is for connectivity
resources. Perhaps we should sort that out first.

That said, I don't think that adding other service descriptions would be
hard. It feels like the definition of further SLOs and SLEs. 

If we want to continue this discussion, we should probably involve the SFC
working group to see how they feel about it. But anyone who is interested in
this could certainly begin work on specifying the SLOs and SLEs that they
will want to see added to the NBI.


Teas mailing list <>