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

Gyan Mishra <hayabusagsm@gmail.com> Thu, 04 February 2021 02:14 UTC

Return-Path: <hayabusagsm@gmail.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 CC98A3A10F0; Wed, 3 Feb 2021 18:14:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1Z_TrQKorU3g; Wed, 3 Feb 2021 18:14:34 -0800 (PST)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 999663A10E9; Wed, 3 Feb 2021 18:14:34 -0800 (PST)
Received: by mail-pl1-x629.google.com with SMTP id s15so912212plr.9; Wed, 03 Feb 2021 18:14:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QKpo+3hGx07XOt8q1DLNM1BhEUBpN0lPVKEdDlN64Bg=; b=Jxfl6+k68+v0yRw5urWJruCZmeeRizYAtCgSwkcRkkFZnJKyEl4kGt36EUD604ttu+ q21FjJcBJ+HriidPSTwnCzzaC1MQQrzbhTbUnIp6Tm13aA1L6m68ksLyyEGT2+bQ2zMO Z9yzlk6Sw73RooSfC0558EGUrIi72I4E0WCBSYFUbr0+F/YSGQc4jM2nGyyLUAX3yx6Q 7TOgxEms2L4i7haKcg2w7jnrKe7lvbdXaDxhh6tPUN/9cm/SnyBzhA+MNsqryCENW5DM wkUF/7vE5qnk2jVXOBlZ93hTC3uwTz+DnvjWdYY7059ahbLWUMNPFhdu4kThKTnZ15ky 2OzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QKpo+3hGx07XOt8q1DLNM1BhEUBpN0lPVKEdDlN64Bg=; b=W9gz+TS5wcSGNaRLTbHoTAQMA2Bdg6EWjsHyXzWruo3Ksqc/mCsPpNWOVQN+20L5/5 +sr1WxyZ1kXgw6KfzkEU/ViAYySOkEvqn+QXtBmV+gBNT7nulHWnr2yCkPMGMKQXL8Cl R6kesprrnikHXgPvg/edwdM4A8RvzPnHwPDs3EuCu8BH3oJKO3sxHs0TPxX9OKZJhWBO PqpBeUVKqFFxUgiovPNyamJSw1h8ysNN1jWkLctPGF3peEngayDn2KQ2pGN7I1s8sY6K ui5SsdeBKuNmBMlplFJDW5ifRa4MPCj13joer5/YNlya+wUWepODT1NucQmBgm3vjdEY mKvg==
X-Gm-Message-State: AOAM533uMvpx6yxgWfgjNsrge4+y9WREducLoNUYkNbwJF51Wz6rI1Oy LaXv9NEKnWG8LNFAkyCtGUzyqhkuIMdG/suV+DUdKB4htFuEGw==
X-Google-Smtp-Source: ABdhPJzqB86UH+sQQwrJb0np8ag9Ao6JtgS6XAQgh7NxrgJSzO/2qDCDbtSJKdMrfsuxb8RcfYoPIAP+31iBbSADEqA=
X-Received: by 2002:a17:90a:65c4:: with SMTP id i4mr5860156pjs.132.1612404874052; Wed, 03 Feb 2021 18:14:34 -0800 (PST)
MIME-Version: 1.0
References: <160866255058.12375.3624366295025144530@ietfa.amsl.com> <B5853097-0690-45E9-9123-6F74FBCC4F03@juniper.net>
In-Reply-To: <B5853097-0690-45E9-9123-6F74FBCC4F03@juniper.net>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 3 Feb 2021 21:14:23 -0500
Message-ID: <CABNhwV1u=iiK_2PQTKCquDbVwXanbTfB7U5GEzNRcgNY=iHhqQ@mail.gmail.com>
To: Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org>
Cc: TEAS WG <teas@ietf.org>, "draft-bestbar-teas-ns-packet@ietf.org" <draft-bestbar-teas-ns-packet@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c089a505ba794360"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/yuQV2W9e5fsS6uTTDvBif5sYRU8>
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: Thu, 04 Feb 2021 02:14:37 -0000

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

This drafts main focus it seems is an example of NS using QOS CS selector
marking Differential service to be used for network slicing.  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.


Kind Regards

Gyan


On Tue, Dec 22, 2020 at 1:59 PM Tarek Saad <tsaad=
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" <
> 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.
>
>
>
>     The IETF Secretariat
>
>
>
>
>
> Juniper Business Use Only
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD