[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
- [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo Peter Psenak
- Re: [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo Dongjie (Jimmy)
- Re: [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo Peter Psenak