Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt

Igor Bryskin <i_bryskin@yahoo.com> Sun, 07 February 2021 14:03 UTC

Return-Path: <i_bryskin@yahoo.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 9FE0B3A0E0E for <teas@ietfa.amsl.com>; Sun, 7 Feb 2021 06:03:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 PY75_qL5OgL2 for <teas@ietfa.amsl.com>; Sun, 7 Feb 2021 06:03:33 -0800 (PST)
Received: from sonic314-20.consmr.mail.ne1.yahoo.com (sonic314-20.consmr.mail.ne1.yahoo.com [66.163.189.146]) (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 9820F3A0E0F for <teas@ietf.org>; Sun, 7 Feb 2021 06:03:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612706612; bh=y6dJTZGVP62t2hdKV3Pzfzr9C/Hk4xzzI7htLKxfunQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From:Subject:Reply-To; b=t+HIFGRC/2CXfEN1+2FTmKgtc90TgoXwl+CQp0XQ8S9u5wJx4JqV7upROwA8v5G3us58Ll/0lWVb/CPN/MpxPLB0HX2KEbr8LFshCxLP6yqnc/Jd8fKLmCzurSRNyWnwx/LeWMNQUmTM8TXm+Qmw2tctIslXjf74UMo3Lxfzfd7ZOFMaayOGFc3qgjn2VnhGrwKGeP9kpnISzHVl0dc6mDXTCFKXOgvCVN7BFL7rPunHZAwBG0eDlSxaU9SU2vtnOdo5MniiEs3cU8VPB2uJYroyr4ngFu2abTFuFPh3yqMb0+4dVaU2v5hDt4K1PubaEgY7BjbD7chCezLUHygOpA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612706612; bh=l+5saeAOa4mv6kmkqiARLqpGD8/wcDm7Pn6QBnAVApB=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=o/qqoQdmzUAGeaCF193CcsLqsUVHfJX+5Ew0NOmtQDVKzcXpsEXdi0vL3aIasAnQz0aVFrFtRHrwICLWchn+w97JZGGxnZw05sbwc8UHoogLRheSKbRQf1iCQvPFm/69C7neD3IoEr85Lllxqs7glCsME6VW62oS3lBD6BBt30/0d1vwYD/4tekoLH23/k1EoEkaQT/OkXUlKmLh+Za87tEbz7+9lpHV/uJWxZunOE9326Deq37s3U0PXljJFyC/ngGi/3QZn7hwYqnHTxDTn5yKLksJ1NJoIWrajyjZQ67xsufkrdUTSvnanzXu6ILGKe56PIjdm9AmLr3BZneBXQ==
X-YMail-OSG: xZ2HPqsVM1lBSjQxOp.eukP6DyrHmBU7npMh2Hd3nLYmnbT5q_lavAh1Z22oidm 5A2_NcxDzFGl1fJ9.HdJ3FSuvgeeW8B5w264CBSoERc4k0TNiSu9P8OVoSFc0R5sNNNXRuly__Fx p8imESU.Cv98pX2zY9.TtInitiryP07Cg3xISe3GuBjNsw0ZfG1v2bEJhR_p.HPnXJgs1d67mqgx yvLMzEmqC4k8Stb.NfAT8tPNpUa67d7DHx6HDxoSRIqEj1OZxl9bip4pgSBBpTfX0sViKXxAEcDA qrGDbhkyzJSXrmV4zZsuo2h0R6O0oVAUvrybFaxtyV7tWTekFQo1NlnjFzdsIA.lV689ajQ4zUfy uFi_srJnWvksDbFH626L5tK0n5Bogou1rsy00lD5oMgTV9Pi1tN8Mh9z2TtDeE5OUGzCpp.kaK3R 3HSYoHmBXzXmSgmwf.HJ5ftA4R5LKONQygF5RVyXu0e7ufa.x1PdNyiepWe0vCcdLw3BOPE8Nknt sjQrQOUU3r8jr1K96FpxJ0Lmklshl1c9mX3hNrcYkVdHmDJyt9SGEQ9Q2QiZkEHBKJcyCQXP_irD b11PXHoKeBDPvOS0idCIhnjiZTiz2I7tMDbhXoEZaqgTWNZhE1J7IrRAZRPe5H7RUC5qxgEH_7bA H8F3g5OCWGKUDgiScfhumlBg0XWe1JcQz_BjIFu1AmEqDoP3Y9oG9rTr5KRNOvKQA61FON1gxtt0 Ss3LUEl_oh5CuCAKad96Oi_w0DjN6TeUFcUXFlLyDTElk4.Ge1IyHvjwCeY_dQk_T_Hp2SUUpDs9 loYwfjH7zioHF1r9Pu8B4DTjQiPnDDh8ipFPdXguLwezTn84Il8lSl9dUTmUHUKeFLQcqal.QDBo P09FcN.XP.7RUUOHIoi5u.yLkKdDXhpvf6xhDeX8icUFn62Ra_JxXKeQhzCFgPVlewRfpZsx58PL JBWp8XxyuqIv253ppBgTOM_FNybqOzIHQ2sKTRFKcX6Kdft_2BY5Qhh3xUTpqPekkQBGL7382cjP 3bxCNPfaYGUZ5USxoBa3J9DqiEUSdnc2Sg032.U3fN88uI1eUKu1xfhp0YIJvWNyVSXBl9W3gv6u P_LImtl8_yQ3oOWaK4L69dPC5QYuek8raiPurcnVl6vzb7nQ_OtLV5jBEsKtTDRWUksvJ90nTfq3 03RrlC6Rvtehkvid1VhR.7FkS41CRSeWy8SgzLpVEBfQE7UNHyESleUOtquz5nqkTWLf5ccvFEVZ rDNwKq3yZfrzmctt1US9xHeCpO18qhiNixnBjVf0mA1X4oYtYnCO3HyxIJ1aYDVW.2y8NZt0A4Rt fhAyJQrI.oUzd4DOgw4XvpLFelN8oKr0UvS2X.HwgvJ3bo.cHmCob8cVKgm8osCTz1ssggW1iebs a.f8zN6Nbvnh7xvvXbYnJxAEjGRaWs_DyUY5EeR1aauAPUoUMPLguyqJEO1VQp7qpfakJGnovzkk ta9TAI7V29k5c8kwmUj6SgYCFImAhbgjWCWyQZtfaS0XK.6kDWBaYHWqtCiVb6YMrnTP03oONFUS v450F3NkFyO0nm7iMdpTsc8AiIllX1msqJhW1Jh.51wJS5I_wsh8GKTqig8RJ.1QpBHQn2KYr47L OocQZmbyl90yALVFOyHu9PWoJkBs0kyAB0ojA961Pk.FylD_9QyuDEPzr14orHuZYxp5OYe17m1O 02.x8Xl1CNy1tnBJkUr42P1id36YpcNoMxu3ulZ6OmHAOk.PAEPPN_ZwuNkEb.aK2LBYijGDpM8r RYbUCAE4pAObpKcVXMwSwJ4lcJB5d0di1mVbpRTeHzp1EdDs_TG.Tp7ymHZ7bfd9qLaP2bs_INbI 3RWWBWAtvQyHiJ2UBdcQVVdgJG1Ra4eVeC9Urdy0WTEexhZFeKeT7RdRyivdhUCgmp4Q_18s7Oyg t5xLKSKqbNAvym8yCVI_ixTEbCS9yq55RbucPRgoJ6ylHhZJ4Q40OSwyrhmhmNcql3BqiMuir2HR Thnor5uZ03GfwN0xlQxRrFfGim_BM1VFQol6rxx1uZrP3lXcU3DOeZ.YB7a1fP_4Cn7qSLjXvOC2 Vy8ytDEiGikKCd4IVBHKv6EhvfRusA3y3Qy6R2kP8RPjAnsz.WQyIcQ_gIcpwu_oZiZRxDh3Ki14 b.9C6KMUn0UZAl_iCGmuwl5N3MFq5hPdlI6T7k3v0drEx9hHVDFwQ4C45048WpncDenBEpb2ooOL CrJqg8BDbfQBc9iQddZ3waNZy75kMhL0B3clGRNKmT.LwYiavEJ8tUQMXcSOyuT_1s9D7u2fmOvu 1EkVGkLAeVV6NsIGN5idqO7pSHWNUTDnYx831wzb89b5sXXoBkp0v0xp8JPWJVjbVXrwUjDKSiWv aeYxfAIypU_QCfaekIVn0Gyr_mWjYJ_v7qjfG.WGgH6tt4OKldGH7pCu85ErV6jG4kw4psQct46V XR866jbOxJxV1LK0SUnwvWZ4_5gHInj._fUcrZftjD0aAClU8pVpvOzC6weDVt0iUz5Lhdl7pYxu J_2LJxMbiLmI6ingwbyLBHs8ihCYVMpZ4e8Lhp4SRF7FEzB0aFInrvs2PFEZFwF0gnmx04pyvhnv rSVRtqWAoJOXvMH0QYUh7gw4Tk0QHMPL8w9_qdq3gqMl1tgqcairF1K08sYEveM_NmxfHEEklHUI m_yHEhoQt.hp80uUMx_uCkSnxMjN5Vp59.VnSWVtIUxuYVnG52fOiOy8b9xQDo9wG_2AWKB_nB_3 9LDzupvbhyYHbfK2.73lbZAWBMhXl75pjm._lyK1Ztbft5O3KG4CkGWi_LUoID90AG3tSqzLuGxX uPOnn9k89Sn4KI6O8oEMSem3.pYYp9Y1Q
X-Sonic-MF: <i_bryskin@yahoo.com>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Sun, 7 Feb 2021 14:03:32 +0000
Received: by smtp408.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 68ee660e155a9b00b5e160de1954de23; Sun, 07 Feb 2021 14:03:31 +0000 (UTC)
From: Igor Bryskin <i_bryskin@yahoo.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>, Gyan Mishra <hayabusagsm@gmail.com>
CC: Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org>, "draft-bestbar-teas-ns-packet@ietf.org" <draft-bestbar-teas-ns-packet@ietf.org>, TEAS WG <teas@ietf.org>
Thread-Topic: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt
Thread-Index: ATAyMzcwz1nVZ13L8uB/thznweqMNTNGMjQ3UVJUcWlRVFcxN8bm4pNm
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Sun, 7 Feb 2021 14:03:30 +0000
Message-ID: <BN6PR16MB1683FD38A7080E2BDAC114B0A0B09@BN6PR16MB1683.namprd16.prod.outlook.com>
References: <160866255058.12375.3624366295025144530@ietfa.amsl.com> <B5853097-0690-45E9-9123-6F74FBCC4F03@juniper.net> <CABNhwV1u=iiK_2PQTKCquDbVwXanbTfB7U5GEzNRcgNY=iHhqQ@mail.gmail.com>, <CA+YzgTvrk7bXDzyChjy1HORbAdb6XWLhaWpZP=gTbXUhTs3+3Q@mail.gmail.com>
In-Reply-To: <CA+YzgTvrk7bXDzyChjy1HORbAdb6XWLhaWpZP=gTbXUhTs3+3Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_BN6PR16MB1683FD38A7080E2BDAC114B0A0B09BN6PR16MB1683namp_"
MIME-Version: 1.0
X-Mailer: WebService/1.1.17648 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Apache-HttpAsyncClient/4.1.4 (Java/11.0.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/cGgPuHi-cKl2u_JIQgAfxT509Vs>
Subject: Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt
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, 07 Feb 2021 14:03:38 -0000

Gyan and Pavan,

When a packet arrives at a node participating in a multi-slice network, the packet needs to be treated and *routed* according to the slice it belongs to. Because the physical data link over which the packet has arrived could be used by more than one slices, the packet needs to carry somewhere the slice ID. IMHO because the slice topology may dynamically change, it would be simpler and cleaner to carry the slice ID, rather than slice aggregate ID, as suggested by the draft. I also agree with Gyan that the COS field may not be the best choice for the task.

Regards,
Igor

Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: Teas <teas-bounces@ietf.org> on behalf of Vishnu Pavan Beeram <vishnupavan@gmail.com>
Sent: Thursday, February 4, 2021 3:49:37 PM
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org>rg>; draft-bestbar-teas-ns-packet@ietf.org <draft-bestbar-teas-ns-packet@ietf.org>rg>; TEAS WG <teas@ietf.org>
Subject: Re: [Teas] FW: New Version Notification for draft-bestbar-teas-ns-packet-01.txt

Gyan, Hi!

Thanks for taking the time to review the document. Please see inline for responses (prefixed VPB).

Regards,
-Pavan (as a co-author)

On Wed, Feb 3, 2021 at 8:14 PM Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> wrote:


Dear authors

I reviewed the draft and have some comments.

I noticed the draft  name and throughout the document it mentions Network Slice in IP/MPLS networks and wonder if it would be more appropriate to say network slice in SR/MPLS networks.  As NS involves traffic steering either RSVP-TE or SR steering my thoughts are it would be appropriate

[VPB] I’m not sure if I understood the comment. As you are aware, Segment Routing can be instantiated on MPLS or IPv6 dataplanes. The solution proposed in draft-bestbar-teas-ns-packet is intended for realizing network slicing in IP(v4/v6) / MPLS networks. The proposed solution works with any type of path control technology (e.g.RSVP-TE paths, SR paths, FlexAlgo paths). If you are interested in how the proposed solution works in SR deployments, please refer to draft-bestbar-spring-scalable-ns.


This drafts main focus it seems is an example of NS using QOS CS selector marking Differential service to be used for network slicing.


[VPB] Not really. The focus in this document is on the Slice Policy construct which includes rules that control the following slice aggregate attributes:
- Data plane policies (Slice Selectors, QOS profiles)
- Control plane policies (Guaranteed BW, Reservation priorities)
- Topology membership policies (Customized/Pre-defined)

There are 3 types of Slice Policy Modes depending on how/where the shared network resources are partitioned –
(1) Data Plane Slice Policy Mode
(2) Control Plane Slice Policy Mode
(3) Data and Control Plane Slice Policy Mode

In modes (1) and (3), a Slice Selector (SS) is carried in the packet to identify the slice aggregate and apply specific forwarding treatment (scheduling treatment and drop probability). But this is not needed in mode (2).

In my mind QOS is completely orthogonal to the concept of network slicing.  QOS involves shared resources and traffic classification and scheduling based on shared pipe resources which is completely orthogonal to network slicing which is a cross section of underlying resources involving a degree of isolation during provisioning to meet a customer  SLA.  QOS has been around for a long time and the big downside to QOS is that it is independent of underlying network resources.

When QOS PHB scheduling occurs based on CS AF or EF selector, packet are marked at the edge of trust boundary and PHB hop by hop scheduled matching dscp value providing bandwidth guarantees for profile traffic at or below the scheduling bandwidth which is based on the shared physical link.



[VPB] As noted above, it is certainly possible for a network slicing solution to be put together without requiring a specific per-hop-behavior to be applied on packets belonging to a slice aggregate (we refer to this as “Control Plane Slice Policy Mode” - Section 4.2 of draft-bestbar-teas-ns-packet-01). However, there are cases where the Slice service requires strict QOS guarantees and differentiation from other traffic – this is where the Data Plane Slice Policy Mode comes into play.

Kind Regards

Gyan


On Tue, Dec 22, 2020 at 1:59 PM Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote:

Hi WG,



We have published a new revision of this draft (just in time for your holidays reading).

The changes include:

  *   additional co-authors have joined
  *   introduction of new terms “slice policy” and “slice aggregate”
  *   editorial nits to align with new terms introduced



As usual, reviews and comments are welcome.



Regards,

Tarek (on behalf of co-authors)





On 12/22/20, 1:42 PM, "internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>" <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> wrote:



    [External Email. Be cautious of content]





    A new version of I-D, draft-bestbar-teas-ns-packet-01.txt

    has been successfully submitted by Tarek Saad and posted to the

    IETF repository.



    Name:           draft-bestbar-teas-ns-packet

    Revision:       01

    Title:          Realizing Network Slices in IP/MPLS Networks

    Document date:  2020-12-22

    Group:          Individual Submission

    Pages:          27

    URL:            https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bestbar-teas-ns-packet-01.txt__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPzvuhQQRw$

    Status:         https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bestbar-teas-ns-packet/__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPwWnIEvoQ$

    Htmlized:       https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPxBddbTdg$

    Htmlized:       https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bestbar-teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPznNKoLDg$

    Diff:           https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-bestbar-teas-ns-packet-01__;!!NEt6yMaO-gk!UopixISsH-6laFtUNIg5vIaLsXzFthS8C65TCDCRk-5ayO6AAa-8IPzsN9oeaw$



    Abstract:

       Network slicing provides the ability to partition a physical network

       into multiple logical networks of varying sizes, structures, and

       functions so that each slice can be dedicated to specific services or

       customers.  Network slices need to operate in parallel while

       providing slice elasticity in terms of network resource allocation.

       The Differentiated Service (Diffserv) model allows for carrying

       multiple services on top of a single physical network by relying on

       compliant nodes to apply specific forwarding treatment (scheduling

       and drop policy) on to packets that carry the respective Diffserv

       code point.  This document proposes a solution based on the Diffserv

       model to realize network slicing in IP/MPLS networks.









    Please note that it may take a couple of minutes from the time of submission

    until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.



    The IETF Secretariat






Juniper Business Use Only

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

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

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