[Teas] SFC and slicing

Adrian Farrel <adrian@olddog.co.uk> Sun, 23 May 2021 17:40 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1D35B3A2042 for <teas@ietfa.amsl.com>; Sun, 23 May 2021 10:40:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.052
X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=0.846, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UfzsHXGtiA5B for <teas@ietfa.amsl.com>; Sun, 23 May 2021 10:40:15 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636413A2041 for <teas@ietf.org>; Sun, 23 May 2021 10:40:14 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com []) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 14NHeCFa022451; Sun, 23 May 2021 18:40:12 +0100
Received: from vs1.iomartmail.com (unknown []) by IMSVA (Postfix) with ESMTP id 900C24604B; Sun, 23 May 2021 18:40:12 +0100 (BST)
Received: from vs1.iomartmail.com (unknown []) by IMSVA (Postfix) with ESMTP id 840384603D; Sun, 23 May 2021 18:40:12 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown []) by vs1.iomartmail.com (Postfix) with ESMTPS; Sun, 23 May 2021 18:40:12 +0100 (BST)
Received: from LAPTOPK7AS653V ( [] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 14NHeBjU023665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 23 May 2021 18:40:12 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <teas@ietf.org>
Cc: <i_bryskin@yahoo.com>
Date: Sun, 23 May 2021 18:40:11 +0100
Organization: Old Dog Consulting
Message-ID: <006e01d74ffa$aec567b0$0c503710$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AddP+Cy6X925jH4bRLG91y3U0kEFmA==
Content-Language: en-gb
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--3.847-10.0-31-10
X-imss-scan-details: No--3.847-10.0-31-10
X-TMASE-Result: 10--3.846600-10.000000
X-TMASE-MatchedRID: lOHN29jQbHQOwAmmWH5kBP7FEhWgo0y83V4UShoTXae/md2adk3dRPVZ RgYwg53IuN5ucsFDS5PtzqbwNDqs3DPWM/ZkTnTjQ5OaaEmFzZeX3dHCCeCwWi196sn93sBvuio XsEFi40zgngr7UzGnm7MTUjboGcLovyVS5uBh2g2OnKW5y3Y2vSIk3dpe5X+hUku+FPb4Sn8SNH j6zaP5xIiD+ERSRa5Q1gFwx84rPNbrhhonC8q8Q5CYtcHXhxbaOxjb9QQbt+R1Ddg7WD4hMmJjg 9GXn3itacPeCpXC55V42sweejr9QHJP1QUEHCwSngIgpj8eDcAWi1nwOKnDgYtkBWmEtb9tKrau Xd3MZDVPFzjCkfkYUgl7pJFxbizlXQzXCI5qXFAcDWA3mpZuCN/BaVjIUZSUjLnwu+LKlr9c2f/ l/RSdRDQy1DXjfI9zdeOo8ENF8uwyensl3L6+E6fItuohgjfnw/3NmPJsa4pNWfnUnboML1TXUX 0dTQdP
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/XYU0AwSNLKbbc3-Zu_C3Pz5G9JE>
Subject: [Teas] SFC and slicing
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 May 2021 17:40:17 -0000


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.