Re: [Teas] Comments on draft-bestbar-teas-ns-packet-00

Tarek Saad <> Sat, 21 November 2020 05:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78B323A12C2; Fri, 20 Nov 2020 21:35:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tOM_dJXzLnf7; Fri, 20 Nov 2020 21:35:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6817F3A12B2; Fri, 20 Nov 2020 21:35:20 -0800 (PST)
Received: by with SMTP id 92so7817163otd.5; Fri, 20 Nov 2020 21:35:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=jfI3xvsa1zINATyLKbxs+YElu0jMPX6ZXvrBMoa5myw=; b=rdY96+yVSafuZGkB3cNRFioVM7Q1p/o/DmblzT0rF+Xn5rb5fjFSNFhCOawB4yAUEg vl69jKyCoq16LValg6lYY7BU/uTDaw4idNmP/D3ASNWeEvm5RAjeAb/6B1VNEEOUdlUY 5D16ZJpHeOO+X/DPHcJugVQr2nj+SsdSqMS9SDcezktK5YfVHOFqq7UuuMAjMGojS2dh KJxFAH2/l5PBjKAvgEz3ECDtOjqZYw5KXy7x6nI0rRqCu3vAhp9WGNdD8+CvbMz2iU6X wVt9ncH5nljG6t5w7Ss7ikHcgfeuDzEkr7ePOwKk5+WEW+Gb7wUAWR0K+aI+cQbc/U5H ay8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=jfI3xvsa1zINATyLKbxs+YElu0jMPX6ZXvrBMoa5myw=; b=RbIauA7cH+b9VH3KVVq+tCdWp1qJwA0AJxCykUQGWSLWowQSBE1zI6cUJvGSu47Etu odGk9b0xdRhiGBXEPZlHMS4ogmIeFOSuwqXJfHXWdUgv2Cmi4FlKbvpd5nCnHSkRuuGG x1VxmdZC72xkXv6o1+NRZsLqiTq744ax5mIP8H8WYKbfLQzaj+ECYJMUXFkwMdPajIJn FbfH45LKL07JpBczB+R4f6ATBk6TDOIfCYNMaoNPKw+TFfsTHKVQ6ofYxU4QN2NQZiuu MLsv5p1TEB9DN4zbZErGzH1M0Lp6mieak4rk8Imoo2yQ4dMYRycTdnRwUd5Hwu6pO/25 A3KA==
X-Gm-Message-State: AOAM5303cixWdNUzcv5ZVoGf6un4paeaEVMw1auiGZ8msUT7ET6hzwM2 IBWkImOHVxg1BhwM8WuglgStP8MfzYtJuQ==
X-Google-Smtp-Source: ABdhPJyS013YZFWS3VwYQ3rpih06vEZaY7e6cXtIfeX0vK6b4HA0DRw1Z5t/ifnTEjlJCQgRiAmPNw==
X-Received: by 2002:a9d:754a:: with SMTP id b10mr16391282otl.140.1605936919246; Fri, 20 Nov 2020 21:35:19 -0800 (PST)
Received: from ([2603:1036:4:9e::5]) by with ESMTPSA id m81sm2996325oib.37.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2020 21:35:18 -0800 (PST)
From: Tarek Saad <>
To: "Dongjie (Jimmy)" <>, "" <>
CC: "" <>
Thread-Topic: [Teas] Comments on draft-bestbar-teas-ns-packet-00
Thread-Index: Ada4yFzQlsTL3WHCS6W4IaR+h6AiDQCRxtaJAJzmZBAAi2NO5Q==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Sat, 21 Nov 2020 05:35:16 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_DM5PR1901MB21505F46613F4708FF48A79BFCFE0DM5PR1901MB2150_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Teas] Comments on draft-bestbar-teas-ns-packet-00
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 21 Nov 2020 05:35:24 -0000

Thanks, Jie. Please see further response inline.

Hi Tarek,

Thanks a lot for your reply. Please see some further comments inline with [Jie]:

From: Teas [] On Behalf Of Tarek Saad
Sent: Sunday, November 15, 2020 1:24 PM
To: Dongjie (Jimmy) <<>>;<>
Subject: Re: [Teas] Comments on draft-bestbar-teas-ns-packet-00

Thanks Jie for your review and your comments. Please see inline for some responses from the authors.

From: Teas <<>> on behalf of "Dongjie (Jimmy)" <<>>
Date: Thursday, November 12, 2020 at 2:52 AM
To: "<>" <<>>
Cc: "<>" <<>>
Subject: [Teas] Comments on draft-bestbar-teas-ns-packet-00

Hi authors,

I’ve read draft-bestbar-teas-ns-packet-00, please find some review comments from my side:

To my understanding, the mechanism described in this document aligns with the VPN+ framework described in draft-ietf-teas-enhanced-vpn. More specifically, this document describes different approaches of reserving dedicated or shared network resources for logical (or virtual) networks to provide network slicing. It also describes the mechanisms to steer traffic on the specific network resources allocated for the network slices. Thus it would be reasonable to reference draft-ietf-teas-enhanced-vpn in this document.
[TS]: the draft proposes a solution on how shared network resource(s) can be allocated to different slice(s) – in control and/or data plane. This solution would be able to cater to enhanced VPN when a slice is mapped to 1 VPN. However, the solution the draft present covers other variant ranging from (M VPNs mapping to N slices). We can add some text highlighting how this solution can be used to realize an enhanced VPN service in a later version.

[Jie] From this description, it shows that the a consistent view about the relationship between the terms VPN, network slice and enhanced VPN is needed. There is some description about this in the introduction of draft-ietf-teas-enhanced-vpn, review and suggestion are welcome.

[TS]: We agree the terminology needs to be consistent with that produced by the network slicing design team, and we’ll make sure we’re aligned with it as it progresses.

Section 4 describes three approaches for resource partitioning. First please note that the list a), b) and c) is not in the same order as sections 4.1, 4.2 and 4.3. Then I’m a little confused with this classification. If my understanding is correct, The difference is whether the resource is reserved in data plane or not (i.e. hard or soft isolation).
[TS]: thanks, we will fix the list order to be in line with the TOC.

While no matter which approach is used, the resource reservation state needs to be maintained in control plane (either in a central controller or in the control plane of devices). And the resource sharing described in 4.2 between multiple slices within a group is also possible with the data plane based resource partitioning. Thus I’m not sure “data plane only” and “control plane only” are the appropriate terms here. How about using “data plane resource partitioning” and “control plane resource reservation” instead?

After reading section 4.3, my understanding is this subsection actually talks about two things of a network slice: resource reservation and topology customization. Then perhaps it should not be listed as the third approach for resource partitioning/reservation. The combination of the resource and topology attributes may be described in a separate section.
[TS] In the “Data Plane Network Resource Slicing” (Section 4.1) approach, there is no per-slice resource reservation state maintained in the control-plane. In fact, some path placement techniques would select the best path without consideration to the network state or utilization (e.g. IGP based path selection, SR flex-algo path, or LDP).. Those would map traffic on the best selected path (usually leveraging ECMP) but without any network state reservations. Section 4.1 covers enhancing those usecases to enable data-plane slicing along such paths. In the “Control Plane Network Resource Slicing” (Section 4.2) approach, the control-plane (be it on the devices or on some central controller) maintains per-slice resource reservation state. And this facilitates Slice-aware TE path placement. The approach discussed in Section 4.3 ties both of the approaches together.

[Jie] Thanks for your explanation. Then my understanding is with “data plane network resource slicing” in this document, path computation and selection is based on a common topology (constraints), which means the network slices need to share the same topology attribute. This presumption may be true for some of the slices, while it may be difficult to ensure that all the network slices have the same topology. Thus a more generic approach is to allow either topology sharing or customization between network slices, and the data plane resource can be either dedicated or shared. Then “data plane resource slicing” and “control plane slicing” in this document can be seen as the special cases.

[TS]: No, the proposed model is generic enough to allow a set of slices to share a topology, while another set of slices share a different topology.

In section 5.1, it mentions a network slice may be realized using a network slice service Layer, and a device/resource Layer. In management plane, this separation of functionality can be seen in the context of RFC 8309 by considering that the NBI described here is a customer service interface, which is mapped down to network and device configuration interfaces. The term network slice service layer aligns with the NS-DT documents that a network slice is a service provided to a consumer. Then one question is: can the device/resource layer also be called a network slice? Using the same term for both the service layer and the resource layer may cause ambiguity. Maybe it is better to provide a dedicated term for the resource layer in the network slice context? For example, in draft-ietf-teas-enhanced-vpn, the virtual underlay network is called a VTN.
[TS] The service definition of the “network slice” is outside the scope of this document and (as you are well aware) is discussed in detail in various other documents. The only assumption that this document makes is that there is some controller(s) that would translate this service layer intent to a network wide consistent slice per-hop definition that is provisioned on slice-capable nodes. The slice per-hop definition is required to enforce the proper per slice treatment onto slice traffic on each hop.

[Jie] I think we agree that in NS-DT the term “network slice” refers to the service layer. I understand the functions described in this document and its relationship with the network slice service layer, I’m just not sure whether the same term could be used for both the service layer and the resource layer, as they may have different characteristics and granularity.

[TS]: The “network slice service” used on the NBI is clearly different from the “network slice” used on the SBI for realization on a shared network. Our network slice per-hop definition includes the 4 key elements that are required to instantiate a network slice on a shared network: 1) Slice Selector, 2) Data-plane resources, 3) Control plane resources, and 4) the topology (refer to draft-bestbar-teas-yang-ns-phd for more details).


Section 5.2.1 describes two options for Slice data plane selector, and analyzed the scalability challenges with the first approach. This section is relevant to draft-dong-spring-sr-for-enhanced-vpn, which describes the mechanism of using different SR SIDs or SRv6 Locators to identify the nodes/links and the resources allocated to different VTNs. And the scalability considerations for VPN+ are described in draft-dong-teas-enhanced-vpn-vtn-scalability, which provides the scalability analysis and optimizations in both the control plane and the data plane. For IPv6 data plane, one approach to carry the VTN identifier in data packet is described in draft-dong-6man-enhanced-vpn-vtn-id. My understanding to this section is it may aim to cover the native IP and legacy MPLS cases? Anyway, some coordination between these drafts would be helpful.
TS] The primary motivation behind this document is to offer a solution that is agnostic to the path control technology used in the slicing domain and uses a model that caters to a variety of IP (including native IP and SRv6) and MPLS data-plane slice selectors to provide slice specific treatment on a given device. Operators can choose any specific slice selector that suits their deployment – section 5.2.1 provides the considerations for picking a suitable slice selector. And yes, always welcome to coordinate with relevant drafts.

[Jie] Understood. Look forward to the coordination with the data plane related drafts.

Section 6 provide some general considerations about routing protocol extensions. For this part you may refer to the VTN and VPN+ drafts in LSR and IDR WG, which provides the control plane solutions with different scalability and flexibility characteristics. Comments are always welcomed.

[TS] Ack, thanks. We will make sure that there is coordination with relevant drafts as we make progress on Slice-aware TE specific control plane enhancements.
Hope this helps.

[Jie] Good to know this, thanks.

Best regards,

Tarek (for the authors)

Hope this helps.

Best regards,