Re: [Lsr] 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> Sat, 16 April 2022 21:54 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 185063A0C0B; Sat, 16 Apr 2022 14:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.594
X-Spam-Level:
X-Spam-Status: No, score=-9.594 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, 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=bCCC20yd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=oIFhr5WI
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 44RiqXTw3Z58; Sat, 16 Apr 2022 14:54:02 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB753A0C00; Sat, 16 Apr 2022 14:54:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63571; q=dns/txt; s=iport; t=1650146041; x=1651355641; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nx46UtR0XAO8jbgxAWqvf/hWEK0pINwdZMMikqZIv9A=; b=bCCC20ydNn2JNCNK8XRXmNz4I+5F3SE/fcjL3J3qeL7N+E/Shpleq4OB LZEc/CxVDOnssSUN5SnOHp73TtIcqZ0i9/t9OTCiXDjFs6sjZDY5SMJlq RohjK13tCCVdBdixfdRLbzgHoIYNkrY407tmGL1hnlDRqJhP3I/BsyTsE Y=;
X-IPAS-Result: A0ALAADTOVtimJxdJa1XAxYGAQEBAQEBBwEBEgEBBAQBAYIGBwEBCwGBIDEoLnwCWjlDhFSDSgOEWWCFD4MCA4sUhTKKd4EuFIERA1QDCAEBAQ0BATcMBAEBhQMCFoRoAiU0CQ4BAgQBAQEBAwIDAQEBAQEBAwEBBQEBAQIBBwQUAQEBAQEBAQEdBwYMBQ4QJ4VoDYZCAQEBAQIBEggDBgoTAQE3AQQLAgEGAgcHAwMBAgkYAQIEAwICAh8FDBQJCAIEAQ0EARsHgmIBgg5XAw0kAQ6RcY83AYE+AoofeoExgQGCCAEBBgQEgTsCDkGCfw0LgjgJgT0BgxCCfwOBJQEBgSCFfSccgg2BFAEnDBCCNzA+giFCAQEBAQGBKAESAQcxCQEFBwkICYMPN4IumwdbBmQEUQEBBSpiTQEeAT8NHZJagx+JbY4CkgtrCoNJixeINIY6hXwFLoN0nnuFZJR3gWcggimKVYNVkGsEC4R/AgQCBAUCDgEBBoFhOmtwcBU7KgGCPglIGQ+OIAwNCRWDO4UUhUp1AjYCAwMBCgEBAwmMXgEB
IronPort-PHdr: A9a23:/t1XNRQfb7543Bj8sgyuj/A5FNpso7vLVj580XJvo75Nc6H2+ZPkM QSf4Ph2l1bGUM3d7O4MkOvZta3sGAliqZaMuXwPatpAAhkCj8hFkwkpGsXQD0r9IbbjZDA7G 8IXUlhj8jm7PEFZFdy4aUfVpyi57CUZHVP0Mg8mTtk=
IronPort-Data: A9a23:USSc6KA9vDjMoxVW/+Pjw5YqxClBgxIJ4kV8jS/XYbTApG8ihGQFy WsdCmvTMvaOZ2H3Ldtya46y9E0OuceAnNNmOVdlrnsFo1CmBibm6XV1Cm+qYkt+++WaFBoPA /02M4WGdIZuJpPljk/F3oLJ9RGQ7onVAOukYAL4EnopH1U8FH5/0UgLd9MR2+aEv/DoW2thh vuqyyHvEAfNN+lcaz98Bwqr8XuDjdyq0N8qlgVWicNj4Dcyo0Io4Kc3fsldGZdXrr58RYZWT 86bpF2wE/iwEx0FUrtJmZ6jGqEGryK70QWm0hJrt6aebhdqiyA99qoJG/0nWXwNgW+sscF28 YhVusnlIespFvWkdOU1SRJUFWR1OrdLveKBKnmkusvVxErDG5fu66wxVwdtYstJoaAuXD8mG f8wcFjhajiKjO+76Lm6UeJrwM8kKaEHOatP6i48kWuJV6ZOrZbrQv6S/+ZV2xgLtNFNPqfBe dEbbR9+RUGVC/FIEg5HVM1h9AuyvVH7aCdwqV+Jq+ww+We75ABr2bbxddvYZtLPQd5P20eA4 2zC8nTwBh4dHN2S1TTD9Wij7sfMkD/yXp5UFbCk+NZlhVSSwioYDxh+fVuysPCzl1W3VMlaA 0MR8ysq66M18SSWosLVRRa0pjuPuQQRHocWGOwh4wbLwa3Ri+qEOoQaZhNNZ/gqhuAxfgwRj FXTuv34AgUyqLLAHBpx6YyohT+1PCEUK0oLaikFURYJ7rHfTGcb00KnojFLTfLdszHlJd3j6 2vQ/XRh3d3/meZOhvvkpQqY6965jsKRJjPZ8Dk7SY5MAulRXo+uZ4Wy5UPc656sx67GEwHR5 RDodyVihd3i4LmXnyCLBe4KBrzsurCOMSbXhhhkGJxJG9WRF5yLIN04DNJWfRoB3iM4ldnBO hK7VeR5v8c7AZdSRfUrC79d8uxzpUQaKfzrV+rPcv1FaYVreQmM8UlGPBDMjjGyyhBzy/tvY /93lPpA615HWMyLKxLrGI8gPUMDmkjSOEuKH8mglkT7uVZgTCfJEu5t3KSyghARtfPY/1q9H yd3PMqRwBIXS/zlfiTS6uYuwaMicxAG6WTNg5UPLIare1M+cEl4UqO56e5wIORNwvUK/s+Wp SvVchEDlzLCaYjvdF/ihoZLMu+1B/6SbBsTYEQRALpf8yF6P93+vftFKsNfkHtO3LUL8MOYh sItI62oasmjgByek9jBRfERdLBfSSk=
IronPort-HdrOrdr: A9a23:UMT1TKz8TkkLCSylqQauKrPxh+skLtp133Aq2lEZdPULSKKlfp GV88jziyWZtN9IYgBdpTiBUJPwJU80hqQFnrX5XI3SEzUO3VHIEGgM1/qb/9SNIVydygcZ79 YcT0EcMqy/MbEZt7eA3ODQKb9Jq7PrkNHKuQ6d9QYWcegAUdAG0+4NMHfjLqQAfnghOXNWLu v42uN34x6bPVgHZMWyAXcIG8LZocfQqZ7gaRkaQzY69Qinl1qTmf/HOind+i1bfyJEwL8k/2 SAuRf+/L+fv/ayzQKZ/3PP7q5RhMDqxrJ4dYyxY4kuW3bRYzSTFcFcso65zXQISSaUmREXee z30lUd1gJImjXsly+O0ELQMkLboUgTAjfZuC6laD3Y0JTErPZQMbsauWqfGSGpsHbI9esMo5 6ilQiixupqJAKFkyLn69fSURZ20kKyvHo5iOYWy2dSSI0EddZq3MYiFW5uYd899RjBmcsa+S hVfbbhzecTdUnfY2HSv2FpztDpVnMvHg2eSkxHvsCOyTBZkH1w0kNdnaUk7zs93YN4T4MB6/ XPM6xumr0LRsgKbbhlDONERcesEGTCTR/FLWrXK1X6E6MMPW7LtvfMkfgIzfDvfIZNwIo5mZ zHXl8dvWkue1j2AcnLx5FP+gClehT1Yd0s8LAp23FUgMyIeFOwC1zwdLkHqbrVn8ki
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.90,266,1643673600"; d="scan'208,217";a="887442828"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Apr 2022 21:53:58 +0000
Received: from mail.cisco.com (xfe-rcd-004.cisco.com [173.37.227.252]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 23GLrwAL010770 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Sat, 16 Apr 2022 21:53:58 GMT
Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Sat, 16 Apr 2022 16:53:57 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Sat, 16 Apr 2022 16:53:57 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S8d27r13XVxFE9KraAw0hYd/1TjCeY5mmHMHAJqLJiPFtMEgW3hvht8zIK7hgie52Gbw//x3eLD2ett3cGZQUA8mgVA5mkUPlBkj9KRXv5vVNU0UVdngAPYT4LJCxcsSqjXzUBtyJrOfbJ0eJyK+cjWoq5AFykjyRX/hbdddADsVfDObX9OM/Njwe8QBTrcjE+JROGvXO2q2torextAdKSg3Haf/E/pQTttTibKeAAhjYz/XedhkI6ObfkeMV/spvktp+6YE65tmq+4LZTm0zrbtlstJL/uJLTpL0RZB+GE/h/UlS6IoSPHuZ/9+Q8RBDzFD6PIiiWRqVuX48jqRPw==
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=nx46UtR0XAO8jbgxAWqvf/hWEK0pINwdZMMikqZIv9A=; b=Ve7URQu8avg6T+rLUdn9UPuE0ETRDIT9j2McZuCSKedDTup3RJKkhqywnSh+I4P7mK5AxUiMBYS0KXnqwN+91FMl79zB5aFxazSPGwLMefb0bJckOupTsAxAX0Eh56L+Tk+niLMduh5D7eNEYTQyc2Km++KHCIHnEgQ/aq+pjHZ+FZTNpg7rqrtAODq/pm8DJ3pKsgbcgUa9vhezUfGlo9hCGLPHDMGRMmV04q8+rAaaNQOTxhYGh9R7c9PW/AchCeLw6FZTrQO9t8gOQxmC30xdoVNF9uQW3urhuwCnp6bupcAHl+6iW0kIEoIDIamHiWmV6tYZOBEe6qy+M8tgDA==
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=nx46UtR0XAO8jbgxAWqvf/hWEK0pINwdZMMikqZIv9A=; b=oIFhr5WI9Iq2MbIZPtH0OKYVvqWijD/OxZaqFhttXIO5abxML6UkMwG0DGCqEyPrr2d/kY4HaWe6ZuxXhkPLaMDdEpk8FywVsQJCBsPrLITrTxdK7kj6PBBCgiV6XzHNXHPb0RNsUM/H5tR3c1UMHGaCztknlrwjtbx3pdLcMxk=
Received: from BYAPR11MB2757.namprd11.prod.outlook.com (2603:10b6:a02:cb::16) by CO1PR11MB5043.namprd11.prod.outlook.com (2603:10b6:303:96::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5164.20; Sat, 16 Apr 2022 21:53:54 +0000
Received: from BYAPR11MB2757.namprd11.prod.outlook.com ([fe80::b46e:544c:a2a6:caad]) by BYAPR11MB2757.namprd11.prod.outlook.com ([fe80::b46e:544c:a2a6:caad%6]) with mapi id 15.20.5164.020; Sat, 16 Apr 2022 21:53:54 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Gyan Mishra <hayabusagsm@gmail.com>, Ketan Talaulikar <ketant.ietf@gmail.com>
CC: "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "draft-ietf-lsr-ip-flexalgo@ietf.org" <draft-ietf-lsr-ip-flexalgo@ietf.org>, lsr <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+m71Clk6zqRI8AgAATxgCABzJ2AP//4/oAgABw5QCAAADSAIAAHNKAgAAyVICAAG/hgIAAHSmAgAAjzYA=
Date: Sat, 16 Apr 2022 21:53:54 +0000
Message-ID: <1DCB8FC1-E5AB-4629-9CF3-BA0EF9EFEC72@cisco.com>
References: <CAH6gdPyXbPh0=k6KvZJyzyvapBrjjkby50MbmGNQOAG1GDX1OA@mail.gmail.com> <3FA9B00A-864D-464A-8BA5-368C1EDAC580@gmail.com> <CAH6gdPzQmuZAFvnDoUqH6ENNd5qCjLpgHidDhZ-etMt=Y5pqXw@mail.gmail.com> <CABNhwV0hYRNzsvkbomzobGG79z738cv2J39Wx_tG55nL6QAfxA@mail.gmail.com>
In-Reply-To: <CABNhwV0hYRNzsvkbomzobGG79z738cv2J39Wx_tG55nL6QAfxA@mail.gmail.com>
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: 4b9e6aa7-f7df-46cf-f34f-08da1ff399e5
x-ms-traffictypediagnostic: CO1PR11MB5043:EE_
x-microsoft-antispam-prvs: <CO1PR11MB5043A8061B0B2DFC95CB60FEC2F19@CO1PR11MB5043.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: 8FUexW47jBvwW8azsWAqPdMH9z40GDJ4kZY05Y0rjBxnj0goWEvnwwT4WzB42fwEmx4hT6UaJhFXiqyzKI5vwveXucCGDHYSnXS3/p+SeQgX8AwyzN3bsK+sIrZZ6+xrq323XJlPI6pdUeM5IOVipzxkBpAUChaxM//klaeE2Hj+yCcOVAUfrrO0PjAKIph9FLAII0eqKhfqnd7RCeD+MMf0WOlSywOVGaFBF7dSykQALLUGUwofZfcskZRxb6qKWEptZqO+a8Et6PxvGslG5otkDpNrRjwqO56JIU/VbMd68d8bJr89DM9JDLAVecc3t2UHWJNvsvtgqWJtc0HZF5PAnceOSAJM69fJ9VwKGQo3u1YrYEnPdhRBbTX7E0jroraFvmG0dA75sVtm2N1yfVY/6bp0AffWBvl7ogH8DJduFNyA1FnYe/yYEq8CjO7cfHmKu8KFJOX1ttxGV95x8TlQUtYzm9jtMGvy9zpgfEvvwnV/mpirg4vyNq9C3MX6Y7yX0UYNf60OCMIe9nNIDed6LFojpb2LVTmw4s/LB/1eLNgP56Snyamu4uc0voi/1ND0b12b296bIbBgqNqZ2ndd6eIutuJc4pjxm5X0A18JXziLS8CIa6KCVlHeh88KKXHGT2Fw3UyLJl3GMrU6Ps2UNFny7Jo0D1uKPGDEdVLWt9dYqVYeDi7krmeTCSnP6Ur9BWBieKSWJx1RYvB7lhmzoH++AfnqbUDd3Hyl7AVXcP3TqAfe8NQscDLYKMZpOM86QR7q3Qta/4BeoPozD8hlAqJnMBSwa6DCkl7jJ+6YVEoq0tPk/jJ2PWgg7fX5kHpJ36Rp8i6fRDZU252nxBZmkQ9h+CZMBEI3CErCcKM=
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)(6512007)(83380400001)(2906002)(508600001)(91956017)(966005)(6486002)(66556008)(76116006)(66476007)(64756008)(8676002)(4326008)(66446008)(26005)(30864003)(5660300002)(186003)(86362001)(40140700001)(33656002)(8936002)(2616005)(53546011)(6506007)(66946007)(36756003)(166002)(122000001)(38070700005)(54906003)(71200400001)(316002)(38100700002)(110136005)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: jpA9hmGCxTsXWmbjsBginCEBlqBKTJcO0XKOVmrq9jRV44KiSqBRrc2Mn461cmNu3GZWOxY4WdcGU6/taduJcuDnIyXb1kARuCGbzXgAOKOSnO78oPpD16qM8+x1vZftfHstkgeqCabnZ+XCHuq1Kx3rmtcvSRYNEx+8mxwCBiRD8aWKiXNvs9h2scZ6w2ifQWQybx0jP30fTUVOMtSzphT2ayZu5c+K0KD4JNE4F5N8nmaGzSK3GeNcAIMQk6+V8aQ3v2HIg+WpK17/P605TVI+BZxaQ6WLZsGkvkWBsTMFqRcFQMYL6lAQgjwwmBvltDczCxJSEfK/mHWQygJQQ/2R+zXi4tROuLnjVxcj1w4VvktKAOsUUQNb9z9MhRcjaS/MImPerY2T2Rxf9XwDfjk4mW+cI1KqsGERo6Vy9qHbrviihy+8TRLVNVnRY0fQI9cTryD8ljSZ+uH/ZwZ8BeCb55q85LJyh9acxlxHmGb7aJRH3pUcVWeL3nySRx2N3rvduK99ONrK5a8QQbik45qCgWlPUSgtYOtL3HQY8Nrod4UzmrIbyO8dgzv/uQWd32r9yZItS8ql9PXt3SAq1/usY35FU0QNQrkPr+EPkyJ6DP1c4j1MxY0u/LykeAdIKwFziRQdpJKCvT1doZqMzA7zhJMccdZULAI39HJsGMsJfz/14hw+tuieKBhZ3dSb1nXSdfdk0c6dWXSSgVtbzb7KRB/H0WKVhqchoLqNuUgFSWmN5V7g6PT1dVom3CXDzEgoZ4Oujgy+eQCmq6gWpC8kJgKR1fHgimu64XmE+LwYSbXQUUhkfrLWa3LsJGywd/n7Mm5Ep2EAKRW3De3QHyuWuVNU/DX0VkaQ8mR3j3ZaiY9YYO1S1jfP1kf3qcNGIUGbb5X4ydMO0A54dHq3cMbHr22Ln79sBRS3/FYhopd7/Sws4/lAdK5KJ1Bjza2PMN6gjkgD+P1UjB0xpt1nhGezPYcyYGyX6cXTyDzckmQ/JHXUOoQUhnsd9sYmQ6C5SwMfYb7mvPOX51jGt9gP5UcdgKlbOMinXjCCG+38Ik8bZb1kS0O8zj6NEXqYZG1S0pa7hIhKS9C+nECvGmFGdQr5iGqBtzJQghS4QWvMrjo6ed91tdXiAVkKffUKM/qTOG0TuuzZak98WzE8BPl9RD+KD6tzdgqANGE7XvAorBrBE1YTAcubEMLswrY0923FSGTh0Y7f1MOsErF5MCBJRguD+/xgDe5IDJYdUyafJ7d4KwCeDp2ggM/Bk2MkHVuUoMR6vOqGEPlPPdfYzAdu9lo36lQCREVFyuy003L3yQyYxgAq+mjpQ0TG79PDzHGEg4u9qS3otArHh7WvKNszqotiOAnylN79peK2gHrpc4BcEddzYo8SwzuGXvMh/L1PtjivYjOjsJKYT2LX/8iUgcltJU47s8CZyDQftPToc3FXhE3Azh1bZqYegNKel6UMoPyRVBqzYVMxyA1W+4wwIqUNCT1aEYjRAUv26Sep9TVSTVQrUeCLaZU0L4+Rfxegm34Xf7RXKVZ9cQ/TVLN2yDmHZFz/AEz1Nduq2+ci0oBYHiYDvKyNWMPt7eRGy4bzpZd04u3JTfV9xFdvTc71Up3sBBXbaLJ1/FF/TYN4gQmb3oNjOTpjX8A4w4/BAjLntSdNtz/bs1u67d+rznpsZ/XKPzJoub+9iCrCPLGGhh+WLIRfiDqZpfKC/qoZOsBn53iv7+0KG7Wc+yzl0INn1Q==
Content-Type: multipart/alternative; boundary="_000_1DCB8FC1E5AB46299CF3BA0EF9EFEC72ciscocom_"
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: 4b9e6aa7-f7df-46cf-f34f-08da1ff399e5
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2022 21:53:54.4907 (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: CZQVLxwIO8Qx/CeQLxF3MwDbSghUX70pJTnikgpb7Ba+An8mcBIFyFq6yNl78G0K
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB5043
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.227.252, xfe-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/pKX2pSBfX8msExoYsmGdnLgGi4Y>
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: Sat, 16 Apr 2022 21:54:07 -0000

Again, speaking as WG member:
Hi Gyan, Ketan,
I agree since for the IGPs we’ve traditionally used “application” for control plane routing applications (shortest-path, RSVP TE, SR, etc.). I know Robert suggested “logical data plane”… What are the thoughts on this?

Thanks,
Acee

From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Saturday, April 16, 2022 at 11:46 AM
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: Acee Lindem <acee@cisco.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "draft-ietf-lsr-ip-flexalgo@ietf.org" <draft-ietf-lsr-ip-flexalgo@ietf.org>, lsr <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"

Thank you Ketan.

Ack on convergence on new term for application.😃

Thanks

Gyan

On Sat, Apr 16, 2022 at 10:01 AM Ketan Talaulikar <ketant.ietf@gmail.com<mailto:ketant.ietf@gmail.com>> wrote:
Hi Gyan,

Your proposal looks ok to me. Note though that we seem to be converging towards using an alternate term instead of "application" in this context.

Thanks,
Ketan


On Sat, Apr 16, 2022 at 12:50 PM Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> wrote:

Hi Ketan

My understanding was that IGP Flex Algo could only be used with SR-MPLS or SRv6 data plane using prefix SID or SRv6 locator to steer packets.

So it was my understanding that the IP Flex Algo draft was providing a solution for IP based networks ( Non SR-MPLS or SRv6) networks which was valuable gap to be filled.

However your editorial comments shed some light that IGP Flex Algo may be used in  IP based ( Non SR-MPLD or SRv6) based networks.  This is confusing to me however below paragraph makes it more clear to me as to why you stated IGP Flex Algo is open to beyond SR ( even though not yet developed).

IGP Flex Algo draft Section 14 describes forwarding plane use cases for Flex Algo which are SR-MPLS and SRv6 and 14.3 mentions that any application that wants to use Flex Algo can use it but that application needs to be developed to install the Flex Algo entires into the forwarding plane such as for RSVP-TE or native IPv4 or IPv6 forwarding plane.

I think if IGP Flex Algo was developed as part of the draft to support other applications such as RSVP-TE and native IPv4 or IPv6 forwarding plane I think we could say that IGP Flex Algo can be used outside of SR data plane but that development has not been done even though it maybe possible in the future once developed or it may never be developed based on industry demand.  So I think it’s safe to say at this time IGP Flex Algo only supports SR-MPLS and SRv6 forwarding planes only.  However now once IP Flex Algo is published and implemented we can safely say that it has been extended beyond SR data plane.

I would change the verbiage slightly to make it more clear.  You mention that the IGP Flex Algo draft is the base Flex Algo draft but I disagree as if it were then the IP Flex Algo draft or any other application of Flex Algo with a new data plane would be an update to the base Flex Algo draft but here in this case I don’t think so and even for any other application.  Each data plane instance of Flex Algo starting with the IP Flex Algo draft and then maybe future RSVP Flex Algo draft would be their own independent “base” Flex Algo draft onto themselves.  That is one option, to keep each data plane specification of Flex Algo independent specifications.

 If we think that IP Flex Algo and future data plane applications such as RSVP-TE and beyond will be extensions of the IGP Base specification, so then will be updates to the base specification, then I think we can call IP Flex Algo an extension to the base specification.

This is what I think the verbiage should state which is a hybrid of yours and Peter’s verbiage.

This is if each application is standalone per data plane  and is not an extension and so IGP Flex Algo would not be a base specification.

NEW

>     An IGP Flexible Algorithm (Flex-Algorithm) allows the IGP to compute
>     constraint-based paths. The  IGP Flex-Algorithm specification
>     currently only supports the application Segment Routing with (SR) data planes - SR MPLS and
>     SRv6.
>
>     This document specifies IGP Flex-Algorithm, so that it can be used  in any IP network
>     for native  IPv4 and IPv6 forwarding in the absence of SR.


Verbiage if IGP Flex Algo is a base and this draft is an extension and updates the base.  We don’t have to say IGP Flex Algo currently only supports dropping the word currently as we are now extending with IP Flex Algo.

> NEW
>
>     An IGP Flexible Algorithm (Flex-Algorithm) allows the IGP to compute
>     constraint-based paths. The base IGP Flex-Algorithm specification only supports the application Segment Routing with (SR) data planes - SR MPLS and SRv6.
>
>     This document extends IGP Flex-Algorithm, so that it can be used
>     natively with IPv4 and IPv6 forwarding.




Kind Regards

Gyan

Sent from my iPhone


On Apr 16, 2022, at 12:21 AM, Ketan Talaulikar <ketant.ietf@gmail.com<mailto:ketant.ietf@gmail.com>> wrote:
Hi Gyan,

I am not sure what the confusion is here. The following is how Peter and I concluded this point. My comment was of editorial nature.

Thanks,
Ketan

>      > 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
>     where do you see such assertion? Each flex-algo data-plane/app can be
>     deployed independently.
>
>
> KT> Let me clarify what I meant by taking the example of the abstract.
>
> OLD
>
>     An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute
>     constraint-based paths.  As currently defined, IGP Flex-Algorithm is
>     used with Segment Routing (SR) data planes - SR MPLS and SRv6.
>     Therefore, Flex-Algorithm cannot be deployed in the absence of SR.
>
>     This document extends IGP Flex-Algorithm, so that it can be used for
>     regular IPv4 and IPv6 prefixes.  This allows Flex-Algorithm to be
>     deployed in any IP network, even in the absence of SR.
>
>
> NEW
>
>     An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute
>     constraint-based paths. The base IGP Flex-Algorithm document
>     specified use with Segment Routing (SR) data planes - SR MPLS and
>     SRv6.
>
>     This document extends IGP Flex-Algorithm, so that it can be used with
>     regular IPv4 and IPv6 forwarding.
##PP2
ok

On Sat, Apr 16, 2022 at 8:07 AM Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> wrote:

Hi Acee

Fixing a typo

On Fri, Apr 15, 2022 at 10:34 PM Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> wrote:

Hi Acee

My question cane up from the list of questions posed by Ketan and Peter’s response to question #3.

See excerpt below.

I am confused by what Ketan stated in his question below and also Peter’s response which is why I am asking the question again.

I believe the goal of the draft is for Flex Ago to be deployed independently of SR filling the gap of IGP Flex Algo providing that solution.  So based on what Ketan stated in his question that IGP Flex Algo is data plane agnostic and can be used with IP data plane then there is no gap to be filled by this draft.

Maybe I am misreading Ketan’s question.

So this is a very important point made by Ketan that if IGP Flex Algo is open to usage “outside of SR”,  then it is very important to restate the goal of this draft, removing assertions in the draft that this draft is for non SR IP data planes, as that can be accomplished today by IGP Flex Algo, and the gap or new solution being filled by this draft is for IP prefix based Flex Algo with Native IP Forwarding.

This as well is quite confusing to me as if IGP Flex Algo can be used outside of SR then can do everything that this draft is supposed to accomplish.

So what then is the purpose of this draft?

In Peter’s response is stated that each Flex Algo data plane / app can be deployed independently meaning this draft and IGP flex Algo can act as 2 ships in the night.  Also confusing.

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
where do you see such assertion? Each flex-algo data-plane/app can be
deployed independently.





On Fri, Apr 15, 2022 at 7:51 PM Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote:
Gyan,

What is your point here? Is this a trick question?

Thanks,
Acee

From: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Date: Friday, April 15, 2022 at 5:31 PM
To: "Peter Psenak (ppsenak)" <ppsenak@cisco.com<mailto:ppsenak@cisco.com>>
Cc: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, Ketan Talaulikar <ketant.ietf@gmail.com<mailto:ketant.ietf@gmail.com>>, "draft-ietf-lsr-ip-flexalgo@ietf.org<mailto:draft-ietf-lsr-ip-flexalgo@ietf.org>" <draft-ietf-lsr-ip-flexalgo@ietf.org<mailto:draft-ietf-lsr-ip-flexalgo@ietf.org>>, "lsr@ietf.org<mailto:lsr@ietf.org>" <lsr@ietf.org<mailto: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"


Hi Peter

My understanding is that the main goal of this draft is to be able to use flex algo over IPv4 or IPv6 data plane as that is not possible with existing Flex Algo which can only be used on SR data plane.

Is that correct or am I missing something?

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo



Abstract



   An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute

   constraint-based paths.  As currently defined, IGP Flex-Algorithm is

   used with Segment Routing (SR) data planes - SR MPLS and SRv6.

   Therefore, Flex-Algorithm cannot be deployed in the absence of SR.



   This document extends IGP Flex-Algorithm, so that it can be used for

   regular IPv4 and IPv6 prefixes.  This allows Flex-Algorithm to be

   deployed in any IP network, even in the absence of SR.

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-19


Abstract



   IGP protocols traditionally compute best paths over the network based

   on the IGP metric assigned to the links.  Many network deployments

   use RSVP-TE based or Segment Routing based Traffic Engineering to

   steer traffic over a path that is computed using different metrics or

   constraints than the shortest IGP path.  This document proposes a

   solution that allows IGPs themselves to compute constraint-based

   paths over the network.  This document also specifies a way of using

   Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets

   along the constraint-based paths.

Kind Regards

Gyan


--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347