Re: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Mon, 25 May 2020 12:12 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EAF3A0A7E; Mon, 25 May 2020 05:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.59
X-Spam-Level:
X-Spam-Status: No, score=-1.59 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, HTML_MESSAGE=0.001, PDS_BTC_ID=0.5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecitele.com header.b=TqCZ/Df9; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com header.b=om7cxyEk
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 yJ69I54vA-_l; Mon, 25 May 2020 05:12:26 -0700 (PDT)
Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 170CA3A0A79; Mon, 25 May 2020 05:12:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecitele.com; s=eciselector10072019; t=1590408742; i=@ecitele.com; bh=MluLJH64PCT552fsuguzRTAZlzcWiNZDE1NcX+K/g9Y=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=TqCZ/Df9/WEi7ZvANXTo3Ye2SDUOhm4EbyDnwETbUYmzSldx1MalDQ1xhX09XEt3D jXVyAf+P4glwVwMCfbiGzw0c5PBY6G1yvyrFddzV3Cuo1mT0LDSPXVvYTNX60QWy+H 7NTd9dCErXPUJC0koQFpSNuEPxCvmisBFKzocAvY=
Received: from [100.113.0.171] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-a.eu-central-1.aws.symcld.net id F5/D0-40388-526BBCE5; Mon, 25 May 2020 12:12:21 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1VTf0wTZxjud3dtT0Lh2iJ8MnSzynQb7UD2o8Y tLNmSNU5EHXMRlXmVk3ZrC7YlgwVNmaiRH0sDHQsgv0rJHKNrQalOZGyEgFAjDMZCYGMymoyC OEpqCmOM3fXEuX+ePO/7vM/3fO/lOxwVOfjROJVrpPQ6UiPhhWCi+RKndLvLnR6/2Pmy3F43D uTmMRMi9w3cR+RDdrHc39WDyfuGVsAbPEXtUANPUdgzz1XYbMuI4q4lAA5gaVy1TpmVe4KrGv 15Bs3uvYHmNjaZUBP4pQ0tAiE4IJpQWO9y8tiiF4NXF50IW1wF8HZfGZ8pMMKOQteX5UGPiLA isG+wmscWUwAuLF0HRWADziNeh21f/8pjeASxHVZ47XyGo8SnCHx4gcsYxEQngFXzt4MhEcR3 AFotvYB1vA8vW77nMhwjYqG9pwBhuIAgob/FBti4VhS2TFShjLCBNlz53BEcAkQkDAy0IGxcF Bz31AU5JAhouzWIsnwj9E7/w2XnSwGs7oxi+8/AxZFRjOWb4XBdMR2G03wbvDZznG0nQ7PvC8 DyODg9MvVoPBuOnivhs3wHLPTVcllrDCwc17PtLbC5dH08Bt4bux78cpDwoHByrR81gxernrg 1y3XQ3+DgVgXXF8L+Sg9WRR+LEs9Bx81H41uhpXiKz/Kd8PzlGv6T/XrAbwa7lXp1psqoJdUa aUJ8vDQhIVG6S7orMVFGfiIlZVSO9CSlM+pJWpWRHxtkhjztSU2GTEcZ2wD9/jJOI94bwGX/U 9YNNuGIZKPAV+5OF4UpszLyVKRB9YE+R0MZukEMjkug4J12WhPqqUwq95RaQ7/idRnioZIIwT ZGFhiySa1BnclKA0CNm701VhS/0F5L4/nZehoD5xpofLDcSOP9r2w0rgaxv5lBXxADQeypabK iIkyXpaOiowQFTADBBKhydI/j1/+jYbA5WiwAHA5HFJpN6bVq4//1WRCFA4lYsHiNPiVUrTM+ vuUsvQBCLzDiGGAWMJL/SdEm5Mwx5R4CuLn+LQdHbt49fXjOVZDz8FhJbLuqPUb50ns/5v+WW h4/YQlw6hb2djWmSSaPdqTXCis4M+8638JSyk7M9a14rJ9R1WBP0ptrmsOiHz4q8xvQjlcil5 6+yLk0d2bl1pI/bmmYc3xSm6HqLonsaFo68k1Sfkv47x5xR9Kd2NZKp7Wz9Nkr+YcehP1BxJ9 t9P9l8u4L0R51Cxfc5uT9qbFnX03xVCwXmt/eoRwThuTpwan9a3s/XC1uDb/jvNT11L36rsFD SVvDB1fdyQcv7vxW2Na77JxQaIw/xUx1h3lyDZWzZJHLNt0a9/dQyYGGF1JSN9Uc2Rf52m7xW nJEGinBDCoy4XlUbyD/BeDrDSTCBAAA
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-27.tower-228.messagelabs.com!1590408737!689060!1
X-Originating-IP: [18.237.140.176]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.50.1; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 31746 invoked from network); 25 May 2020 12:12:19 -0000
Received: from p01a.mail.dlp.protect.symantec.com (HELO mail.ds.dlp.protect.symantec.com) (18.237.140.176) by server-27.tower-228.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 25 May 2020 12:12:19 -0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S/TCiheovnu1v0Lz7jvr9p7jJrkcoYD7g8tcCWKFsfHfoVTAAL/RdCNTF4ZJof3U3OoAGC35t4lIsxWvjz6NK9laeIQ6D5lH/DMnwVvxX7d+bDXRHFbPd1slakeUZMZ8WbbkrTxffg0Bci/C7PoEIuy+XhwZgqpiScMuobxuRqBOhf7iycrFzM0HKMqN2NOCAo0U7fJ8Wy8kE6gBnZEpB8Gs4Pkc0l5Cch1OtnxV6b/8pqF0C6RWxMh0AY+ZIZkbC62r/l1Fy1eEyejcgVJrb5wyeXd7uClLaH5dw6x8up1cObne8HSawcAeSo4r+8fq6s+RazsqYQJflWTdi2zYgw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q0ZMyNd9bjCObVD+aCX7QMqMWME0kLE93U4w9a1PrrI=; b=moKp9Wn2EpBakdtDpt54OdgyTL2Z7O8sKHdutZwVpByFPDd7LSxzY8z8L+WfE8sBo7xF2xRd+/zqD6HRCRlZXX7Rif6eemAwLQVBE4VaTp1tQTwxLYzHEp7YKxW9ybYlZnar90v315Ol2Ec1h1QI53unz4CDFR/8Fz+3OYDKNRGaXt8bfM5TS0ebHaeBmvDOgRPR/EsNYn8MnDViJyH3laKEmGJXTAWQ5+sF65V00bYB9HA7C8IbpINGIytzDzWT0Q3bX389sUhPjjLR17rxdC8XA+hfluvahCYZ6syv/ZzLQ7e3T7nIvYJkZKx6ngI0BDPP/BXsrUwjS35uGo52UA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ecitele.com; dmarc=pass action=none header.from=ecitele.com; dkim=pass header.d=ecitele.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector2-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q0ZMyNd9bjCObVD+aCX7QMqMWME0kLE93U4w9a1PrrI=; b=om7cxyEkQuFo4A6NP2QXooRS+VmYlUk8IlfIoeyinn52hKhzoME9km6JwG4DGAx2Zj8PtjixFFdJw0k3zDCK8kvqofwnjj4tZrrjLkg4meK4I6hL+VwvF7NDdKUfkRi5vrVfLUhNkCwMfvyimI7xYdF7LesWRQ6PQ8ytr7/RAkM=
Received: from AM0PR0302MB3217.eurprd03.prod.outlook.com (2603:10a6:208:2::12) by AM0PR0302MB3283.eurprd03.prod.outlook.com (2603:10a6:208:12::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.27; Mon, 25 May 2020 12:12:15 +0000
Received: from AM0PR0302MB3217.eurprd03.prod.outlook.com ([fe80::b886:92c8:2695:493]) by AM0PR0302MB3217.eurprd03.prod.outlook.com ([fe80::b886:92c8:2695:493%7]) with mapi id 15.20.3021.027; Mon, 25 May 2020 12:12:15 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Mach Chen <mach.chen@huawei.com>
CC: "draft-dong-spring-sr-for-enhanced-vpn@ietf.org" <draft-dong-spring-sr-for-enhanced-vpn@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, qinfengwei <qinfengwei@chinamobile.com>, 'SPRING WG' <spring@ietf.org>
Thread-Topic: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management
Thread-Index: AQHWLxwZUkwzaMUzqEiqJoCp4LvkAqiyQIrAgABTuYCABY0ugIAAChcAgABB74CAADhmsA==
Date: Mon, 25 May 2020 12:12:15 +0000
Message-ID: <AM0PR0302MB32177217AF43D3A2A6BB670A9DB30@AM0PR0302MB3217.eurprd03.prod.outlook.com>
References: <6c9e9271a5e64e2faa2f373d871abaa1@huawei.com> <032901d62f1a$1f88c300$5e9a4900$@com> <170e5214-69ff-6d59-afdb-ee18c2a9483f@joelhalpern.com> <faae33acd85c4426acd5a374d40946c7@huawei.com> <9d4042b5-d226-77b7-7225-b510e28ca1b2@joelhalpern.com> <bfab248f87fa4da38a66525e3c71ba45@huawei.com> <28b5cdff-3456-73e3-ea67-e6cf76a43b64@joelhalpern.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE297B917C8@dggeml510-mbs.china.huawei.com>
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE297B917C8@dggeml510-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [109.66.1.133]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 9f3129b7-ae61-4eda-75f5-08d800a4dd06
x-ms-traffictypediagnostic: AM0PR0302MB3283:
x-microsoft-antispam-prvs: <AM0PR0302MB32836FE6C788129B83BC143A9DB30@AM0PR0302MB3283.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0414DF926F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jDbqmQ0ilgS+KRTbJA9tpCKfumiMb//htzjybil2qn5F8ZisxfuWalHp7AhoAiykp3/C/N+NvC994yf5grAMVSCTOfgNwv/+LUTdymvSXQaCa/aMnh2dTHIDMk/mpMLlCkdb2QAVgGGY+oDa4mkE2G311IPD368dA9J3FMjQJV1TfEWGRO08yCOiRR37MEH+Vzo60o06kcv1fhRPqT+hVHsv9LugPcbyodxDvaWCfblSNzxmy+OXpzpd0uTsm4rPOZGfqtSXmDD05Oql5Am/Xbu23AqVt4Kh09IuVUvoUVruePSoDWWd9OB/7E7PhPhiJTeWES8WVnloEeP1rqiyz8YVCty1iJdVEbgM7ieuRXRQ5y693oyN9mcsON89ebRrRiN9QtIw6Dy2+Pcl0rRxC3jgHKdW2pKdW60NUfAN/ZgrixI4LCuFRWxdmhbIVYal
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0302MB3217.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(376002)(396003)(136003)(39860400002)(2906002)(86362001)(71200400001)(30864003)(5660300002)(4326008)(66476007)(66946007)(186003)(83080400001)(66446008)(64756008)(53546011)(6506007)(76116006)(7696005)(55016002)(66556008)(26005)(478600001)(316002)(224303003)(54906003)(6916009)(966005)(9686003)(8936002)(52536014)(33656002)(166002)(160933001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 7HyoB32QVVWxqDkYyoFI4CncbeEnY5LsrlzNGOXJj4UpuiFdDz0Cvvc7wVmbJcRP7UTYpKrnMZ1wePCRijnQxQ0hEGWsGThvuhlafGYusIRn0jo2by6snFw0ICABp9GBjzu5ElACPtVThjEih09gkxAkvehCHkDmTWGrykv3ZOQn2BnrP1WPT5Yqq8uDIvQiF//NqQj4BnGyLz07Yyt09xVrHSYIAub7qfjSLKiHIhGg49L34/pcPRtcU/FU0CLx3TnhQXxtDsrkINvRikmvyeKjNIl2RtsqunaUKtW+Vp5imKw9CYBb/uxnCiJ0anRVLLw0qbTDrdBRkEOpXE8JIxqCLTbm2+YwMLAEbKFuanTeJDc1EMtFytKDPeo3EkLF63roBla7Fw+y1Id15RAKltz2BuEGDc1zVwISkQkW1JdR3BBf+byE+oKNBlSuO5NVoHioG0SyeRuV+qJo6AKdlqxFfoOxXjXvFqoyHN58lPw=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR0302MB32177217AF43D3A2A6BB670A9DB30AM0PR0302MB3217_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f3129b7-ae61-4eda-75f5-08d800a4dd06
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2020 12:12:15.5280 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: VmRy2Ioh8rrK479HAxOYhIWF18I+avIgAdOm+B5y9tOIlxIRgPR4KzCY1pzRqB5Q0sAWdF29cqGfnrw0aospSA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0302MB3283
X-CFilter-Loop: Reflected
X-DetectorID-Processed: d8d3a2b3-1594-4c39-92fb-b8312fe65a8a
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/hDDkbd8ULXQCh6hKiR075bp7cEI>
Subject: Re: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 May 2020 12:12:29 -0000

Mach and all,

From my POV saying that " With current SR ... there is no way for the devices to differentiate traffic over the same link or to the same destination, because the SID used by all the flows are the same" is inaccurate.



AFAIK it is perfectly possible to associate multiple Prefix-SIDs with the same destination prefix by associating them either with different topologies or with different algorithms (or even with a combination of these two parameters).



It is also possible to associate multiple Adj-SIDs (if you want to use them) with the same IGP adjacency by associating them with different topologies (but not with different algorithms).



Therefore it seems that the following recommendations from Section 2.1 of the draft are adequately addressed by the already defined SR-MPLS mechanisms:


   For one IGP link, multiple Adj-SIDs SHOULD be allocated, each of
   which is associated with a virtual network it participates, and MAY
   represent a subset of link resources

...

   Similarly, for one IGP node, multiple prefix-SIDs SHOULD be

   allocated, each of which is associated with a virtual network , and

   MAY represent a subset of the node resource



There may be valid reasons not to use these mechanisms for associating multiple SIDs with a given destination prefix or an IGP adjacency, but the draft does not mention any such reasons.



I defer to others to decide whether existing SRv6 mechanisms are sufficient for addressing similar requirements in Section 2.2 of the draft.



I also wonder whether draft-dong is a valid candidate for the Standards Track document since it does not define any specific protocol elements.  My gut feeling is that it could be a better fit for an Informational document.



Regards,

Sasha



Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com



-----Original Message-----
From: spring <spring-bounces@ietf.org> On Behalf Of Mach Chen
Sent: Monday, May 25, 2020 10:27 AM
To: Joel M. Halpern <jmh@joelhalpern.com>; Dongjie (Jimmy) <jie.dong@huawei.com>; qinfengwei <qinfengwei@chinamobile.com>; 'SPRING WG' <spring@ietf.org>
Cc: draft-dong-spring-sr-for-enhanced-vpn@ietf.org
Subject: Re: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management



Hi,



Is the "resource allocation" performed only on the controller? If so, sounds like a virtual resource reservation, or somehow it is more accurate to call it resource planning. In this case, the interoperability issues may not be the most concerns. The problem is how to guarantee the resource reservation on the data plane, how to prevent resource reserved for one application from using by another application.



With current SR, operator can do resource and traffic planning on controller, while there is no way for the devices to differentiate traffic over the same link or to the same destination, because the SID used by all the flows are the same. Thus devices cannot perform resource reservation for specific customer or service.



Best regards,

Mach



> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Joel M.

> Halpern

> Sent: Monday, May 25, 2020 11:31 AM

> To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; qinfengwei

> <qinfengwei@chinamobile.com<mailto:qinfengwei@chinamobile.com>>; 'SPRING WG' <spring@ietf.org<mailto:spring@ietf.org>>

> Cc: draft-dong-spring-sr-for-enhanced-vpn@ietf.org<mailto:draft-dong-spring-sr-for-enhanced-vpn@ietf.org>

> Subject: Re: [spring] 答复: Progressing

> draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource

> management

>

> No, there probably is no IETF reference.  The techniques I can think

> of do not have interoperability issues, and therefore are not IETF

> standards. They are just operations on a controller, where the

> controller manages resource allocations.  These were discussed in

> slide presentations in the early work on SR.

>

> And I am sure there are other ways that I do not know of.

>

> Yours,

> Joel

>

> On 5/24/2020 10:54 PM, Dongjie (Jimmy) wrote:

> > Hi Joel,

> >

> > Could you provide some reference in IETF to the "existing ways to do

> resource reservation with SR" you mentioned?

> >

> > Regarding the term isolation, my suggestion is to keep that generic

> discussion in TEAS. In the context of this draft, as described in the

> draft and mails, the meaning is "allocating dedicated network

> resources", i.e. resource isolation,  the description could be clarified further.

> >

> > Best regards,

> > Jie

> >

> >> -----Original Message-----

> >> From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com]

> >> Sent: Thursday, May 21, 2020 10:08 PM

> >> To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; qinfengwei

> >> <qinfengwei@chinamobile.com<mailto:qinfengwei@chinamobile.com>>; 'SPRING WG' <spring@ietf.org<mailto:spring@ietf.org>>

> >> Cc: draft-dong-spring-sr-for-enhanced-vpn@ietf.org<mailto:draft-dong-spring-sr-for-enhanced-vpn@ietf.org>

> >> Subject: Re: [spring] 答复: Progressing

> >> draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource

> >> management

> >>

> >> Part of my concern is that the document claims that this technique

> >> is necessary to use resource reservation with segment routing.

> >> Given that we know there are existing ways people do use resource

> >> reservation with SR, it is not necessary.

> >>

> >> The term "isolation" has been extensively debated in the traffic

> >> engineering working group, and the proponents have not been able to

> >> make a clear case for it.

> >>

> >> Yours,

> >> Joel

> >>

> >> On 5/21/2020 9:07 AM, Dongjie (Jimmy) wrote:

> >>> Hi Joel,

> >>>

> >>> Thanks for your comment.

> >>>

> >>> In this document, isolation means resource isolation, more

> >>> specifically, a

> >> set of dedicated network resources are allocated on a group of

> >> network nodes and links, and SR SIDs are used to represent the

> >> allocated network resources. As mentioned by Aijun, this is

> >> described in section 5, it could be clarified earlier in the draft if needed.

> >>>

> >>> As for your statement regarding diffserv, I agree it has been

> >>> widely used in

> >> network thanks to its simplicity and scalability. Whether it can

> >> address all services needs may be questionable. In IETF there have

> >> been many efforts to meet specific service requirements by

> >> reserving network resources, such as RSVP-TE, Detnet, etc. This

> >> draft aims to

> enhance SR with such capability.

> >>>

> >>> Best regards,

> >>> Jie

> >>>

> >>>> -----Original Message-----

> >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]

> >>>> Sent: Thursday, May 21, 2020 11:01 AM

> >>>> To: qinfengwei <qinfengwei@chinamobile.com<mailto:qinfengwei@chinamobile.com>>; Dongjie (Jimmy)

> >>>> <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; 'SPRING WG' <spring@ietf.org<mailto:spring@ietf.org>>

> >>>> Cc: draft-dong-spring-sr-for-enhanced-vpn@ietf.org<mailto:draft-dong-spring-sr-for-enhanced-vpn@ietf.org>

> >>>> Subject: Re: [spring] 答复: Progressing

> >>>> draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource

> >>>> management

> >>>>

> >>>> This email (and the underlying document) asserts a need for "isolation"

> >>>> without defining isolation, and without recognizing that the

> >>>> service needs can be met by existing packet technologies.

> >>>>

> >>>> The document also asserts that resource management requires

> >>>> packet based resource reservation.  We have significant evidence

> >>>> that diffserv treatment coupled with central (PCE or equivalent)

> >>>> resource management can address these needs.

> >>>>

> >>>> At the very least, the discussion of isolation should be removed

> >>>> from the document before it is evaluated for adoption.

> >>>>

> >>>> Yours,

> >>>> Joel

> >>>>

> >>>> On 5/20/2020 10:47 PM, qinfengwei wrote:

> >>>>> Hi all,

> >>>>>

> >>>>> At present, 5G applications have been widely developed,

> >>>>> recently, many enterprises require dedicated network resources

> >>>>> to achieve isolation from other services in the network, such as

> >>>>> southern power grid, Migu live video and Tencent cloud games.

> >>>>> This document provides the mechanism to enhance SR with resource

> >>>>> identification capability. This is an important feature to meet

> >>>>> different customer’s requirement in our network. Thus we believe

> >>>>> it is a generic and useful enhancement to SR, and hope it could

> >>>>> move forward

> >> quickly in the WG.

> >>>>>

> >>>>> Thanks,

> >>>>>

> >>>>> Fengwei Qin

> >>>>>

> >>>>> *发件人:*spring [mailto:spring-bounces@ietf.org] *代表 *Dongjie

> >>>> (Jimmy)

> >>>>> *发送时间:*2020年5月19日18:38

> >>>>> *收件人:*SPRING WG

> >>>>> *抄送:*draft-dong-spring-sr-for-enhanced-vpn@ietf.org

> >>>>> *主题:*[spring] Progressing draft-dong-spring-sr-for-enhanced-vpn

> >>>>> to enable SR with resource management

> >>>>>

> >>>>> Hi all,

> >>>>>

> >>>>> The latest version of draft-dong-spring-sr-for-enhanced-vpn was

> >>>>> uploaded in March, which describes a generic enhancement to SR

> >>>>> to support resource representation and identification, by

> >>>>> introducing the resource semantics to SR SIDs. With such

> >>>>> enhancement, SR could be used not only for explicit path

> >>>>> steering, but could also be used to build resource guaranteed

> >>>>> paths or virtual networks. Such SR based resource guaranteed

> >>>>> paths or virtual networks can be used as the underlay to support

> >>>>> different VPN services. The mechanism introduced in this

> >>>>> document is complementary to the existing SR functionalities, and helps to complete the tool set of segment routing.

> >>>>>

> >>>>> Based on the discussion on mail list and the presentations on

> >>>>> previous IETF meetings, this draft has been revised several

> >>>>> times, all the comments received so far has been resolved and

> >>>>> reflected in the current version. To move forward, the authors

> >>>>> would like to know if there are further comments on this

> >>>>> document, and people’s opinion on whether it is in the right direction.

> >>>>>

> >>>>> Comments and feedbacks are welcome.

> >>>>>

> >>>>> Best regards,

> >>>>>

> >>>>> Jie

> >>>>>

> >>>>>

> >>>>> _______________________________________________

> >>>>> spring mailing list

> >>>>> spring@ietf.org<mailto:spring@ietf.org>

> >>>>> https://clicktime.symantec.com/3Vi2XF9rXtn95ip934LJk1v6H2?u=http

> >>>>> s%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

> >>>>>

> > _______________________________________________

> > spring mailing list

> > spring@ietf.org<mailto:spring@ietf.org>

> > https://clicktime.symantec.com/3Vi2XF9rXtn95ip934LJk1v6H2?u=https%3A

> > %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

> >

>

> _______________________________________________

> spring mailing list

> spring@ietf.org<mailto:spring@ietf.org>

> https://clicktime.symantec.com/3Vi2XF9rXtn95ip934LJk1v6H2?u=https%3A%2<https://clicktime.symantec.com/3Vi2XF9rXtn95ip934LJk1v6H2?u=https%3A%252>

> F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

_______________________________________________

spring mailing list

spring@ietf.org<mailto:spring@ietf.org>

https://clicktime.symantec.com/3Vi2XF9rXtn95ip934LJk1v6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________