Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Peter Psenak <ppsenak@cisco.com> Fri, 14 May 2021 09:12 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78F63A2A55; Fri, 14 May 2021 02:12:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 GWJ9uydFq-dX; Fri, 14 May 2021 02:12:14 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998163A2A42; Fri, 14 May 2021 02:12:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4175; q=dns/txt; s=iport; t=1620983533; x=1622193133; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Cub0uRbSTKWnA0tD9yxc2KVKVxlBJPevXjD15vSGCQU=; b=To2ajp8jhx+0s2Ts/VQNWPAhSJMQTPLzfE8NVj9kcFcCvnocikiUmKUY nOhDIjoBQQcPQt3dMfhXK2FIb2RDZSJxbSGqc+auQcxzwn7biA7X/teLh vNmUhPiM+RDhwJna0hx2JQQ/g9MAjdUG7FSH6/cKlFt9tv7GrE/5oLCiN s=;
X-IPAS-Result: =?us-ascii?q?A0C1AQDJPZ5glxbLJq1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?VeDIlYBJxIxhEeJBIhSLQOdDAsBAQEPNQwEAQGETwKBdSY4EwIEAQEBAQMCA?= =?us-ascii?q?wEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBAWiFIwEsDYZEAQEBAwEdBg8BBUEQC?= =?us-ascii?q?xECAgEBAQICHwQDAgJGCQgGAQwGAgEBgm0BgmYhD6c8eoEygQGDXkFEg2OBR?= =?us-ascii?q?IEQKo1jQ4FJRIEVJ4F7US8+gmECA4R0gmMEgkAGASJBBDIhCUcrClgBKrwhg?= =?us-ascii?q?yCDSoY3kzUFCQUjg1mLEoVzLZAuhlWNUgyBAowGmCSBayGBWzMaCBsVO4JpC?= =?us-ascii?q?UcZDod/S4VuHoYPE4IrhUs/Ay84AgYBCQEBAwmNEAEB?=
IronPort-HdrOrdr: A9a23:846bgqMTFSFTO8BcTvCjsMiBIKoaSvp037Dk7SxMoG9uA6ulfq eV7ZImPH7P+VIssR4b+exoVJPvfZqYz+8R3WBzB8bBYOCFggqVxehZhOOI/9SjIULDH4Vmv5 uIHZISNDS9NykYsS4/izPIa+rJB7K8gdmVuds=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,299,1613433600"; d="scan'208";a="36007535"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 May 2021 09:12:09 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id 14E9C89v020648; Fri, 14 May 2021 09:12:08 GMT
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Cc: "draft-hegde-lsr-flex-algo-bw-con@ietf.org" <draft-hegde-lsr-flex-algo-bw-con@ietf.org>
References: <0BAE6DBA-04A3-4A3A-A1E3-14EFAA0FBE68@cisco.com> <6ba087997bc1433babc8f3c00b7998ee@huawei.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <22f52de5-37ac-b5a6-d014-0606b0fc6adc@cisco.com>
Date: Fri, 14 May 2021 11:12:08 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <6ba087997bc1433babc8f3c00b7998ee@huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.52, ams-ppsenak-nitro3.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/mM3wvL_s2iX_ObbZ1vrdfNabVfc>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 May 2021 09:12:27 -0000

Hi Jie,

please see the response for one of your questions inline:

On 14/05/2021 09:52, Dongjie (Jimmy) wrote:
> Hi authors,
> 
> I’ve read the latest version of this document and have the following 
> comments:
> 
> 1.Is the generic metric type applicable to applications other than 
> Flex-Algo? If so, it is better to make this clear in the document, or 
> perhaps it may be defined separately from the Flex-Algo specific extensions?
> 
> 2.The “Exclude Minimum Bandwidth” constraint is compared with the 
> maximum link bandwidth to exclude the links from the computation, it 
> would be helpful if there is some analysis about how much this can help 
> in traffic engineering, such as to reduce the congestion or improve the 
> link utilization. One simple example is, if multiple Flex-Algos use this 
> constraint to exclude the same set of links, this may increase the 
> possibility of congestion on the rest of the links?
> 
> Perhaps a more general question is, what would be the benefit of 
> introducing bandwidth attribute into Flex-Algo based distributed path 
> computation?  It is known that bandwidth can be used in centralized 
> computation for efficient path placement and resource management, can 
> distributed computation with bandwidth constraint achieve the same, or 
> is there some advantages compared with centralized computation?
> 
> 3.With the automatic metric calculation, it could introduce per 
> Flex-Algo link metric value, while the existing Flex-Algo only refers to 
> the metric of the link via metric type. Is this the expected behavior? 
> Will it be further extended to make other link attributes flex-algo 
> specific?

we need to distinguish between:

a) flex-algo application specific metric (applies to all flex-algos)
b) flex-algo X specific metric

(a) already exists in the form of the ASLA advertisement for delay and 
TE-metric. Bandwidth metric will be no different.

(b) there has been no such thing as flex-algo X specific 
metric/attribute defined so far. And we are not defining it in this 
draft either. The draft defines sub-TLVs for automatic bandwidth metric 
calculation. It is the winning FAD for the Flex-Algorithm X that 
specifies whether the automatic bandwidth metric calculation is done or 
not and it would be rather complicated (certainly possible) to have the 
parameters for such calculation being advertised outside of the FAD.

You are right these being part of the FAD may result in the calculated 
bandwidth metric being different for each flex-algo on the same link. 
The intention was NOT to have the different per algo bandwidth metric 
value, rather it was the convenience of reusing the FAD that was the 
motivation for the existing encoding.

So to answer your question, we do NOT intend to make any link attributes 
per flex-algo number.

thanks,
Peter




> 
> 4.In the reference bandwidth method, the draft says it simplifies the 
> management in case the reference bandwidth needs to be changed. Since 
> the reference bandwidth applies to the metric calculation of all the 
> links in the flex-algo with the same proportion, it seems the change of 
> the reference bandwidth will not impact the result of the path 
> computation in the flex-algo. In which case the reference bandwidth need 
> to be changed?
> 
> Best regards,
> 
> Jie
> 
> *From:*Lsr [mailto:lsr-bounces@ietf.org] *On Behalf Of *Acee Lindem (acee)
> *Sent:* Thursday, May 13, 2021 5:09 AM
> *To:* lsr@ietf.org
> *Cc:* draft-hegde-lsr-flex-algo-bw-con@ietf.org
> *Subject:* [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: 
> Bandwidth, Delay, Metrics and Constraints" - 
> draft-hegde-lsr-flex-algo-bw-con-02
> 
> Esteemed Members of the LSR WG,
> 
> This begins a 2 week WG adoption call for the following draft:
> 
> https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/
> 
> Please indicate your support or objection by May 27^th , 2021.
> 
> Authors, please respond to the list indicating whether you are aware of 
> any IPR that applies to this draft.
> 
> Thanks,
> 
> Chris and Acee
>