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

Vishnu Pavan Beeram <vishnupavan@gmail.com> Thu, 04 February 2021 20:49 UTC

Return-Path: <vishnupavan@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 8F9D83A17F3; Thu, 4 Feb 2021 12:49:52 -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 9FOlNQoGAsBD; Thu, 4 Feb 2021 12:49:50 -0800 (PST)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 42D723A17F1; Thu, 4 Feb 2021 12:49:50 -0800 (PST)
Received: by mail-il1-x136.google.com with SMTP id g7so3907875iln.2; Thu, 04 Feb 2021 12:49:49 -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=V3/yBCIl8HeZ7aGr4LFw7fjB+XMVHczvN9r6dkQG8Uc=; b=J8n61j1otJj4IT0p3ggy30h57nvaD30N4FnKjEMi6JNIAT5z14qJ4+WVPoSzpXzhu5 CccQeKr4XEKB0T/y1cVTYnOkDAmhkAte6oOQV7f6tWEkDbKL2gRd4kdP0oU3+a8QZ97e 6JCs42JsPtQUjheVOYAIAQJd6bRoYG6txDglLBfZxlmNo/qXYp34hubd5DFApZcDP5IL MXxbweBnx6mjGX/3acljLkoW3DT0od82+1Pqo9l3SH+Pe6ptzIDJ0YAALVUDcF+kMoXz Pi0pngHMCOoo6etahicU1grriM87ZilR20Wsb+zdYpQQQZzAEJO/K/SQBGw8xm27LpGT 1Jlw==
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=V3/yBCIl8HeZ7aGr4LFw7fjB+XMVHczvN9r6dkQG8Uc=; b=K+gp2W/kaYbp3Eh8h27dquEZlOxrxZelLn7lbVyLLlZCejp1peeiDMFlZ/3/DzbePy 6vYkXA0WFequ3/ua2JCkKTRsyzLcVfRbaOh15TKEFc/bf73+q74nBMOdvJWICQhRVu1O 7l8S8gMekpf3uSPt2dStzj+uNx/S9QTpS1cyY6IbcmtfTSBJMfCdjG8tDdvHaj+g1SMj fQeZ4f/UcTiwUVpi99mzmRTHpt600rEpxNgn6OEgLD8u4bZfLD3hXvWsu2ooXiwpNXyH dEawzE60zDNbpnbYb15Ikeux1K47NHrOdedovLB+mxCFKq9s6zRQFihsIm/7/JAn5Muk 3oGQ==
X-Gm-Message-State: AOAM533Qn0R7Rr3EUm95bFsQpJIM1TAgEvhSaRnRvsWgPRJp0h2xH088 8bvFtmN7a7USE7E8xffwbZrtPJg42axZ79sX1iQ=
X-Google-Smtp-Source: ABdhPJyI7ecMoOMiko9Q8jrUAQyIsyhuIGZnfRvLfkyuD3rCk4/VSPrXqL+4BFstpKpzYYL0M2ZMzFUxrg1FfQZ9DDc=
X-Received: by 2002:a92:b011:: with SMTP id x17mr853625ilh.179.1612471789091; Thu, 04 Feb 2021 12:49:49 -0800 (PST)
MIME-Version: 1.0
References: <160866255058.12375.3624366295025144530@ietfa.amsl.com> <B5853097-0690-45E9-9123-6F74FBCC4F03@juniper.net> <CABNhwV1u=iiK_2PQTKCquDbVwXanbTfB7U5GEzNRcgNY=iHhqQ@mail.gmail.com>
In-Reply-To: <CABNhwV1u=iiK_2PQTKCquDbVwXanbTfB7U5GEzNRcgNY=iHhqQ@mail.gmail.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Thu, 4 Feb 2021 14:49:37 -0600
Message-ID: <CA+YzgTvrk7bXDzyChjy1HORbAdb6XWLhaWpZP=gTbXUhTs3+3Q@mail.gmail.com>
To: 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>
Content-Type: multipart/alternative; boundary="0000000000003300a005ba88d8af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/0fuSSjRhZqYZyY5sJVHaDAiqkbQ>
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 20:49:53 -0000

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> 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> 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
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>