Re: [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo

Peter Psenak <ppsenak@cisco.com> Fri, 12 March 2021 11:40 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 BF8D83A18BC for <lsr@ietfa.amsl.com>; Fri, 12 Mar 2021 03:40:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.602
X-Spam-Level:
X-Spam-Status: No, score=-9.602 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_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ksFHQOFgO6SC for <lsr@ietfa.amsl.com>; Fri, 12 Mar 2021 03:40:50 -0800 (PST)
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 9B7833A18BE for <lsr@ietf.org>; Fri, 12 Mar 2021 03:40:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3686; q=dns/txt; s=iport; t=1615549249; x=1616758849; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=yuH56sq+W9WyBW+dCfnpdHBboJWhdjOCG1CDw/nyuSg=; b=mj2yzj++RuDDndpIfdRDYoKEDmB70Z1XeLcXPHZondE6/8ma7EMhiNXH YJ9cI3pMayo2bASfhXIZShWXgofGF3xP/NM6ln9S+o9wQo14kIesU4NkL VSUGRcAelUC9GWCPP7uzjXTfpodW1gMRunbWCcmBrQlfV72HDfg7cWB6V 4=;
X-IPAS-Result: =?us-ascii?q?A0DVBABrUktgjBbLJq1QChwBAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IFPgyFWAScSMYRBiQSIFS0Dml2BaAsBAQEPHQsMBAEBhE0CgXUmOBMCAwEBA?= =?us-ascii?q?QMCAwEBAQEFAQEBAgEGBBQBAQEBhjoNhkQBAQEDAQEBIRU2FwQLEQQBAQECA?= =?us-ascii?q?iMDAgInHwkIBgEMBgIBAReCVQGCZiEPq2F2gTKFWINHgT8GgQ8qjUNCgUlCg?= =?us-ascii?q?TiBdn4+glwBAYElDYNDgl8EgVQCgVEDBFNQCz1BKQJBnTOKJ5I4gwqDMJhxB?= =?us-ascii?q?QcDH4M8iliFU5AZlGuibYFrIYFZMxoIGxU7gmlQGQ2OKwUICYhhhUZAAy84A?= =?us-ascii?q?gYKAQEDCYx/AQE?=
IronPort-HdrOrdr: A9a23:DNs5AqzSvlU1sSr8XtnbKrPxfeskLtp033Aq2lEZdDV+dMuEm8 ey2NES0hHpgDgcMUtQ/eyoEq+GXH/a6NpJ+oEXJ7ivR03Lv2GvIYFk4+LZslrdMgf58fNQ0r olTrhmBLTLfD1HpOvz/QXQKbcd6fad9qTAv4jj5ldrCTpncqRxqzp+YzzrcHFeYCljKd4HGI GH5sxBzgDQGkg/SsigHHEKU6ziirTw+q7OWhINCx455ATmt1rBg4LSKBSW0gwTVDlC294ZnV TtqRDz5amorpiAoCP06mm71flrsef6xsAGLMKBjdV9EFXRozftQph9ULufuz1wh+ej5D8R4a DxiiZlGdhv4HXMeWzwmz/R4k3L1TYj7GKK8y7/vUfe
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,243,1610409600"; d="scan'208";a="34136540"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2021 11:40:45 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 12CBeiMY018757; Fri, 12 Mar 2021 11:40:45 GMT
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>, "lsr@ietf.org" <lsr@ietf.org>
References: <86f134ee-62d0-05dc-84a9-ee1ab130be23@cisco.com> <8b3ef2e9f32f41af8c48e1ddbdc2b983@huawei.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <c9da0fd8-17e1-8f8a-c400-aee5b739da22@cisco.com>
Date: Fri, 12 Mar 2021 12:40:44 +0100
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: <8b3ef2e9f32f41af8c48e1ddbdc2b983@huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.60.140.52, ams-ppsenak-nitro3.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/gYiJz4wRoSlKvoSGTjbq9gPQTpk>
Subject: Re: [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo
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, 12 Mar 2021 11:40:52 -0000

Hi Jie,

please see inline:

On 12/03/2021 09:03, Dongjie (Jimmy) wrote:
> Hi Peter,
> 
> Thanks for your comments. Please see some replies inline:
> 
>> -----Original Message-----
>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak
>> Sent: Tuesday, March 9, 2021 5:46 PM
>> To: lsr@ietf.org
>> Subject: [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo
>>
>> Dear authors,
>>
>> here are couple of comments to draft-zhu-lsr-isis-sr-vtn-flexalgo:
>>
>> 1. whether we want to flood VTN specific link data in IGPs or not is something
>> that deserves its own discussion.
> 
> IGP as one option can be used to distribute the VTN specific link information among network nodes, and some of these nodes could further distribute this information to a network controller using BGP-LS. This is similar to the distribution and collection of the TE link attributes of the underlay network.

I would say the need to distribute VTN specific link information 
requires a broader discussion. We already advertise per instance, per 
area, per topology, per application link attributes. Adding yet another 
dimension needs a careful thinking.


> 
>> 2. Nevertheless, the proposed encoding does not seem to be a fortunate one:
>>
>> a) it hijacks the L2 bundle member TLV for VTN data. I don't see the need for
>> that.
> 
> It is considered as one option to advertise the VTN specific link information when Flex-Algo ID is re-used to identify a VTN, as there is no existing mechanism to advertise per-Flex-Algo link attributes (this is a difference between MT and Flex-Algo). And based on the L2 bundle mechanism, only minor extension is needed.

the fact that there are no link attributes per each Flex-algo ID is a 
feature, not a miss.

> 
>> b) the proposed mechanism to associate the VTN specific link data with the VTN
>> itself by the use of the link affinities is a very user unfriendly way of doing it. If
>> the VTN need only the low latency optimization, provisioning additional
>> affinities seems like a unnecessary provisioning price that would need to be paid
>> by the user for the encoding deficiency. You want to flood the VTN specific link
>> data, put the VTN ID in it.
> 
> A VTN is associated with not only the metric types defined in the Flex-Algo, it is also associated with a subset of network resources. Thus different VTNs with low latency optimization may need to correlate with different set of resources for packet forwarding, hence different Admin Groups are needed to distinguish the different set of link attributes of a L3 link. Using Admin Group (link affinity) to correlate the link attributes with a Flex-Algo is the mechanism introduced in the Flex-Algo base document, this document tries to reuse the existing mechanisms when possible.

not really. Flex-algo specification does not make any correlation 
between any link attribute and Flex-algo ID. It can not, as the same 
link attributes may be used by many Flex-Algo IDs. Flex-algo uses link 
attributes during calculation but these attributes are not tight to any 
specific Flex-algo ID.

thanks,
Peter


> 
> Introducing a VTN-ID is another option, which would require a little more extensions. That mechanism is described in draft-dong-lsr-sr-for-enhanced-vpn, which is targeted to provide a more scalable solution with the additional protocol extensions.
> 
> Hope this provides some background about this design.
> 
> Best regards,
> Jie
> 
>>
>> thanks,
>> Peter
>>
>>
>>
>>
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> 
>