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

Gyan Mishra <hayabusagsm@gmail.com> Wed, 10 February 2021 01:58 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 20CFF3A119E; Tue, 9 Feb 2021 17:58:01 -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=unavailable 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 5zZ4h4JLTq82; Tue, 9 Feb 2021 17:57:58 -0800 (PST)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 086DB3A119A; Tue, 9 Feb 2021 17:57:58 -0800 (PST)
Received: by mail-pf1-x436.google.com with SMTP id w18so247604pfu.9; Tue, 09 Feb 2021 17:57:58 -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=XDuVcX36wS43tnubmEPR1lMr/Y7CamQgVWhcqFXQKNM=; b=g6RXfFDuGNFG3wMzY1iplhNzD+3W+MYj/cOHnRYK9p8bLrHPI9/UewynTfnJoz6+Mf ar03gIK3eVj2nfuuWMFHRYpB/3nX+oM4VRCw151G16p78MOBVVw/+42jg96/mGHpsO5J YRm9UQwhdK32syVXfoDhf0htB3fZhoKRCNQV0SOSHsJczs0gWIiWCgWnhAH5EUmt62Aw B0BB/J2P9MC5VZztDPf2twKxYzn64gR82HEbVtfAmnkeqIZrf90tHOHCcVS6qXuj5Z06 HOKP/XXbXAlSZ/Cy2mPcm45UwsWNTAe8A09C1bg+Qf13+MTZitn6iz+mB11bkbxKJRqW wQCw==
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=XDuVcX36wS43tnubmEPR1lMr/Y7CamQgVWhcqFXQKNM=; b=g2cITuS9K/n6zt9gMWUA0Q/ldUomaYReFl6oglCsAqwiGMaT0T+FfN3CnwSDbozc32 J8uRJG1bUUv/xO6xwxwJiIbxIUc99l7Pw2XKpM6Ry2dtDAdl6xuY/z38ds4pMSg1PrLJ TTUvZvk7soLnMH3RUl30KQ81rQvJ/RVpW37wSQMxMPmh4gTFdS9Q3GwrtEszrAVToaqF uyGc8yBSGIOSeGm4nGUDMmBRjDCdDWA/4AM8LgP4W+6v1I+VZcGNgtZJFGwqquQSQsuu nSszdOxsU+XO6Xv+G1v1B8Bdq+D7v2JfbDoiTThlVrt1NT3V/S0biY4cpVp/l4Pt8Z2n /ycg==
X-Gm-Message-State: AOAM533aUc913ltJAkI21HeTjX2AZXL1yuASdji1an3c7vQp6SPZeacD J5gbJqpz0qHwq75pRR+yt7QIW2t/z8x8V4zRiBs=
X-Google-Smtp-Source: ABdhPJwHJol4Kxrqf8Y7g49uUP0RYQXurBK5QYWisV3ZzRIJSreWqIjUSTOGvYIEAuHFjmhjKu4OnOP4zpcksY+5Vbc=
X-Received: by 2002:a63:1524:: with SMTP id v36mr811909pgl.383.1612922277287; Tue, 09 Feb 2021 17:57:57 -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> <CA+YzgTvrk7bXDzyChjy1HORbAdb6XWLhaWpZP=gTbXUhTs3+3Q@mail.gmail.com>
In-Reply-To: <CA+YzgTvrk7bXDzyChjy1HORbAdb6XWLhaWpZP=gTbXUhTs3+3Q@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 9 Feb 2021 20:57:46 -0500
Message-ID: <CABNhwV1UaLrwp+=VJ2JEXd2X6_AYj=UYN0uhqkazuGtNYu7-GQ@mail.gmail.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Cc: TEAS WG <teas@ietf.org>, Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org>, "draft-bestbar-teas-ns-packet@ietf.org" <draft-bestbar-teas-ns-packet@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000635c1005baf1bb33"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/H6sJWESDci8eTqMjNTr34HTI9TY>
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: Wed, 10 Feb 2021 01:58:01 -0000

Hi Pavan

I read the draft a few times to try to understand what the benefit of using
the QOS PHP CS would be for the instantiation or a network slice by the
slice controller.  In my mind I think you can accomplish the instantiation
of the network slices which can be done without the use of any concept of a
slice selector control plane mode or data plane mode without slice selector
using CS.

See draft below of how the network slice can be provisioned using BGP-LS.

https://datatracker.ietf.org/doc/draft-drake-bess-enhanced-vpn/


I think I have a little better understanding of leveraging the QOS diffserv
model CS using a Network Slice controller concept of a slice selector using
QOS CS selector packet marking as means of mapping overlay VPN or
aggregation of VPNs the same SLA called an aggregate slice  to underlay
resources slice  with some degree of hard isolation.


I think the disconnect I am having is the use of QOS DSCP PHB scheduling
that exists for customer flows.  So let’s say an operator has 10 different
QOS service models that provisions to its customers Gold, Bronze, Silver
etc and each one has different discrete CS AF or EF that are voice or video
centric or data centric or a mix.  So now the customer packets on ingress
get mapped to the QOS IP SLAs provisioned.  What does seem to be a gap is
in the use of DSCP for slice selector is that a customer may have many
markings on their packet that map to a particular provider class of service
offering which will still be made up of up to 8 classes.  So how do you
know what slice selector to use.  In the framework of RG RAN and core there
may still be multiple classes for the 3GPP user plane traffic.  So how does
that mapping work as you may have multiple CS values and corresponding
queues which all have different forwarding treatment and bandwidth in
profile requirements.  So is all traffic for a network slice mapped to a
single slice selector but then how is that slice selector determined is the
problem if you have multiple classes CS values which is always the case.
I don’t think the data plane mode is valid since it used CS which is in the
customer payload and the control plane mode how do you determine what slice
selector to use when their are multiple CS values which as I said is common
for any operator SLA given to a customer.

Another point I want to make is that with MPLS the payload had the customer
packet inner encapsulation or on SR case SR-MPLS or SRv6 it is the payload
that had the CS.  Throughout the operator core PHB the customer QOS marking
CS value is only seen at the ingress edge node and once the remark happens
DSCP to EXP to the customer SLA chosen for provisioning, within the core
the MPLS label stack topmost transport label contains EXP marking and not
CS markings.  This is true as well for IP based SRv6 as the identical
remark happens with SRv6 Ingres source node as happens with MPLS but not
you have 64 bit dscp values to play with versus the limitations of 8 EXP
bits.  So bottom line is that this draft is referring to the customer
packet CS marking which is not visible or acted on PHB within the core as
it sits in the payload.

So what seems to be described here is DS TE model RFC 4124 RDM and MAM
models mapping customer flows to RSVP TE tunnels.  So in this case the
overlay VPN is mapped to underlay DS TE tunnel based on IP SLA
requirements.  How is this draft provide a greater degree or improvement as
far as granularity of  achieving hard isolation of resources allocated
dedicated to the VPN or aggregate of VPNs with the same SLA.  The advantage
of DS TE over this draft is that at ingress the packets CS is mapped to EXP
which then the VPN is then mapped to discrete DS  TE tunnels.  Also the
core does not have to be CS aware and their is no concept of CS as that is
within the customer packet that is preserved end to end untouched.


Responses in-line

Thank you

Gyan



On Thu, Feb 4, 2021 at 3:49 PM Vishnu Pavan Beeram <vishnupavan@gmail.com>
wrote:

> 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.
>
>

Gyan> Understood.  To be more clear my suggestion is to state SRv6 as IPv6
data plane although it used by SRv6 it can be used for global table routing
where VPN overlay does not exist.  Similarly MPLS is vague as it can be
used for LDPv4 LDPv6 and do to be more clear it is better to specify
RSVP-TE clearly as the topmost label or SR-MPLS which reuses MPLS data
plane using SR-TE binding sid for ERO path instantiation.


>> 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).
>

Gyan> Understood.  See my comments at the top of this reply.

>
> 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.
>
>

Gyan> Understood.  See my comments at the top of my reply.

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
>> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
>> Spring, MD
>>
>> _______________________________________________
>> 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