Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 10 December 2020 06:17 UTC

Return-Path: <ginsberg@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 66CFE3A0603 for <lsr@ietfa.amsl.com>; Wed, 9 Dec 2020 22:17:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 header.b=CLebjQA1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=b9DPi3n7
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 RXAslb_KaD1w for <lsr@ietfa.amsl.com>; Wed, 9 Dec 2020 22:17:40 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBF43A05AA for <lsr@ietf.org>; Wed, 9 Dec 2020 22:17:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43495; q=dns/txt; s=iport; t=1607581060; x=1608790660; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=rtBs9sljVTQoRrsdFWOySbD8MqZwAXWV1kW6ZHbl814=; b=CLebjQA1toW7eJWNgo+Dgfxru0EjVh5ylzsDcaZL+bLdyOrFbS4LkC3J mOI01q2xCBrHzhsuerdv0Q7uFbSAsQqpYpR+HWurlo6rKn4qsRzFaYI1k snYfRZ9A8AAcy0TAUYU0DR+wZERqoH2zWlz8CprFeTM+LeiBLJ+IRSZIv 4=;
IronPort-PHdr: =?us-ascii?q?9a23=3A5Rg5bh0p0KaaVV2CsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGtadti0PMVITfrflDjrmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtVH9r7blzW5Ha16G1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmBQAOvdFf/5NdJa1iHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+BIy9RB3VbLy6IBwONXgOCcIcojnGCUwNPBQsBAQENAQE?= =?us-ascii?q?YAQoKAgQBAYRKAoF/AiU4EwIDAQELAQEFAQEBAgEGBHGFYQyFcgEBAQMBAQE?= =?us-ascii?q?QCxATAQEsDAQHBAIBCBEDAQEBASABAgQHJwsUCQgCBAESCBqDBYF+VwMOIAE?= =?us-ascii?q?OolYCgTyIaXSBNIMEAQEFhQ0YghADBoE4gnSCZk6HGxuBQT+BEUOBV34+ght?= =?us-ascii?q?CAQEBAQGBOgEBIh4HBgmDFIIsgVkQgUINIiICVwMLMSsZAS4BBZpejCqQJTh?= =?us-ascii?q?XCoJ0iR6NCoU8gyWKJZRvhhOLe4FuiwyCdo5OhFMCBAIEBQIOAQEFgW0jgVd?= =?us-ascii?q?wFTuCaVAXAg2OIQwXFIM6hRSFRHQCNQIGCgEBAwl8iVoBAQ?=
X-IronPort-AV: E=Sophos;i="5.78,407,1599523200"; d="scan'208,217";a="813900394"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Dec 2020 06:17:38 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BA6Hc7b010261 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 Dec 2020 06:17:38 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 10 Dec 2020 00:17:37 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 10 Dec 2020 00:17:37 -0600
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 10 Dec 2020 00:17:36 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MqptpdHaA89YhICVOIptPZ2wIEfjbHq4YPJMsfAiVYrmx6XH6dPuzNyWXea2uOtzpWGRiVk7sB9p7t33x97mzdA2yaCob3c0467k6QztjbggHL3QeJJllB9wa8icw1wsfnBra/BI22O1i+4911ZzzJNXuFYpostHj1vJLuHTzGhOdI5mXEl1Q1lHbc1vimCfaU8kAyS/0qMsAQJjTUrfaRWKj4xS7IaLHyPu9LXXUGLNITHo5omkFCs8m/G+tPVlIKxI13VwnawXUJTMEq2Or0l9D9gMkln+h3ZfIUVfNFpgopLQFqFpNbZzh+g9r/b4ZBm46QCfDrxD1a1rwLmO0g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fXV8EojXB0c7IJeHaAzidfQwhP3gDde+w+lm5kPPuks=; b=jtSEw30DNA2CGyMnMCl0LSTx+rcnvKUZYnY9+NrZuHsGXrQ2FS+4dB7+uy8EBeycIbVwJiuhmbwJ5nFHmIwdsthkCRj3TeVUPfg3Iz2z3kwb7OkQ/U+SGXj/Dlo9uXcgcCOpEhd/Pm7A42OLKaIvFOh66k8SdOgHrrWthps5aMMos3jnzv6RDUoirJ4s2sgxSyT4yRZZF5eNlpDQNplSxxqSJ+jbDUuVYY8vsj7C9KNpWcmxKzW/ytmzjAYzZcwK1sFrFqmkohHFX7g2L8ZAxOWLIdKfrCqO0jiBb8X6wYR7Fv9E2q6CwqTn1KkeWzr160gzgGxQchLKBOEDiVqvvQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fXV8EojXB0c7IJeHaAzidfQwhP3gDde+w+lm5kPPuks=; b=b9DPi3n7BLlcdJvHFuDybgwY8GcOMCxnVCd4scwCmrHRX8JfEub38ZabPjWf3SV1lvX6jHJTwk1tIxhXNfe05Y8esvRb1aCKD3BIW1mq2XXnCukYD1QuWmphI/ipXn3HnI9bUrUEKw50ay9AwH7Lg5ox9ymt4j0zzuA/mslgUNQ=
Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by BY5PR11MB4056.namprd11.prod.outlook.com (2603:10b6:a03:18c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Thu, 10 Dec 2020 06:17:35 +0000
Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::e063:fc51:b359:2f39]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::e063:fc51:b359:2f39%7]) with mapi id 15.20.3632.021; Thu, 10 Dec 2020 06:17:35 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "li_zhenqiang@hotmail.com" <li_zhenqiang@hotmail.com>, Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, lsr <lsr@ietf.org>
Thread-Topic: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Thread-Index: AQHWyCa69SgvuXvqQUSruOMjcUOnRanukOqggAAPfYCAACN6gIAAA8+AgAD6zdyAACBy0A==
Date: Thu, 10 Dec 2020 06:17:35 +0000
Message-ID: <BY5PR11MB43379FFF67C0E5B14864C0A9C1CB0@BY5PR11MB4337.namprd11.prod.outlook.com>
References: <777B2AC4-CACF-4AB0-BFC7-B0CFFA881EEB@cisco.com>, <169b063524dc4420b37016d2428fc85c@huawei.com>, <29d3d16a-237d-e657-e84c-c74a1e5a841f@cisco.com>, <c779c9da19264b718effd3d0442c8616@huawei.com>, <8024148b-df7d-d79f-26b6-c64b9113cd9e@cisco.com> <MEYP282MB2022B32F7AC9A761DF4769FFFCCB0@MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM>
In-Reply-To: <MEYP282MB2022B32F7AC9A761DF4769FFFCCB0@MEYP282MB2022.AUSP282.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: hotmail.com; dkim=none (message not signed) header.d=none;hotmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2602:306:36ca:6640:c98e:8f45:15f1:c01a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e7c3c1c6-9907-4a08-5605-08d89cd34945
x-ms-traffictypediagnostic: BY5PR11MB4056:
x-microsoft-antispam-prvs: <BY5PR11MB4056868A26743ABD99062596C1CB0@BY5PR11MB4056.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: MqosP5/8O4r+P6WNji6IGPTtmnX/Qoysita97bb3q1cR/F8WWwmwsxIYQw9ec67ufgR+oVdoZrjWvUHFioDA15fRGP5nTgho9dTyUq221zGjs5m/pmUvwITWxSKlmLs+9sG2Dwj6zcQN4DDxhf1YDpAQ+L+efTbLM4RQk4OhNOSWQdwG+F1H3Thwc9lXz1t5zMqYYkrsSWsNt6AQWEjLzhjuX+QK9rViBrFzXHvU+39/IrY2nicMw+/+/GS9ppfvVLmSLl2us6iHA5PCVpm5glfnkfmbyf/oTvN3VX1qMLi86xS4SxZ5SlsZgvweP2myfeuhg9Uj16apAbhLzCCqD5Og41FqExla4nVvESL1WqYCnibiLo4MKF8vmC/zBQ5n3pwNNDmtrp/nhiYZ+AvTIQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4337.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(366004)(376002)(52536014)(5660300002)(8676002)(7696005)(71200400001)(66446008)(55016002)(966005)(186003)(66946007)(9686003)(2906002)(66476007)(64756008)(8936002)(76116006)(86362001)(66556008)(45080400002)(33656002)(508600001)(83380400001)(6506007)(110136005)(21615005)(53546011)(166002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?cjZTTwm/h0/X3L2YdzNExTo0+IfECObruZRxctzb2KIby1mRI/fCNlZKKsji?= =?us-ascii?Q?7zOBL0do8pi0gEKv6a4yMTa+2Mw7SId94poqQrFVoDBxXPIKi+SLymsgM88T?= =?us-ascii?Q?hEr4LFlgViD2OZzuuJA8W1vhO9nVarSJ4SO4WycfMhTd+8iyu9p4P1KCUGsc?= =?us-ascii?Q?/7Azfz6rmlq78YNKQOtYY/KJY4dTWcZi63E5F9Ta/64UbPkmVTLGZUbAS1E6?= =?us-ascii?Q?wt0C9m3Ew+5BVoa6BqTHfuLwU37h27ogvrsVldwx6c4yQkrbJV7dI6BJkvRY?= =?us-ascii?Q?jqt7LmiNmD799gfG/zeQ6sPTUhXketwJUcGgDyQ94Nv0Ydl4EJSruXM+sDYz?= =?us-ascii?Q?khlcNVRkt5WBRuFgv++kW24+LLcv5Ziid+EefhhB3lD4PZ7dO95t4CBer+gJ?= =?us-ascii?Q?NcsY9Zidum1Y2M/IrNxTQ5mtIEOeknw+6V61rBqLNPVlaS8J1Q/2O9y0okaD?= =?us-ascii?Q?8dY8+dNg0hjWP5R8y35JC1SKW3OnRw1MFwgbxSa5RIJ7exVLj4JJXHmxUpBN?= =?us-ascii?Q?TooAOqjElkQa4JMSgViaMNauVC8pGcX78Am0FPoE2oEzrbQvbG3E1cskF/N3?= =?us-ascii?Q?0AxAtcCgLo0u+8u1+aIbzKM4mHz5fZfvnbAPwHB9ibZPYGC3YFB5Lc4bDTru?= =?us-ascii?Q?NelojZTZiv7FjtAupMLx31RHYhiKEehkGdhrjC2L9JHvCQFO6FphLKwko5/W?= =?us-ascii?Q?QYtNARKQ2x5RvsbM2SxTocpJ9TRkbrIT8wkq/q4JWRAU46oMLgAcU/9AncGC?= =?us-ascii?Q?BSWaeCeq5ZkjvP3Ibg3L3CFFUFE4PzNFo2dxe0M7+plclRODEsVeH1c8tZed?= =?us-ascii?Q?6XPWpNczowXg1PCvCfq3wjZcq1IXJdkcKxNKYAEPBpLHG+HvwzdqrWAEyBPi?= =?us-ascii?Q?Jt9IFL9vZ2+HcFt8IKPIy9MhztYrr2Vq721VCJpi3OFQgIQKJsi4bpwP7Ged?= =?us-ascii?Q?Wj6MUi4P15V12IG/sy+nThMQ6NOP7MdxdjgzXcQFBUsFydHqNFjlKM1WhfND?= =?us-ascii?Q?+ZTv7ks65AIwUdFPo1AW+s8MkojinyPuI7nQrwcyyTuKStE=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY5PR11MB43379FFF67C0E5B14864C0A9C1CB0BY5PR11MB4337namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4337.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e7c3c1c6-9907-4a08-5605-08d89cd34945
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2020 06:17:35.3598 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: lHH7mFxN3nIjbnNVoM9gKnRFfPkVDQW4Ar90LZGiJaHcvRbxteZhR6cRZaO1dghqmbxph1AoHObN1Ptdt+zRAw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4056
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/wcVnYFCBT_7sHZ-8pEHnZTHUsr8>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
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: Thu, 10 Dec 2020 06:17:46 -0000

Zhenqiang -

In regards to:

<snip>
[Zhenqiang]Since paths for IP flex-algo are calculated within specific MT, I think one new top-level TLV for ISIS is enough to advertise prefix reachability associated with a Flex-Algorithm, that is the one defined in section 6.1. MTID can be used to indicate it is for IPv4 or IPv6.
<end snip>

You have misunderstood RFC 5120.
It is true that the reserved MTIDs defined in https://www.rfc-editor.org/rfc/rfc5120.html Section 7.5  are restricted to support only a single AFI/SAFI, but non-reserved MTIDs are NOT subject to this restriction. It is quite possible to use one of the unreserved MTIDs and support forwarding of both IPv4 and IPv6 address families on the topology associated with that MTID. Therefore, it is necessary to define AF specific TLVs. And that is why RFC 5120 did so and why this draft also must do so.

Draft authors -

https://tools.ietf.org/html/draft-bonica-lsr-ip-flexalgo-01#section-6.2 states:

"The ISIS IPv6 Algorithm Prefix Reachability TLV is identical to the
   ISIS IPv4 Algorithm Prefix Reachability TLV, except that it has a
   unique type."

But this is not completely accurate.
The existing Prefix Reachability TLVs for IPV4 (135, 235) and IPv6 (236, 237) have different flags formats.
See https://www.rfc-editor.org/rfc/rfc5305.html#section-4 and https://www.rfc-editor.org/rfc/rfc5308.html  Section 2 respectively.
And of course the legal ranges for prefix length are different.

I would expect these differences to be preserved in the new TLVs defined in this draft. It would therefore be better (and more accurate) if you replaced the above statement with a diagram for the new IPv6 TLV comparable to the one in Section 6.1.

Thanx.

   Les


From: Lsr <lsr-bounces@ietf.org> On Behalf Of li_zhenqiang@hotmail.com
Sent: Wednesday, December 09, 2020 8:04 PM
To: Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>rg>; Dongjie (Jimmy) <jie.dong@huawei.com>om>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>rg>; lsr <lsr@ietf.org>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

Hello Peter,

follow-up questions with [Zhenqiang].

FA calculation is done for every MT topology independently.
For IPv4 it will take all routers participating in MT0 and run the FA
calculation on top of MT0.
For IPv6 it will take all routers participating in MT2 and run the FA
calculation on top of MT2.

[Zhenqiang] Could you please elaborate this explicitly in the draft? For example, in section 7, replace the setence "IP Flex-Algorithm application only considers participating nodes during the Flex-Algorithm calculation" with "IP Flex-Algorithm application only considers participating nodes within the same MTID during the Flex-Algorithm calculation".

[Zhenqiang]Since paths for IP flex-algo are calculated within specific MT, I think one new top-level TLV for ISIS is enough to advertise prefix reachability associated with a Flex-Algorithm, that is the one defined in section 6.1. MTID can be used to indicate it is for IPv4 or IPv6.

Best Regards,
Zhenqiang Li
________________________________
li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>

From: Peter Psenak<mailto:ppsenak=40cisco.com@dmarc.ietf.org>
Date: 2020-12-09 21:05
To: Dongjie (Jimmy)<mailto:jie.dong@huawei.com>; Acee Lindem (acee)<mailto:acee=40cisco.com@dmarc.ietf.org>; lsr<mailto:lsr@ietf.org>
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
Hi Jimmy,

On 09/12/2020 13:52, Dongjie (Jimmy) wrote:
> Hi Peter,
>
>> -----Original Message-----
>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>> Sent: Wednesday, December 9, 2020 6:45 PM
>> To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; Acee Lindem (acee)
>> <acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>>
>> Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>>
>> Jimmy,
>>
>> On 09/12/2020 11:10, Dongjie (Jimmy) wrote:
>>> Hi authors,
>>>
>>> Here is one comment following the previous discussion on the mail list
>>> and the IETF meeting.
>>>
>>> The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm
>>> participation information, there is no separate TLV for IPv4 or IPv6
>>> Flex-Algo participation.
>>
>> the draft clearly says:
>>
>>      "The IP Flex-Algorithm participation advertised in ISIS IP Algorithm
>>      Sub-TLV is topology independent."
>
> This does not answer my question.
>
> Section 7 gives the rules of IP Flex-Algo Path calculation:
>
> " IP Flex-Algorithm application only considers participating nodes during the Flex-Algorithm calculation.  When computing paths for a given Flex-Algorithm, all nodes that do not advertise participation for IP Flex-Algorithm, as described in Section 5, MUST be pruned from the topology."
>
>>From IP Algorithm TLV, one cannot tell whether a node participates in Flex-Algo 128 for IPv4, IPv6 or both. This would cause the problem described below: >
> When one node uses IP Flex-Algo participation to compute a path for an IPv6 address advertised with Flex-Algo 128, it will not prune the nodes which participate in Flex-Algo 128 for IPv4 only from the topology. Thus IPv6 packets following that path may get dropped on nodes which participates in Flex-Algo 128 for IPv4 only.

FA calculation is done for every MT topology independently.

For IPv4 it will take all routers participating in MT0 and run the FA
calculation on top of MT0.

For IPv6 it will take all routers participating in MT2 and run the FA
calculation on top of MT2.


>
>>
>>> If some nodes participate in IPv4 Flex-Algo 128, and some of these
>>> nodes participate in IPv6 Flex-Algo 128, how to ensure that the path
>>> computed for IPv6 Flex-Algo will not use the nodes which only
>>> participate in IPv4 Flex-Algo 128?
>>
>> there is no such thing as "IPv4 Flex-Algo 128" or "IPv6 Flex-Algo 128".
>> There is only algo 128.
>
> Agree that Flex-Algo 128 is application or data plane agnostic, and as we discussed the same Flex-Algo can be used with both IPv4 and IPv6 (maybe also for SR-MPLS, SRv6). These terms are used as shorthand of "Flex-Algo 128 used with IPv4 or IPv6"
>
>> You are mixing data plane support with algo participation.
>
> I understand Flex-Algo definition is application agnostic, and Flex-Algo participation is application specific, it is just not clear to me whether IPv4 and IPv6 can be treated as one application.

yes they can.

>
>> If you want an algo to only include nodes that supports specific data plane,
>> you would need to define a specific algo for it.
>
> This IMO contradicts with the base concept: Flex-Algo definition is application (or data plane) agnostic.

not really, see above.

thanks,
Peter

>
> Best regards,
> Jie
>
>>
>> thanks,
>> Peter
>>
>>
>>>
>>> Best regards,
>>>
>>> Jie
>>>
>>> *From:*Lsr [mailto:lsr-bounces@ietf.org] *On Behalf Of *Acee Lindem
>>> (acee)
>>> *Sent:* Wednesday, December 2, 2020 5:13 AM
>>> *To:* lsr <lsr@ietf.org<mailto:lsr@ietf.org>>
>>> *Subject:* [Lsr] WG Adoption Call for "IGP Flexible Algorithms
>>> (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01
>>>
>>> This IP Flex Algorithm draft generated quite a bit of discussion on
>>> use cases and deployment prior to IETF 109 and there was generally
>>> support for WG adoption. This begins a two week WG adoption call.
>>> Please indicate your support or objection to WG adoption on this list
>>> prior to
>>> 12:00 AM UTC on December 16^th , 2020. Also, review comments are
>>> certainly welcome.
>>>
>>> Thanks,
>>>
>>> Acee
>>>
>
>
>

_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr