Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"
John E Drake <jdrake@juniper.net> Thu, 14 April 2022 13:22 UTC
Return-Path: <jdrake@juniper.net>
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 6312C3A19C8; Thu, 14 Apr 2022 06:22:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level:
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=JfuKbclZ; dkim=pass (1024-bit key) header.d=juniper.net header.b=CLjTShfO
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 SnjKVO9JrUzB; Thu, 14 Apr 2022 06:22:46 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40DCF3A1998; Thu, 14 Apr 2022 06:22:41 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 23E4ntLM018060; Thu, 14 Apr 2022 06:22:40 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=a2MeEKxNYPx1pdPOioJZ58Ow6T/KmiiQPE9/9GMPJQ0=; b=JfuKbclZ+QC6FTOKo9LV6kUX8Kran+DqEg70HumXNgPbOJdbY/YSDfW5JHsUOQH9p1ZQ YNuLYR1AYjfE4MwL0xryIFTnHPioK5ZlJlOdzEQ7fSNneiW7PP7LHq6UuGz4aj/nDVmO keU8j7k4+isWwPTJOAaaeCYp7GV7Ga/GlwdSSQDQfyCcxkcBvZvPv4oMntfCVNCWNSSf BXIUIfY61OL4MkCx/I5uBqUbK6NAKDKMYgq7rXdZ6LvQ+dwAziE/ztXRZSZ9kCaAaS3B sSIgYbC4/Bx4t3IPZKRllOsuIM83Zpt2m5Ia9dNzc4VOyKTXPMg0viXUI4ZSmAurgqNu Sg==
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2105.outbound.protection.outlook.com [104.47.70.105]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3fecx68tx0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Apr 2022 06:22:38 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UP8PSPB2iQFl7tkxpvhmNycb3WjdLb+i49h2S6qs2z/xh2zJxvgYWf7EzyctHtzLQrxmx0MmUxm9HO8Owqeg/A4qco/kbZfIb+be/LJ7TGWrxKfU3/51YOb/bY7pOb/DkYGVYbYEU6zlQiUDuPoLfWbGMWIU/RD5ANC8JRWFDDR/CpMBNLh85p8XEy2e6+AAMsBlenj9cDdyD1L6jLkOHe+NM7omcN3Pz/OYlwVCZhIwzj77PH6i47s3rXaBDtpENUv1a/plIXNTFiDSP5xt0kfKRZA4NlEq/XcuNe/UXqpfSOvbqutAg5ZCnW2EObrs5bGEGxhsAVxSfmDh8LGMlw==
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=a2MeEKxNYPx1pdPOioJZ58Ow6T/KmiiQPE9/9GMPJQ0=; b=HOCW4w0DV6fIyKlAbOSJ24jLwhwKE88fC3F3+OWKR377eWWErwDrug1P6U8Y4ioSGWllpl1FtTUeUoZWb7J8GQr/lg/LtcgosgpySPZwlY1oA9VEKdat43CbXM8n4BMFJ7DxU0jq+vDwOhdQLTChT1JcCNA2/xP37EEfDDifZm4SlXSWRxD5ruM3a3fWDgI/xMFpzyIlNmimLdFdJLafA1wAAibvkWRxpf8/QDgGQFGHuTLY16LJ1VwU18N3yxBvQh8AijqoVGTY/u8kSs7amhBLbrwGK+tmomtN9mOi+92m8cuhfdyK8NOkcSHgPXIQuP+T4fqsWkf5fitoviyGoQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a2MeEKxNYPx1pdPOioJZ58Ow6T/KmiiQPE9/9GMPJQ0=; b=CLjTShfObjgGJ8wVekSYtiD5SrloWum63+9ScWwaq2ca8dlHEFNKt/HZIoQ+7LK2+LYJy9LXTtJAZHzsXM07Bv5wrP3ari2NfO1AG3mMxymvJ3N1aWfTxIdeWYsZAMZ9ShScz1xjhjpZTLkGDFmoCKkmeAJMxSHDejPHqaOq5gE=
Received: from BY3PR05MB8081.namprd05.prod.outlook.com (2603:10b6:a03:366::15) by BN6PR05MB3474.namprd05.prod.outlook.com (2603:10b6:405:3e::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.18; Thu, 14 Apr 2022 13:22:35 +0000
Received: from BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::8db8:fd72:6beb:3657]) by BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::8db8:fd72:6beb:3657%9]) with mapi id 15.20.5186.006; Thu, 14 Apr 2022 13:22:35 +0000
From: John E Drake <jdrake@juniper.net>
To: Robert Raszuk <robert@raszuk.net>, Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>
CC: Ketan Talaulikar <ketant.ietf@gmail.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "draft-ietf-lsr-ip-flexalgo@ietf.org" <draft-ietf-lsr-ip-flexalgo@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"
Thread-Index: AQHYSrKu6FNK67UObUGS/u+m71Clk6zqRI8AgAATxgCAAGvOgIABIEIAgAFcXACAADbxAIAAGpQAgAADlgCAAFFHAIABJbKAgAAfuACAAEKl4A==
Date: Thu, 14 Apr 2022 13:22:35 +0000
Message-ID: <BY3PR05MB808120DF15629133EED09305C7EF9@BY3PR05MB8081.namprd05.prod.outlook.com>
References: <36E526F2-34CB-4C0A-84C2-79A50D9D4C36@cisco.com> <CAH6gdPwrshSVGNsjJVqND8kpNBTBQWicggEz_qyP0DtMYY5wjg@mail.gmail.com> <b6250861-a35d-2a47-6701-194b074e7233@cisco.com> <CAH6gdPwbL5qWX_GXfuv5YL4mRL9xUy3p9wc7an-FbnzpTc0U9A@mail.gmail.com> <46e4c6c1-4ae6-a628-ba27-daa5381c0ac0@cisco.com> <CAH6gdPwS97eEgRQsX16=QfR_yEiPi0WPWGt6PM0XawE5v07exA@mail.gmail.com> <b5def3f0-9bb4-84d6-5fe2-4ba3091dcb95@cisco.com> <CAH6gdPyJxppbyjhYBxX4R+LJvt-TdFfvjmPHJ-PHLOoQBPeO2w@mail.gmail.com> <e7cc29b8-00fb-6294-5c87-4409428b8ae2@cisco.com> <CAH6gdPzQ-nPuwoMm1HpK8b6Fxbh=MkD-+D01DLT2DV4QUHc6TA@mail.gmail.com> <005681e5-14f3-ecd6-de29-b09a92f87682@cisco.com> <CAOj+MMGmkvFV-KnzQnZi_46nnvVWo5cPM0xffxSHhLUSaaAFEQ@mail.gmail.com>
In-Reply-To: <CAOj+MMGmkvFV-KnzQnZi_46nnvVWo5cPM0xffxSHhLUSaaAFEQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.6.401.20
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2022-04-14T13:22:33Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=678f3ca5-ae3a-4b4c-8928-369d3a497877; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c374bfbc-a68b-4f3e-f62e-08da1e19d6bf
x-ms-traffictypediagnostic: BN6PR05MB3474:EE_
x-ms-exchange-atpmessageproperties: SA|SL
x-microsoft-antispam-prvs: <BN6PR05MB34742D58C93F8122269FEA22C7EF9@BN6PR05MB3474.namprd05.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: RKUNTH3P05uPjW8sOrUiO5D/3ESLbQoEC7t7N6mitTFFhAMe4zxVppV+s1j4erUt0MEmypNgNAlq6WW5j+B2xQXlRFgiSubzs8iLVC1qbxWqoZ7jSNxZ3QX8c0SE8LQVdGTb1WME9tSSGT5VOllLLqbebjG3dXWevRS19i4DUNV7qrSurt3/CcEnQtfV4zV8gGgK/P23Zd/9dh7p+nADcF2QYBHNSkyvDT/VPoYma+wcLfObDjxIBefFSrxiy82b5cDxwSRAUp2o4csty9XjokSzpEpsAtPY+KIqvKX5HTMtBGDTyovxNjw8KaFB1fOYsMM585OibZvmjn3E6exfIK3Y8UZZmASVZZOCVSSX0w7lo6hIQM80o/clyqf+CqrXGJsrnRelZRnBxCotRh+FkDA9N0U5N/Ido+p+9fDGyh5i37lan4IAJMzaQ6PP5oeaxYNAYD9tQMfj/UcWYFyDYDC7oQTcuhX3nKRPO+6aOMHToUlFBW+ixBomZRcIgk3fZQzKrCxDyRQLjgMmTFfx8+r7+kgWb1RLIvGnND9UmVtn12l1Tj1AOeHF7+27i06hIu8iBKeNBs1QZv4HxZ+ECQi69W8Os2SBZaYw+mppJzF9nyfxtjG3QkNdf97oUm7d02Ok0k+x1J1Q01PsFduPV79DoWVuIjq6/y5LFfJWIzbFqTsjrd9M5HhUbOblv533WBYvebFzBI7Z2d3EMkbOTpetH5soseDZtKMBUuqnhM64+67wqZdPGEdydfBO2fCOXPN0H0SzHNy/GwH5u4GLGezDueoDKzs4xsyQkV9izqg=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR05MB8081.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(316002)(8676002)(33656002)(8936002)(9326002)(66556008)(66446008)(66476007)(64756008)(53546011)(4326008)(66946007)(76116006)(54906003)(30864003)(110136005)(5660300002)(52536014)(71200400001)(86362001)(508600001)(26005)(966005)(6506007)(7696005)(38100700002)(122000001)(166002)(9686003)(55016003)(2906002)(186003)(38070700005)(83380400001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: a+GBGUejJyGuOBUOmldDVhyce/UcfyLbuu1IYJ6YKqFgMQTN1k4vJQO05rdDhNvAMVTiPTW0MXMFobFeqFYiL6TrzAM+x8YzyJ12/adlzGGWK3qNPI6UMUV3eOIIod8bGgclXwPSKx8mBnvviSfKRl3nCLSSwGg7jZbz44snDIx8BvlzskLl7SSmV3c2P/LP6raPjs7z69a2RhV6hJ/yDw2b/8QYl0Mti/FBMWIxVch/9V82dXjhfgBirR0KaHxW84CZVKf0sR463UlmBWSiINhRJRf89USUEtL8YMsrVglhbAl4EKCYy1PGoIcF46nagsck44fFQ8/BgGmdIb4clRYNfcLn3t0U1sG5F/LTIG7QnfOCvhbqOl4wLQVBQik3d7AapzjR6FVpQw1ZQfDP7UXUtIrFEcC75N4VxLxKUluE8iQRzK+6hYTodlj7C3XzGz3BseM6wt1fFua/HSRbC2C4zRlL4HwFeT8cBQZnOp5cR5hUhJUhRBe+w4Ynnk295IGQ13goKjVqezzQ23qcdLIqreZMqVvVdM0ANGPOvr6t9377PHI1C8YAOUzqDFEMYaOaCDDxG+/JKF/wDeLvAjwKJcMu3E3XarPlxgu7g7KGP4agK+THQqkb7jLTOELkLBRCKSW/G5uG9EZe03q+qoFanL8p4bluma4XjZ//BjOwnFyP/6s2As68m1tqV55/d6KKD9fSLaVADBYUWdkOIU8xc7mAPiLnihqSGu32S/0roPndX8E0HPyXDyNIZxbZO9tV5YsTX7OqiwAiY+zl7HkOIWEHhFlKcBCttoq0Dc7a7DOEjJNMTEwQJZmK3lv1NeXlllkfxd+HOYT9Zm7DV5ox7cSV3crJCjxtNQibQVld5+E56VBlecDL7ALoNG1scLqqkjHaB1B2Aav4ercx2EFgTJMBscIrLwU5s2uElDIE5lMb4aAgbgAleqJ0obfFhTaZy53TARB2xHmVsz3JCE/Yz1tbvA6eGXm6cApjt6e8SfXNeLtwFtmiOViwUeqBUOPh4ii13xAZLCZP6I09tclrO+hHptZzPsEy4KHrZfYGNzsSmzovTNE/IBFntTJ95cgfScH6VWWq32VwVvJFhKCIJ2qO5Q3JVJm+IuRQxSWTlLdCm55tdzowoAF4HiAaWs4bw55fo/B1GuO49vIIsrEOyhUGDbmzaKcH77xA6CzWqpmw7O3oJZ8Z+Wu2TBehb3f/yx6F/XKRpfu2lj/vt90piEHl9TlYecVIAZeq63xvFUAuxFdqeit+13WrYONFl6aZQ45RkDckRl2gCPIuIzzQlQYG+2A9nmHpN00FKR8HBgdcte+w9kGVbvzkXQQm66w2ZpIhxB5BSsP1ec6szq0JBqYgMv5CqXf8ZBydSSBB1quGhAEYjZbo8CfsxBB0h92va59zpSUFBDULisirQKnxEOckPucUgUEJTPn3H7kMcb/x/4Lf5cxvxdn/q/M+0WS2s7Ww/basH7M3oT+B2iyL4uBGzlZ+yQjsXUAqW3rIDeamghnvPrxCVX6zeIOBMy5lXF1RClABrNKDyVy01RxOGbpTUHWCx4jXWBmcNTZZQoxBpErGLJ377aa8d+Kh16GoPe/3w0UZnm9FHMz2UOGG9xpI+nSor2FsNiiEIFipxhpMUNqcIGImL4piIZXfvm7d+WSYBO08gx8rRW29asb6wM9YeX1vWbLa57FzblU+33kTcagO1ZTkrIJooW7vFI9n3J3nv8+PfyOzzcmU4w==
Content-Type: multipart/alternative; boundary="_000_BY3PR05MB808120DF15629133EED09305C7EF9BY3PR05MB8081namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY3PR05MB8081.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c374bfbc-a68b-4f3e-f62e-08da1e19d6bf
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2022 13:22:35.2110 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 6NXyndP/Xhm2/rR7Tmh9sKBmvQR1QEIxN0244i9NXLbR3WH53FzfSKcW6gRjChP74BBEh32nGCQVIDb/YI9dYw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3474
X-Proofpoint-GUID: -nx-fcvdVgQduYUeufHS-6gudj6AfMVu
X-Proofpoint-ORIG-GUID: -nx-fcvdVgQduYUeufHS-6gudj6AfMVu
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-04-14_04,2022-04-14_01,2022-02-23_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 bulkscore=0 malwarescore=0 suspectscore=0 lowpriorityscore=0 phishscore=0 impostorscore=0 mlxscore=0 clxscore=1011 priorityscore=1501 spamscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204140073
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/OPlT-2k4aG8_ADOBAIhQwkwbyX4>
Subject: Re: [Lsr] 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.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, 14 Apr 2022 13:22:54 -0000
Hi, In the IETF context I have always associated 'data plane' with packet forwarding, so I think Peter's suggestion is fine. Yours Irrespectively, John Juniper Business Use Only From: Lsr <lsr-bounces@ietf.org> On Behalf Of Robert Raszuk Sent: Thursday, April 14, 2022 5:21 AM To: Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org> Cc: Ketan Talaulikar <ketant.ietf@gmail.com>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>; draft-ietf-lsr-ip-flexalgo@ietf.org; lsr@ietf.org Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" [External Email. Be cautious of content] Hi Peter, Term "data-plane" usually means physical resources links, switch fabric, ASIC etc ... so I am afraid it will also generate confusion with default data plane. How about two alternatives: - custom/logical topology - logical-data-plane Thx, Robert. On Thu, Apr 14, 2022 at 9:27 AM Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote: Hi Ketan, On 13/04/2022 15:56, Ketan Talaulikar wrote: > Hi Peter, > > I would still reiterate the need to clarify the usage of "application" > terminology in the base FlexAlgo spec. We don't need to call it > "data-plane", I was suggesting "forwarding mechanism" or it can be > something else as well. I will replace with data-plane. That's the best from what we have. thanks, Peter > > Just my 2c > > Thanks, > Ketan > > > On Wed, Apr 13, 2022 at 2:35 PM Peter Psenak <ppsenak@cisco.com<mailto:ppsenak@cisco.com> > <mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com>>> wrote: > > Hi Ketan, > > please see inline (##PP4): > > > On 13/04/2022 10:52, Ketan Talaulikar wrote: > > Hi Peter, > > > > I will not press this point further if I am the only one that > finds this > > complexity without any benefit. :-) > > > > Please check inline below for some clarifications with KT3. > > > > > > On Wed, Apr 13, 2022 at 12:47 PM Peter Psenak <ppsenak@cisco.com<mailto:ppsenak@cisco.com> > <mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com>> > > <mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com> <mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com>>>> wrote: > > > > Hi Ketan, > > > > > > please see inline (##PP3): > > > > On 13/04/2022 06:00, Ketan Talaulikar wrote: > > > Hi Peter, > > > > > > Please check inline below with KT2. I am trimming everything > > other than > > > the one point of continuing debate. > > > > > > > > > > > > > 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 > > > > I strongly disagree. > > > > > > > > FAD is data-pane/app independent. Participation is > > data-plane/app > > > > dependent. Base flex-algo specification is very > clear > > about > > > that. That > > > > has advantages and we do not want to modify > that part. > > > > > > > > > > > > KT> No issue with this part. > > > > > > > > > > > > Topology calculation for algo/data-plane needs > to take > > both > > > FAD and > > > > participation into account. You need independent > > calculation > > > for each > > > > data-plane/app in the same algo. > > > > > > > > > > > > KT> So, an implementation now needs to potentially > support > > > performing > > > > multiple topology computations for each algo. This is a > > > complication for > > > > which I do not see the justification. Why not just pick > > different > > > > algorithms for different data planes for those (rare?) > > > deployments where > > > > someone wants multiple data planes? > > > > > > ##PP2 > > > flex-algo architecture supports multiple > apps/data-planes per > > algo, > > > with > > > unique participation per app/data-plane. That requires > > per-algo/per > > > app/data-plane calculation. What is complicated on it? > > > > > > > > > KT2> This specific and precise statement that you have > provided > > is not > > > covered in either draft-ietf-lsr-flex-algo or this > document. For > > > starters, this needs to be clarified and covered so that > it gets the > > > attention of any reader during the review. This has > implications for > > > implementations. > > > > ##PP3 > > sure we can add it explicitly there, but if you read the base > flex-algo > > draft carefully, it is quite clear. I will add that exact > statement in > > the next re-spin of the base spec. > > > > > > KT3> Thanks. I think we may also need to carefully scrub the use > of the > > term "application" since it seems to bring out different > interpretations > > thanks to the "application" in ASLA. It is better if we use the term > > "application" only in the same semantics as ASLA - this means that > > FlexAlgo is a single "application". We can perhaps use the term > "traffic > > flows" or "service flows" as an alternate for "application flows" > that > > are steered over or use a FlexAlgo. And then when it comes to Node > > Participation in a FlexAlgo, we could use the term "FlexAlgo > Forwarding > > Mechanism" instead of "Applications' Forwarding for FlexAlgo". > Thoughts? > > ##PP4 > the term application is used in the base flex-algo spec from day > one. It > was chosen because it was generic enough to describe whatever the > flex-algo may be used for down the road. We could have used > 'data-plane' > instead, but it could be quite restrictive IMHO. > > > > > > > > > > > > > If your implementation does not want to support it, > fine, but the > > > architecture allows it and there is/are implementation(s) > > that already > > > support it. This is not defined in this draft, it's > defined > > in base > > > flex-algo spec. > > > > > > > > > KT2> I am not sure if it is really an option for > implementation > > once it > > > is in the specification. And this is not about "my" > > implementation :-). > > > So it is not that because some implementations can do (or > does) > > it that > > > it should be in the specification. The determination on > whether it > > > should be in a specification needs to be based on the tradeoff > > between > > > requiring multiple computations per algo with the potential > > benefit or > > > use case that is enabled by it. > > > > ##PP3 > > again, this is how things have been defined from day one, and > for a > > good > > reason. Requiring per app flex-algo even though I want to use > the same > > metric and constraints for both app would be inefficient. > > > > > > KT3> For my understanding, the only inefficiency that you are > referring > > to with the "separate algo per FlexAlgo forwarding mechanism" is a > > duplicate FAD advertisement. Am I missing anything else? > > ##PP4 > right. But the point is there is nothing that prevents multiple apps > using the same algo in the architecture itself. And I see no good > reason > for such restriction. > > > > > > > > > > > > > > > > > > > > > > > > > The fact that the same FAD is shareable between all > > apps has it > > > > advantages and use cases - e.g. if the > participation > > for algo > > > X is the > > > > same in SR and IP data-planes, one can use SR to > > protect IP > > > in that > > > > algo. > > > > > > > > > > > > KT> Would this protection use case not violate the base > > FlexAlgo > > > rule > > > > that the protection has to remain within the specific > > topology. > > > If there > > > > is an SR data plane, then why would one want an IP data > > plane as > > > well? > > > > > > ##PP2 > > > if the participation in two app/data-planes is the > same for > > the algo, > > > the resulting topology is the same. If your > implementation is > > smart, it > > > can only run a single computation for that case. There > is no > > violation > > > here whatsoever. > > > > > > > > > KT2> If the resulting topology is the same between SR data > plane > > and IP > > > data plane, what is the need to enable the IP data plane? > Why not > > just > > > steer the IP traffic over the FlexAlgo data plane? And > when it is > > not > > > the same topology, then we cannot really do the protection > for IP > > > FlexAlgo using SR FlexAlgo. So what is really the use case or > > benefit > > > for enabling this? > > > > ##PP3 > > I just gave you an example where this might be useful. You > may not like > > it, but it will have no impact on the defined architecture. > > > > > > KT3> Ack - we can agree to disagree on this. > > > > > > > > > > > > > > > > > > > > IP forwarding can be steered over the SR-based FlexAlgo > > topology > > > along > > > > with the protection provided by it. Am I missing > something? > > > > > > ##PP2 > > > topology for both primary and backup computation must > be the > > same. > > > > > > > > > KT2> I see the primary use case for IP FlexAlgo (or > another data > > plane) > > > to be that the data plane is used by itself. In the > (rare?) case > > where > > > multiple data planes are required to coexist, it is > simpler both > > from > > > implementation and deployment POV to use different algos. It > > would be > > > good to have operator inputs here. The only cost that I > see for > > this is > > > that the same FAD may get advertised twice only in the > case where > > it is > > > identical for multiple data planes. So I am still not > seeing the > > benefit > > > of enabling multiple (i.e. per data plane) computations > for a single > > > algo rather than just keeping it a single computation per algo > > where a > > > single data plane is associated with a specific algo. > > > > ##PP3 > > I really do not see the problem. As you stated above > repeating the same > > FAD for multiple algos would be inefficient. The beauty of > FAD is that > > it is app independent and can be used by many of them. > > > > If you like to repeat it, fine it will still work. But we do not > > want to > > mandate that in the spec. > > > > > > KT3> There is currently no normative text in the draft-lsr-flex-algo > > that specifies that an implementation needs to support a "per > flexalgo > > forwarding mechanism" computation for each algo. So when this > > clarification is added, can this be a MAY or perhaps a SHOULD so > that an > > implementation has the choice to perhaps not do this and still > remain > > compliant to the spec? > > ##PP4 > I'm fine to make that optional. > > thanks, > Peter > > > > Thanks, > > Ketan > > > > > > > > thanks, > > Peter > > > > > > > > Thanks, > > > Ketan > > > _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!TzTdj43IFN6fAOGdIoLWLPVget9auoAEB4GEhK3-KKwX2ecau0S1IyKViY2p4BA$>
- [Lsr] Working Group Last Call for draft-ietf-lsr-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Robert Raszuk
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Robert Raszuk
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Huzhibo
- Re: [Lsr] Working Group Last Call for draft-ietf-… Robert Raszuk
- Re: [Lsr] Working Group Last Call for draft-ietf-… John E Drake
- Re: [Lsr] Working Group Last Call for draft-ietf-… Robert Raszuk
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ron Bonica
- Re: [Lsr] Working Group Last Call for draft-ietf-… Dongjie (Jimmy)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Dongjie (Jimmy)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Les Ginsberg (ginsberg)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Les Ginsberg (ginsberg)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Parag Kaneriya
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- [Lsr] [Need AD’s Judgement and Explanation] Re: W… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Acee Lindem (acee)
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… John Scudder
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Acee Lindem (acee)
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Peter Psenak
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Acee Lindem (acee)
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Peter Psenak
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Peter Psenak
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Peter Psenak
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Acee Lindem (acee)
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… John E Drake
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang