Re: [Lsr] [Need AD’s Judgement and Explanation] Re: Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

"Acee Lindem (acee)" <acee@cisco.com> Tue, 17 May 2022 15:16 UTC

Return-Path: <acee@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 97BADC15952A; Tue, 17 May 2022 08:16:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.493
X-Spam-Level:
X-Spam-Status: No, score=-9.493 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, HTML_TAG_BALANCE_BODY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 header.b=H+iv9Ptk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dD6OuFdg
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W19Zxk-IgOLg; Tue, 17 May 2022 08:16:46 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1424CC1595E6; Tue, 17 May 2022 08:16:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=534699; q=dns/txt; s=iport; t=1652800606; x=1654010206; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WjFn2rZ/cp+l7/PgpSuAQtJJvkDpMKrgQwej1M/HzLc=; b=H+iv9PtkjtxexE9AW2CWH0ymMmt61BlbfJR68y7Vocp6tZOxfL0xJYou fR5qBEC0yxKRVTkl131RKQsWhmB7RmnL6KWk44UOc2lo5Y9LTcCrV8kv2 +eL0oyED8FC6yj+jAzZAgRXkFqIQZ4sYLUXC/zdpCoUmusAerqkmrmbea 0=;
IronPort-PHdr: A9a23:HfBAlBKcH52fP4unHdmcuWEyDhhOgF28FgIW659yjbVIf+zj+pn5J0XQ6L1ri0OBRoTU7f9Iyo+0+6DtUGAN+9CN5XYFdpEfWxoMk85DmQsmDYaMAlH6K/i/aSs8EYxCWVZp8mv9P1JSHZP1ZkbZpTu56jtBcig=
IronPort-Data: A9a23:E4jfvK0C59RKF5QexvbD5Ulzkn2cJEfYwER7XKvMYLTBsI5bp2MAn2ceDDyCO6uDMGfyf4h0PI20/BwG7ZHUn9VhGgI53Hw8FHgiRegpqji6wuYcB84ZRyH6ZBoPA/42N5+RdajYcleG/k33auW48yElvU21buOU5NDsa3gZqTBMEE/NuTo78wIIqtYAbeqRWmthivuqyyHrA2JJ7hYvWo4iBw1vnzs01Bj6kGtwUlXT/pmntneG/5UeJMp3ya1csxLFrodo8u6SH44vzZmj9W/fuhwqEN7gy+69eUwRSbmUNg+L4pZUc/H92V4Z+WpjieBiaKR0hUR/011lm/h4w9hAnZexUgwueKbLnYzxVjEJSHEiZ/Yfou+vzX+X9Jb7I1f9W3f2yvtySUA7IYNd/v1tRGBWsPIcJSAEah+Er+O73Lz9TfNj7uwnN9PDPY4DtDdn1z6xJfUrXZnFX+PL6MNW9Dg1j8FKW/3ZYqIxazV0RBbdZRxXN01RDp8i9M+wnmLydTRb/Q7Nrqss6G+Vxwt0+LToOcDePN2HWcsTmVyXzkrZ9mL2CxAYKdq31SGE9H2sm+aJmjn0HokUfIBUXNYCbEa73GcfDlgdUkG25KDhzEW/QNlYbUcT/0ITQWEJ3BTDZrHAs9eQ+RZoZiIhZuc=
IronPort-HdrOrdr: A9a23:TEgAw63D3vO6wkfhnBW2PAqjBRlyeYIsimQD101hICG9Lfb3qyn+ppsmPEHP5Ar5AEtQ5expOMG7MBfhHO1OkPYs1NaZLUbbUQ6TTb2KgrGSuwEIdxeOlNK1kJ0QDpSWa+eAQ2SS7/yKmzVQeuxIqLLsncDY5ts2jU0dNz2CAJsQiDuRfzzra3GeMzM2Y6bReqDsg/Zvln6FQzA6f867Dn4KU6zovNvQjq/rZhYAGloO9BSOpSnA0s+6LzGomjMlFx9fy7Yr9mbI1ybj4L+4jv29whjAk0fO8pVtnsf7wNcrPr3NtiFVEESutu+bXvUlZ1SwhkFwnAhp0idsrDD4mWZjAy200QKWQoj6m2q15+Cq6kdR15ar8y7ovZKkm72geNr/YPAx376wtXDimhEdVZhHodF2NyjyjesmMTrQ2Cv6/NTGTBdsiw69pmcji/caizhFXZIZc6I5l/1UwKp5KuZJIMvB0vFtLACuNrCq2N9GNVeBK3zJtGhmx9KhGnw1AxedW0AH/siYySJfknx1x1YRgJV3pAZNyLstD51fo+jUOKVhk79DCscQcKJmHe8EBc+6EHbETx7AOH+bZV7nCKYEMXTQrIOf2sR52Mi6PJgTiJcikpXIV11V8WY0ZkL1EMWLmIZG9xjcKV/NFAgFCvsukaSRloeMMYYDaxfzOmzGu/HQ18kiPg==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CoBADea4Ji/5JdJa3IC3MGAQEBGQMCAQcEgRyFdYcJOrZniXWSdYK0VRkP
X-IronPort-AV: E=Sophos;i="5.91,230,1647302400"; d="scan'208,217";a="938423128"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 May 2022 15:16:44 +0000
Received: from mail.cisco.com (xfe-aln-004.cisco.com [173.37.135.124]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 24HFGicC009109 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 17 May 2022 15:16:44 GMT
Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 17 May 2022 10:16:43 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Tue, 17 May 2022 11:16:43 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SfZ+Bo+kv3+xyRTDdAdWInUOYZu0ScMl4UL9VgTBhfYnTcYuM2SdKjSLcpp+0uxcN8e6Os91LhfZbupYkq8D/2TSSC8a0jlnapMW8uO9VRhADnK+xeLvyiWWxE124/THMo83+rbK8ip8kRc/7aY0X6GOK0mfOaH5ssOEg9vs/4IvPNfIvIQdAAfJ8ANQJDvbbkXeqFxMxPxhd8g5Kb8kuPJiJlhHSrOFsoN/yQd8ligsPxvcnLXVD0a7OubVlrbJ4b4ROClUkQY6DyK6C3+J+d3Jbu9xvPbOKJBYrEXVep0IwUED67SVEWWaG987VxQgPGZb9EEzraPgDmg7Fx4fVQ==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WjFn2rZ/cp+l7/PgpSuAQtJJvkDpMKrgQwej1M/HzLc=; b=GilWjolSwm0umJB2vbfxsFb0qBeRNvjI0HeB9dB+sqa1Pp8IkTzYeQyavyqiwn7Vg7MSL08KCaYGdx5LXwWRLm2UUrlJge6PP8Ffam03fZK0BPHTERdPF+wJyiVrFvNn7fHl9k3+xmuv1O/U0HNfx4JFHWZ48avRH09py24y/i+LIlpRFvoC1FS3ocIoi3DNd/x/D0DcDOMIjYe0XVy/cEwqb/mgQG8jesraFcb2krvS07T6KmxIelrPQEunw4Z+Fv0O06CVkDs1nYwdAyB5SOS3Oprp9MspRra0lptwokSjq9e3WFs3P7pyNLS7Nk+beK/RUyxyxBQ1vi5fmyLBkw==
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=WjFn2rZ/cp+l7/PgpSuAQtJJvkDpMKrgQwej1M/HzLc=; b=dD6OuFdgze6VUG159sN22fR9Z64D923FB2gEcZxU4dk4I0QfNNkHHqpxy2usFJu5MD70M7Dq1ii8Ab/Cn5Gv6Xtqd3Yqs0LfzYfETLQfG0atVH3MGyLzjdBoyAAD09l5ggJJzJ7ivK9oi0uaepmED+tqRCvOQGcKh6oIio6ykho=
Received: from BYAPR11MB2757.namprd11.prod.outlook.com (2603:10b6:a02:cb::16) by CY4PR11MB1576.namprd11.prod.outlook.com (2603:10b6:910:d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5273.13; Tue, 17 May 2022 15:16:32 +0000
Received: from BYAPR11MB2757.namprd11.prod.outlook.com ([fe80::dc12:a344:f033:8193]) by BYAPR11MB2757.namprd11.prod.outlook.com ([fe80::dc12:a344:f033:8193%4]) with mapi id 15.20.5250.018; Tue, 17 May 2022 15:16:32 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>, Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>
CC: "jgs@juniper.net" <jgs@juniper.net>, Ketan Talaulikar <ketant.ietf@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>, "draft-ietf-lsr-ip-flexalgo@ietf.org" <draft-ietf-lsr-ip-flexalgo@ietf.org>
Thread-Topic: [Lsr] [Need AD’s Judgement and Explanation] Re: Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"
Thread-Index: AQHYafmyUjsQAwM3YUOUWGWN7VpbyK0i6yuA
Date: Tue, 17 May 2022 15:16:32 +0000
Message-ID: <806DEB58-F306-4704-82DB-5F2945D489A3@cisco.com>
References: <1206df78-bfef-6e05-52d5-b22735f74293@cisco.com> <1414CF1B-8DDB-4D17-A7C1-8423AB9A7AA4@tsinghua.org.cn>
In-Reply-To: <1414CF1B-8DDB-4D17-A7C1-8423AB9A7AA4@tsinghua.org.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.59.22031300
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9f581390-e81a-480f-74e1-08da381839c6
x-ms-traffictypediagnostic: CY4PR11MB1576:EE_
x-microsoft-antispam-prvs: <CY4PR11MB1576274DEA0377F289DDC981C2CE9@CY4PR11MB1576.namprd11.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: y51+Teb6qHnooa4QzikIWjmShdKeApizUvxiIrZKdihVQrIbXV5OcAqnco0aucnMJ0fpxxV48SN3rwQLn+ZUvfCJ+BwCITQbv9Pwl+JG6ykEh0HMPb9HgPCp8KH8uTuAigaPvmr8upmKFTnPhvOwwd4XQsxWGDn/BibGJO0s8ucWYozh5YGscqiFUABLCFZuDGutWTjaYSmejDY65CPgtVK6ASd5UwaeCAe2+HQ1d/M1Kk4i6J3tWRV3M2cTb2JNrRPZVjX+VW/1K7aY11ofOB32eKWsJyEIJxorqlCaOrxXHS4pjl9fRQjwH3CiVlEhTcOqbsEG/N3yyEU/awCIRRhCrM07EMGXvOSEiT2JCeY/9rFJzsIsEADnCqPRI2h74jHKWTnZHbfEzVxKfIufnuuPhvdEdOdUdrUrXqQNDGYAztXFXYTd3pWp8ZNg9ApqZMN0+RzEc75PDqNmTmvCa56Pmyd+t+ts48xTX68szqu0qDh76qJ4Nj/9Pg+vE3EizuD2Zz8vUMUx5iubqqBv0fGF3BllIMSk/MeK7f05nHkBj8GI0N8/eIvc7NiVWG8F+bT2Sps46o71m//07LPKAbih6mIBHXplOFYVrfYxCZeeeuLgki6M/vm1phfuRDDCPVjo7M+MBvZJpXDgL2RL8+j1y0U/uUP1Vef9M8TLUHaplH//fsyUmgHflv+eNEqqyL/3kfVIVazusrpd9nRpbQFiB98MIoJv5ItUXJrQU+RLWQWNmib00QMKVFZPURtZjrKa2VjowCC08WWqHU9cNp7ACP9ZrWtDchIXdfIlqpP5c9SbdkA4F4bqs60FsCk3f3AVsPUJtl43EAl3a7xqmVnvaJ4aeodLRy9QkvwykrU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2757.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(53546011)(66946007)(66556008)(2906002)(64756008)(33656002)(8936002)(6506007)(9326002)(66446008)(6486002)(66476007)(966005)(71200400001)(76116006)(91956017)(4326008)(86362001)(508600001)(66574015)(83380400001)(186003)(5660300002)(316002)(122000001)(38100700002)(36756003)(54906003)(30864003)(110136005)(26005)(6512007)(2616005)(38070700005)(45980500001)(579004)(559001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: Ab7Mz7yf6EKh5J2obgVNKTAnhiI5mji5GOxqglcwqY+I3tF72GU+N8H3btutR0FUAbtiHsp1PWCwSz7QbAIfftPSGYimfyyHjP3PyakUzt642ww1OeBQtrA95KrZUMqpatNmDx/YdSH8d8dDGB4uFjJdiyoHIG441Kr9yau9KEtFkeLS+smVzIJx7yVxlD9KW/fWXrKF62o7iZLxKXAaUQBzMHg6+COkK9pshc9Uvfx7BmsfulbLXn8gqvsGUEXQ4J+C5YROgM0x8J84XvqYAuO1hcu/oE+qZWi7HqQtbe7y83rQkf8mMRaHLvrmrimdt3QxwzuIYgntbMoXky0NPKm5PAZjnCgQSVms+euYOXsKI2gG9HhSwTB6HSoH9pzbgL/a97tjd7wvKqWBaFa8mdafiBx2Xodh6b/uYCFkdUj+W8iwcFsvm5eJkUac4Nzw1XqQzAHuEO2Q62G5GYN5+VW4uUuqd9msjs4FXe916hxxZsiF4MZFb9ekpVQG4D+bFiP18iM0HL2b9xg3uRTXx+IWT6L0pb/6R8ddomUe2sWWHdoiiQtDN4aezJ6y2NgH6weEYrHvtBZsOtVFCBNF+GAtvKgs1rEHSFLuQk3rUK7pr+ji+ZKmov9JJ4Zlp5YVSsFMEyC8GnaUWeiHOFXDOIvoIOqBCFvZzTCy9PPxi4/jBZ1OZ8tTnaDR6ZwRuTg+bVMmDI5bBDCm9DHXV/SmJiH37rrCEh8okNR4QIoOo5iU/njFHABu4J6o+190en0j/CfXt5Ezd+j0NU2Nk2tABZVfPE3VOVkW+U1/4DTNnQJ8mhUsN08L6/MwTU7lqTgVt4NVNANEHe7KSWaTZ4falHFAhRPien6fF2VNeGJ2+Q78CgdeVVEGSexnnc6oYLTztPcBwi4ka+nlOUZm9BmtCtOKBGH5n0qUZPDMiyspxK7lnKmm0C/O5MxDeHIXv6tb+g70PyUTjoYCeZiUXiZ/RuhjJG52EQ7jZ9AQPf8K8S9/dIBU54LT8SJkV6BphI22ziqoMWWEvLgbJHf0cld6sVDCm7UX9qvkd5CUVo1bA6D9vUz/sLXkdV2Y+4EWHdsIaTcyBnwGTOfrYi2ucg8Ac2p8aOdrZHDUeLPaccqUqA9iCwZpr6FSW7On3tnFyaC6Fm0BCPVZhO1Psthiu2Gh6E05YIWvFJRfIg4TyxqgfmZVXiuZtn37V/BGXNVkRweR73TX0/ScgguXnBLSN3hAFxqgeR6ntb1k5/ySE8cb5vVD2m0V5fsz8mbziGLkhUKgcO5ZsFpNmC734MXrKMnXzOmE36pks+E7tmxAkFlyH9WcNQ4uFxkk6pSSqQs2OT3tXAYdbxo+xBWwob2pROgtDm6LVJeR7bvnLgA95wgpRrqAhxzafhg4LCppkFLDiYHyEc0BUGbeUyKpAniM+dVQV1q7MX5GktZ3fGF+HVhc4HQ1NPtNnVf5Jxf8VJcUInBDYOwfU/gpfvzMvK7cZhKq+bCDch+GODTOGc1biJv/JFQpCCmlvR3KdaPOxROrx0VRmPkWPDnnH5DIBqcHHniFv4eojcNTMUbSpDDKUVkxevfhjSJrs005lIYmg/Vbq73FFfSho4NfDQ/h4vyg/V59y2jsNpnDiJY2QHlV+zoQ6jbd/ufdk94M3KEwEjfDn0uWnuffDmpGMdpXkVD7zxpxjykNrO+TOR91CFujShwUYwpPhcKu2QlYA+uxfCv2LoHsB1aHkz79pptbQ/eg8eoliA==
Content-Type: multipart/alternative; boundary="_000_806DEB58F306470482DB5F2945D489A3ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2757.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f581390-e81a-480f-74e1-08da381839c6
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2022 15:16:32.5555 (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: sY3FV0Do2QpbOu/FAr1flNPhg/Hq4E15UrGfqZWJAN6UnYU2xtHKz0n3bgE0f4x/
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1576
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.135.124, xfe-aln-004.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/L6oAvoJHBHmwr72E8Z4O-7dm_0A>
Subject: Re: [Lsr] [Need AD’s Judgement and Explanation] Re: Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.34
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, 17 May 2022 15:16:50 -0000

Hi Aijun,

Why you don’t you put your proposals in a draft? Independent of the technical soundness, the WG last call is not the time to redefine requirements and redesign functions. There are always multiple ways to solve any problem and there is nothing fundamentally broken with the current IP Flex Algorithm or the requirements we’ve been working toward for close to two years now. In fact, there are implementations.

Just because you believe you have a purpportedly simpler encoding and a different view of backward compatibility doesn’t mean the WG is obligated to change direction.

Thanks,
Acee

From: Lsr <lsr-bounces@ietf.org> on behalf of Aijun Wang <wangaijun@tsinghua.org.cn>
Date: Tuesday, May 17, 2022 at 10:23 AM
To: Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>
Cc: Acee Lindem <acee@cisco.com>, John Scudder <jgs@juniper.net>, Ketan Talaulikar <ketant.ietf@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>, "draft-ietf-lsr-ip-flexalgo@ietf.org" <draft-ietf-lsr-ip-flexalgo@ietf.org>
Subject: Re: [Lsr] [Need AD’s Judgement and Explanation] Re: Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi, Peter:
Here is the contradictory:
The prefixes that associated with SID can exist in multiple Algo and also the algorithm 0.
Why the prefixes that don’t associate with the SID can’t exist in specific Algo and also the algorithm 0?
I have provided the solutions for the loop avoidance. If this is only your worry, you can responses the threads that I discussed with Acee.



Aijun Wang
China Telecom


On May 17, 2022, at 21:42, Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org> wrote:
Aijun,

On 17/05/2022 15:04, Aijun Wang wrote:

Hi, Peter:
Based on the statements in https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo-06#section-6 <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo-06#section-6> as the followings:
“To be able to associate the prefix with the Flex-Algorithm, the
   existing prefix reachability advertisements can not be used, because
   they advertise the prefix reachability in default algorithm 0.
   Instead, a new IP Flex-Algorithm reachability advertisements are
   defined in IS-IS and OSPF.”
Then why the FAPM sub-TLV can be included in these prefixes reachability advertisements?

FAPM is only used for SR MPLS, where the prefix can exist in multiple algos and forwarding is realized via algo specific label(s). In SR MPLS the prefix is always reachable in algo 0.

In IP flex-algo, the prefix is only associated with a single algo.

thanks,
Peter


Aijun Wang
China Telecom
On May 17, 2022, at 19:24, Peter Psenak <ppsenak@cisco.com> wrote:

Hi Aijun,

please see inline:


On 17/05/2022 04:10, Aijun Wang wrote:
Hi, Peter and Acee:
Then the key issues are the node’s capabilities negotiation within one area. Right?
To deploy the flex-Algo and ensure the forwarding paths are available,  should the nodes within one area be all upgraded in advance?


absolutely not. That has never been a requirement for flex-algo. It can be deployed incrementally.

 If so, why we should still worry about the legacy router? If not, how the operators confirm/assures there will be available paths when apply one flex-algorithm? I think it will be a disaster when only some of routers within the area to support some of flex-algorithms.

no, it will work just fine. Same as if not all routers participate in the particular flex-alago. That is actually one of the deployment scenarios that I've seen being deployed - using flex-algo to create multiple specific planes with a subset of routers only.


Not every node should participate each flex-algorithm, but every node should support the deployed flex-algorithm.

no, that is absolutely not a requirement.


If the above conditions are not met, such algorithm specified prefixes shouldn’t be advertised in any node.
Based on the above rule, no possible loop will occur. The standard will be also simplified.
Or else, why we have the node capabilities advertisements?

there is no negotiation of the flex-algo support. Only the participation in flex-algo is advertised.

thanks,
Peter

Aijun Wang
China Telecom
On May 17, 2022, at 01:24, Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org> wrote:

Aijun,

please read the responses from Les and myself on this matter. We can not use legacy advertisement of prefix for IP algp prefixes, because legacy routers would treat this as valid advertisement of prefix in algo-0. If that happens routers with IP algpo support would calculate the path on a different topology than the routers that do not support IP algo. That at the end would result in permanent loops.

I don't know what else to add. Seems obvious to me.

thanks,
Peter




On 16/05/2022 17:35, Aijun Wang wrote:
Hi, Acee:
I am curious that you are so hurry to forward this document.
The updated document just describes the followings: (https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo-06#section-6 <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo-06#section-6>)
“To be able to associate the prefix with the Flex-Algorithm, the
   existing prefix reachability advertisements can not be used, because
   they advertise the prefix reachability in default algorithm 0.
   Instead, a new IP Flex-Algorithm reachability advertisements are
   defined in IS-IS and OSPF.”
If the above statement is valid, then why the FAPM defined in the base document can be the sub-TLV of existing prefix advertisements?
Please also refer to the IANA allocation table https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-prefix-reachability  <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-prefix-reachability>
And, I see no any clue of different flex-Algo will influence each other:
If the router doesn’t support FAPM sub-TLV(doesn’t not support flex-Algo) or the FAPM sub-TLV doesn’t present in the prefix advertisements , the prefixes will be calculated in algorithm 0. If the router support FAPM sub-TLV(support flex-Algo) and FAPM is present, the associated prefixes will be calculated in the appointed Flex-Algorithm.
What’s the difficulty?
I have also noticed your statement in the document write up, but you and the authors’ responses to the concerns are unreasonable.
Should the AD make the final judgment and give one reasonable explanation?
I respect the works of the authors and all the reviewers’ and shepherd’s efforts, but think this is not the right direction to accomplish the aim.
Aijun Wang
China Telecom
On May 16, 2022, at 19:50, Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org> wrote:

Hi Aijun,

We need to support mixed deployments of routers that do and do not support flex algorithm and in these deployments the default algorithm, i.e., algorithm 0, computation must not be impacted. This is clearly stated in the draft. Your suggestion is noted but what you are suggesting doesn’t satisfy these requirements.

Thanks,
Acee

*From: *Aijun Wang <wangaijun@tsinghua.org.cn>
*Date: *Saturday, May 14, 2022 at 11:19 PM
*To: *Acee Lindem <acee@cisco.com>
*Cc: *"Peter Psenak (ppsenak)" <ppsenak@cisco.com>, Ketan Talaulikar <ketant.ietf@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>, "draft-ietf-lsr-ip-flexalgo@ietf.org" <draft-ietf-lsr-ip-flexalgo@ietf.org>
*Subject: *Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

Hi, Acee and Peter:
I don’t still think this document is necessary, unless you can answer the following questions clearly:
1) Section 5 about the “Advertising IP Flex-Algorithm Reachability” are not necessary, since every FAD has need advertised in the FAD advertisements. There is no such participations advertisements for SR and SRv6 dataplane.
Only the node participations should be advertised, as that described in the base document.
2) Section 6 about the “Advertisements IP Flex-Algorithm Reachability” is also redundant. The FAPM defined in the base document can transfer the same information, what’s the reason to define the new one?
3) Section 7 can be added to the section 14 “Flex-Algorithm and Forwarding Plane” of the base document. This section just describes how to apply the Flex-Algorithm to different data plane, why not use the FAPM directly to achieve such goal? No new TLV/sub-TLVs are needed.
4) There is no more additional information for section 8-10, compared to the base document.
5) For the IANA part of IS—IS, redundant information will be exist in two code points. The inconsistency will be emerged later when the additional sub-TLV is added under this code point.

In conclusion, reusing the FAPM is the right direction to solve the mentioned use case in the updated draft.

Aijun Wang
China Telecom

On May 14, 2022, at 04:29, Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org> wrote:

Hi Peter,

Thanks for addressing the WG last comments relating to terminology and IGP flex-algorithm data-plane granularity. I also have some editorial comments attached. These include:

   1. Remove "new" from the text since these specifications will not be new when they are published.
   2. Fix the reference to the OSPFv3 Router Information Opaque LSA. As you know, there are no opaque LSAs in OSPFv3 since OSPFv3 natively supports LSA compatibility.
   3. Replace "ISIS" with "IS-IS".
   4. Use American English spellings consistent with RFC style.

One comments, for situations where we don't install any route in the data-plane, should we recommend logging an error? For example, in RFC 7684, we say:

           This situation SHOULD be logged as an error.

I was tempted to hyphenate "Flex-algorithm specific" and "algorithm specific" but didn't since they aren't in the base Flex-Algo specification.

Thanks,
Acee





On 5/13/22, 9:59 AM, "Lsr on behalf of Peter Psenak" <lsr-bounces@ietf.org on behalf of ppsenak=40cisco.com@dmarc.ietf.org> wrote:

   Hi Ketan,

   sure, thanks for catching those, I'll fix them in next revision.

   thanks,
   Peter


   On 13/05/2022 15:32, Ketan Talaulikar wrote:
Hi Peter,

Thanks for your updates to the draft and your responses below.

I would like to point out a few remaining points to be fixed/addressed.

a) There is a discrepancy regarding the size of the Metric field for the
OSPFv2 IP Algo Reachability sub-TLV between the figure and the text
description. The text needs to be fixed to reflect 4 octets size.

b) For the OSPFv3 IP Algo Prefix Reachability sub-TLV the Type should be
2 octets and the discrepancy in the sub-TLV name in the Figure needs to
be corrected. Length should now become 8.

c) The references to the sections of draft-lsr-flex-algo in this
document need corrections in Sec 7 ? In general, I think the references
to the base draft sections 11, 12, and 13 (except that M-flag is always
used) would be helpful.

Thanks,
Ketan

On Wed, May 11, 2022 at 3:20 PM Peter Psenak <ppsenak@cisco.com
<mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>> wrote:

   Hi Ketan,


   please see inline (##PP):

   On 11/04/2022 08:25, Ketan Talaulikar wrote:
Hello All,

Following are some comments on this draft:

1) Is this draft about opening the use of all IGP Algorithms for IP
(Algo) Routing or intended to be specific to Flexible Algorithms
   (i.e.
algo 128-255) alone. I think it is important to specify the scope
unambiguously. Perhaps it makes sense to restrict the usage in this
particular document to FlexAlgorithms alone. If not, the draft
   probably
needs an update and we need to also cover algo 1 (Strict SPF)
applicability and update the text to refer more generically to
algo-specific IP routing.

   ##PP
   Done


2) The relationship between the algo usage for IP FlexAlgo and other
data planes (e.g. FlexAlgo with SR) is not very clear. There arise
complications when the algo usage for IP FlexAlgo overlap with other
(say SR) data planes since the FAD is shared but the node
   participation
is not shared. While Sec 9 suggests that we can work through these
complications, I question the need for such complexity. The FlexAlgo
space is large enough to allow it to be shared between various data
planes without overlap. My suggestion would be to neither carve out
parallel algo spaces within IGPs for various types of FlexAlgo data
planes nor allow the same algo to be used by both IP and SR data
   planes.
So that we have a single topology computation in the IGP for a given
algo based on its FAD and data plane participation and then when it
comes to prefix calculation, the results could involve
   programming of
entries in respective forwarding planes based on the signaling of
   the
respective prefix reachabilities. The coverage of these aspects in a
dedicated section upfront will help.

   ##PP
   this has been discussed previously in this thread.



3) This draft makes assertions that IGP FlexAlgo cannot be deployed
without SR. This is not true since the base IGP FlexAlgo spec
   explicitly
opens it up for usage outside of the SR forwarding plane. We already
have BIER and MLDP forwarding planes as users of the IGP
   FlexAlgo. My
suggestion is to remove such assertions from the document. It is
sufficient to just say that the document enables the use of IGP
   FlexAlgo
for IP prefixes with native IP forwarding.

   ##PP
   Done


4) The draft is mixing up "address" and "prefix" in some places. IGP
path computation is for prefixes and not addresses. There are a few
instances where "address" should be replaced by "prefix".
   References to
RFC791 and RFC8200 seem unnecessary.


   ##PP
   Done


5) The draft does not cover the actual deployment use-case or
applicability of IP FlexAlgo. The text in Sec 3 is not clear and
insufficient. What is the point/use of sending traffic to a
   loopback of
the egress router? Perhaps it makes sense in a deployment where
   IP-in-IP
encapsulation is used for delivering an overlay service? If so,
   would be
better to clarify this. The other deployment scenario is where
"external" or "host/leaf prefixes" are associated with a FlexAlgo to
provide them a different/appropriate routing path through the
   network.
Yet another is the use of IP FlexAlgo along with LDP. Sec 9 does not
address the topic well enough. I would suggest expanding and
   clarifying
this and perhaps other such deployment use cases (or
   applicability) in
the document in one of the earlier sections to provide a better
   context
to the reader.


   ##PP
   Done



6) It would be better to move the common (i.e. not protocol
   specific)
text from 5.1 and 5.2 under 5. This might also apply to some
   extent to
the contents of sec 6.


   ##PP
   Done. For section 6, I would prefer to keep it in the protocol specific
   sections.


7) Most of the text with MUSTs in sec 5 doesn't really make sense in
repeating - this is covered in the base FlexAlgo spec already.
   The only
key/important MUST is the one related to using separate algo for IP
FlexAlgo over SR data planes. See my previous comment (2) above.

   ##PP
   I prefer to keep the MUSTs there


8) Sec 5.1, the SHOULD needs to be MUST in the text below.

   A router receiving multiple IP Algorithm
   sub-TLVs from the same originator SHOULD select the first
   advertisement in the lowest-numbered LSP and subsequent
   instances of
   the IP Algorithm Sub-TLV MUST be ignored.

   ##PP
   Done.



9) Sec 5.1, I would suggest changing the following text as
   indicated.
Also, perhaps add that the algo 0 MUST NOT be advertised and a
   receiver
MUST ignore if it receives algo 0.
OLD

   The IP Algorithm Sub-TLV could be used to advertise
   support for non-zero standard algorithms, but that is outside the
   scope of this document.

NEW

   The use of IP Algorithm Sub-TLV to advertise support for
   algorithms

   outside the flex-algorithm range is outside the
   scope of this document.

   ##PP
   Done



10) Sec 5.1, the SHOULD needs to be MUST in the text below

   The IP Algorithm TLV is optional.  It SHOULD only be
   advertised once
   in the Router Information Opaque LSA.

   ##PP
   Done



11) Sec 6. The following text is better moved into the respective
protocol sub-sections. OSPFv3 is not covered anyway by it.

   Two new top-level TLVs are defined in ISIS [ISO10589
   <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#ref-ISO10589
   <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#ref-ISO10589 <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#ref-ISO10589>>>]
   to advertise
   prefix reachability associated with a Flex-Algorithm.

   *  The IPv4 Algorithm Prefix Reachability TLV

   *  The IPv6 Algorithm Prefix Reachability TLV

   New top-level TLV of OSPFv2 Extended Prefix Opaque LSA
   [RFC7684  <https://datatracker.ietf.org/doc/html/rfc7684
   <https://datatracker.ietf.org/doc/html/rfc7684 <https://datatracker.ietf.org/doc/html/rfc7684>>>] is
   defined to advertise prefix reachability associated with a Flex-
   Algorithm in OSPFv2.

   ##PP
   Done


12) Sec 6.1 & 6.2. There is no discussion regd the use of the Prefix
Attribute Flags sub-TLV with the new top-level TLVs.

I think their usage MUST (or at least SHOULD) be included as it
   helps
determine the route type and prefix attributes that

have proven to be quite useful for various use cases and deployments.

   ##PP

   Why? We have a text that says:

   "This new TLV shares the sub-TLV space defined for TLVs 135, 235, 236
   and 237."

   Why do we need to describe the usage of the specific sub-TLV?



13) Sec 6.2 what happens when the same prefix is advertised as SRv6
Locator as well as IPv6 Algo Prefix (same or conflicting algos).
   Perhaps
both must be ignored?

The same applies for OSPFv3 as well.

   ##PP
   Done



14) Sec 6.3, OSPFv2 MT-ID reference should be RFC4915. Perhaps
   the range
of MT should be mentioned since it is a 8 bit field here.

   ##PP
   Done



15) Sec 6.4, the metric field in the sub-TLV has to be 32-bit. While
24-bit is ok when the FAD uses IGP metric, it will not suffice
   for other
IGP metric types.

   ##PP
   Done



16) Sec 6.3 & 6.4, the conflict checking with base algo 0 prefix
reachability cannot be limited only to the OSPFv2/3 Extended LSAs
   but
should also cover the base fixed form >
OSPFv2/v3 LSAs. We could use a more generic term like "normal prefix
reachability" advertisements perhaps to cover the different LSAs?

   ##PP
   Done




17) Sec 7 and 8, suggest to not use the term "application" to avoid
confusion with ASLA. My understanding is that there is a single
   FlexAlgo
application when it comes to ASLA.

Perhaps the intention here is "data plane" ?

   ##PP
   Done



18) The relationship between the BIER IPA and this draft needs some
clarifications - should the BIER WG be notified if they want to
   update
draft-ietf-bier-bar-ipa?

This (in some way) goes back to my comment (2) above.

   ##PP
   I don't see the relationship to BIER IPA here.



19) Sec 8, what prevents the use of IP FlexAlgo paths programmed
   by LDP
as well. Or if the intention is to use them strictly for IP
   forwarding only

then this needs to be clarified.

   ##PP
   nothing prevents someone to advertise LDP label for the IP algo-prefix
   and use it with the labeled forwarding. I don't see a problem. But this
   specification does not specify any of it.



20) The following text in Sec 9 is about using the same FlexAlgo
   (with a
common definition) for multiple data-planes at the same time. The
   key is
that we only are able to use

prefix in one algo/data-plane? I am wondering if we can improve this
text to bring this out in a better way. Or altogether remove this
   if we
agree to not allow sharing of algo

between different data planes to keep things simple.

   Multiple application can use the same Flex-Algorithm value at the

   same time and and as such share the FAD for it.  For example
   SR-MPLS
   and IP can both use such common Flex-Algorithm.  Traffic for
   SR-MPLS
   will be forwarded based on Flex-algorithm specific SR SIDs.
   Traffic
   for IP Flex-Algorithm will be forwarded based on Flex-Algorithm
   specific prefix reachability announcements.

   ##PP
   Done.

   thanks,
   Peter


Thanks,

Ketan



On Fri, Apr 8, 2022 at 12:38 AM Acee Lindem (acee)
<acee=40cisco.com@dmarc.ietf.org
   <mailto:40cisco.com@dmarc.ietf.org <mailto:40cisco.com@dmarc.ietf.org>>
   <mailto:40cisco.com@dmarc.ietf.org
   <mailto:40cisco.com@dmarc.ietf.org <mailto:40cisco.com@dmarc.ietf.org>>>> wrote:

   This begins a WG last call for
   draft-ietf-lsr-ip-flexalgo-04.  The
   draft had a lot of support and discussion initially and has been
   stable for some time. Please review and send your comments,
   support,
   or objection to this list before 12 AM UTC on April 22^nd ,
   2022.____

   __ __

   Thanks,
   Acee____

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



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


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

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



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