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

Peter Psenak <ppsenak@cisco.com> Tue, 09 March 2021 09:46 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 4E5A13A18DA for <lsr@ietfa.amsl.com>; Tue, 9 Mar 2021 01:46:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 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, 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 Kv8OSWFxTJ2p for <lsr@ietfa.amsl.com>; Tue, 9 Mar 2021 01:46:04 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A2C3A18C1 for <lsr@ietf.org>; Tue, 9 Mar 2021 01:46:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=833; q=dns/txt; s=iport; t=1615283163; x=1616492763; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=8UCFsJl44NbN0VzIaqamKw58t3CTtvuwPYs4/zp2UkA=; b=CVzvxE4b59FW9k+BY2Q/5CWHFdKhYbO1CWvt54dMZLGFCScspO6MRWhN Ura1cyVP2XNJAfxstuhnsy+qnpf4xEvOQwKCQTSXKdS8cv8liACKb+n5C g68peFop9KX+IbwDl2hiY4G4UYmHmnhwNfmfnxWXgOOklGRn7DdI5t6pc U=;
X-IPAS-Result: =?us-ascii?q?A0DzBQCXQkdglxbLJq1aHgEBCxIMQIFEC4N3AScShHKJB?= =?us-ascii?q?Igqmw2BaAsBAQEPNAQBAYZOJjcGDgIDAQEBAwIDAQEBAQUBAQECAQYEFAEBA?= =?us-ascii?q?QEBAQEBhjcMhm4VdgImAl8NCAEBgmyDCKtvdoEyhViDM4FFgQ8qiVCENYFJQ?= =?us-ascii?q?oE4hzWDUIJfBIFUgVqBI4F1nS2KJJI4gwmDL5huBQcDH5NgkBKJRosfomOBa?= =?us-ascii?q?iKBWTMaCBsVgyVPGQ2OKw0JjidAA2cCBgoBAQMJjWgBAQ?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,234,1610409600"; d="scan'208";a="33975533"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Mar 2021 09:46:01 +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 1299k1Sl030041 for <lsr@ietf.org>; Tue, 9 Mar 2021 09:46:01 GMT
To: "lsr@ietf.org" <lsr@ietf.org>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <86f134ee-62d0-05dc-84a9-ee1ab130be23@cisco.com>
Date: Tue, 9 Mar 2021 10:46:01 +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
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-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/GfydUD-wdqarIZNZj_-Y8M-VCwE>
Subject: [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: Tue, 09 Mar 2021 09:46:06 -0000

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.

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.

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.

thanks,
Peter