Re: [Teas] SFC and slicing

mohamed.boucadair@orange.com Mon, 31 May 2021 08:31 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138233A0E22 for <teas@ietfa.amsl.com>; Mon, 31 May 2021 01:31:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29AwUGq_A7Fb for <teas@ietfa.amsl.com>; Mon, 31 May 2021 01:31:07 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C89D3A0E21 for <teas@ietf.org>; Mon, 31 May 2021 01:31:06 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 4FtpQv5RL3z20dH; Mon, 31 May 2021 10:31:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1622449863; bh=R0xwIwH9rmG29bGRd0mxyyT+tOfisVHPWdrhhYKB0FI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=qs3Y26YVEG1kQwKWgud3iONr174QOeY94PeN23yhSwvZNAw1+rQTP4rm9Bcfin3zg vDJJ9eHfOjbMI6ixDdXYxYihJY/4wakTl7WUXgWySftHcnR5Sf+dEXhX8Nj//xwRvv RO+HL4csOfbdVfCpkJLqqJvwMNkJDeCfoJohUaTRvOYlX1Pziet3sNfSH8N2j1gby3 gFKtRfxRWFG2xP6e6xD2TKH4yXUBHW4Q7pB1ommSzwAEfrRzDC7ZA9OevkSM12TicH BVJUhNoXLPdptAxSccYGzEK3AuPWk5IbE8mWf3KqjtZljx67VjOJs+42YUGajCmV36 DD0wjArrunc+g==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 4FtpQv4cgvz1xpq; Mon, 31 May 2021 10:31:03 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org>, "teas@ietf.org" <teas@ietf.org>, Adrian Farrel <adrian@olddog.co.uk>
Thread-Topic: [Teas] SFC and slicing
Thread-Index: AddP+Cy6X925jH4bRLG91y3U0kEFmAAnGEH+///rugCAACBRAP/1S2oA
Date: Mon, 31 May 2021 08:31:01 +0000
Message-ID: <32418_1622449863_60B49EC7_32418_441_4_787AE7BB302AE849A7480A190F8B933035394E31@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <006e01d74ffa$aec567b0$0c503710$@olddog.co.uk> <MN2PR15MB3454AF3E8DF6856B28F642F6A0269@MN2PR15MB3454.namprd15.prod.outlook.com> <011101d7509b$2fa58a90$8ef09fb0$@olddog.co.uk> <2071994812.1094145.1621867486287@mail.yahoo.com>
In-Reply-To: <2071994812.1094145.1621867486287@mail.yahoo.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933035394E31OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/2FeDo1-M1YpyZS3WXz5tbyxzTmI>
Subject: Re: [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: Mon, 31 May 2021 08:31:12 -0000

Hi Igor, all,

There are use cases for which distinguishing the overall slice service objectives (between CEs) vs. those involving SFs may make sense from a service standpoint:


·         Think about some SFs such DNS server. The placement of such as an SF is critical for some services. CE-SF service requirements have to be distinguished from the overall slice service requirements.

·         Some service chains may be used for traffic hooking within a slice. That is, the traffic won’t exist the slice but will be proceed by a set of SFs that are structured as service function chains. The traffic performance of the service chain can be captured in its own vs. the one between CEs.

Putting aside the endpoint discussion, these two points can be covered in the draft by making this changes:

OLD:
   The SLOs are defined for sets of
   two or more endpoints and apply to specific directions of traffic
               ^^^^^^^^
   flow.  That is, they apply to specific source endpoints and specific
          ^^^^^^^^
   connections between endpoints within the set of endpoints and
   connections in the IETF Network Slice.

NEW:

   The SLOs are defined for sets of

   two or more points and apply to specific directions of traffic

               ^^^^^^

   flow. For example, they apply to specific source endpoints and specific

         ^^^^^^^^^^

   connections between endpoints within the set of endpoints and

   connections in the IETF Network Slice. Likewise, they can apply

                                          ^^^^^^^^^^^^^^^^^^^^^^

   to specific flows that involve an endpoint and a service function or

   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   a set of service functions.

   ^^^^^^^^^^^^^^^^^^^^^^^^^^

Cheers,
Med

De : Teas [mailto:teas-bounces@ietf.org] De la part de Igor Bryskin
Envoyé : lundi 24 mai 2021 16:45
À : teas@ietf.org; Adrian Farrel <adrian@olddog.co.uk>
Objet : Re: [Teas] SFC and slicing

Right. I suppose we need to hear from operators. Specifically, focusing on the delay SLO I'd like to ask:
1. Is it possible that requested SFs in an SFC need to be time synchronized in a client specific way?
2. If e2e delays D, how the network is supposed to spend the delay budget between SFs in the requested SFC:
a) arbitrarily;
b) evenly.
c) in proportion specified by the client


Cheers,
Igor


On Monday, May 24, 2021, 08:49:31 AM EDT, Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>> wrote:



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?



Thanks,

Adrian



From: Igor Bryskin <i_bryskin@yahoo.com<mailto:i_bryskin@yahoo.com>>
Sent: 24 May 2021 13:22
To: teas@ietf.org<mailto:teas@ietf.org>; adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>
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.

Cheers,

Igor

Get Outlook for Android<https://aka.ms/ghei36>



________________________________

From: Teas <teas-bounces@ietf.org<mailto:teas-bounces@ietf.org>> on behalf of Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Sent: Sunday, May 23, 2021 1:40:11 PM
To: teas@ietf.org<mailto:teas@ietf.org> <teas@ietf.org<mailto:teas@ietf.org>>
Cc: i_bryskin@yahoo.com<mailto:i_bryskin@yahoo.com> <i_bryskin@yahoo.com<mailto:i_bryskin@yahoo.com>>
Subject: [Teas] SFC and slicing



Hi,

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.

Best,
Adrian

_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas
_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.