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

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 25 May 2020 03:30 UTC

Return-Path: <jmh@joelhalpern.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 7E13D3A0A81; Sun, 24 May 2020 20:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 jzBo9SmVWtmp; Sun, 24 May 2020 20:30:51 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 72CEF3A0A80; Sun, 24 May 2020 20:30:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49VjKk6kHbz1nvMj; Sun, 24 May 2020 20:30:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1590377450; bh=nBmhnSp2rbXm1jzgUz+rkO9ZdCsILNNdLgXPAjmKOZc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Fa4Xlfyg8RNVA/miFT4A7ad1dFLrcL1AODb8wwJfhCSo1Kppv66xxq5RdtcNFzzEx NoCpjWEBbXWAkO8Qyic105QYmaeNSqWZ1eWXowbQd/YTFQbF2FsAEawc4pQPYECaxX BfHAuIqBBkIYCkILRUYyVCwThQt54ZbYBETMVUcw=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 49VjKh6FdDz1nv44; Sun, 24 May 2020 20:30:48 -0700 (PDT)
To: "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" <draft-dong-spring-sr-for-enhanced-vpn@ietf.org>
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>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <28b5cdff-3456-73e3-ea67-e6cf76a43b64@joelhalpern.com>
Date: Sun, 24 May 2020 23:30:46 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <bfab248f87fa4da38a66525e3c71ba45@huawei.com>
Content-Type: text/plain; charset="gbk"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/r7dLGsSj5-ndzkcjGv25pgBMIvQ>
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 03:30:54 -0000

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>; 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
>>
>> 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>; Dongjie (Jimmy)
>>>> <jie.dong@huawei.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
>>>>
>>>> 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
>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>