Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt
"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 10 March 2021 13:07 UTC
Return-Path: <ginsberg@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810283A0B41 for <lsr@ietfa.amsl.com>; Wed, 10 Mar 2021 05:07:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.919
X-Spam-Level:
X-Spam-Status: No, score=-11.919 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=gD7T0mhB; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=uCGpYTKZ
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 Qw3JEDuhIoKi for <lsr@ietfa.amsl.com>; Wed, 10 Mar 2021 05:07:02 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8881A3A0B54 for <lsr@ietf.org>; Wed, 10 Mar 2021 05:07:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=245080; q=dns/txt; s=iport; t=1615381622; x=1616591222; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yDHEt62Fhn0EVVN9+N5mGkzNOgHyFG62mmPC47eWUI8=; b=gD7T0mhBF45ehmKB7wnQDns+Je0YuA//FGJY59O+4ry5yGzWEbtYVeWL wvofGTBnuibrIq1QYauC1+tNd2B+hQEp4RdF1NHNsf848QxNwbpaF+/23 n0pr762DPtwwbF/WDvFsNB5SBU2cvrUYVL1LKIare0ezcgM/lM7PjS++U A=;
X-Files: image001.png, image002.jpg, image003.jpg : 66157, 356, 356
IronPort-PHdr: 9a23:J67h8BPqO7xfoGY+yKIl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEvKwx3lDMVITfrflDjrmev6PhXDkG5pCM+DAHfYdXXhAIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtaHc//YxvZpXjhpTIXEw/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DvAAAGw0hg/5JdJa1XAxoBAQEBAQEBAQEBAwEBAQESAQEBAQICAQEBAYIPgSMwIy4Hdlo2MYRBg0gDhTmIWQOBBokXhHeKB4FCgREDTwUDAQcBAQEKAQIBAR0BDAgCBAEBgjCCHQIXgVsCJTgTAgMBAQsBAQUBAQECAQYEcYVhDYZEAQEBAwEBAQMBEgIBCAIIARIBAQUgBwYDAgELBAIBBgIHBwMEAQEBBQEBAQoOAQYDAgICBRAKBQELFAkIAgQOBAEIBg2CVoJVAw4hAQ6RQpBqAooedoEygwQBAQYwgQMBAwIOQYMODQuCDAcJgTmBXIEaNYNSAQGBDDICg1WBLxYQHIFJQoEQAUOBWgFINT6CGkIBAQIBFYESAQsHAQccFQoFBgEJCAmCTzSCK4FcDR0+BgEBYgQNEAUNAhIOAQEEAQQXAg0ZBwwLFQoTHA4CCA0EBwMBAQEXAQEFCg0SBQQqEJARBB4KKwNpgVBBh1AvgS2KGmmGAoI9A16HVFsKgwCHWQKBaYcLSIVpgjiDF4M8ilgXhWiNH4JOknWEA4k/gwqOcSYED4FRgnMCAgICBAUCDgEBBoFrIzcwcHAVO4JpCUcXAg2ISYVWBwUFEYNNg0aBToVFcwI2AgMDAQkBAQMJfIk/BYI/AQE
X-IronPort-AV: E=Sophos;i="5.81,237,1610409600"; d="jpg'145?png'145,150?scan'145,150,208,217,150,145";a="874395994"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Mar 2021 13:06:58 +0000
Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 12AD6uib018373 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 10 Mar 2021 13:06:56 GMT
Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 10 Mar 2021 07:06:53 -0600
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Wed, 10 Mar 2021 07:06:51 -0600
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 10 Mar 2021 08:06:50 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ETtHoEIomMP0slcdh0WYsIocRZCfMEIpURoWMsTvgAZVVDzp+OvRj6eseWsT0lCbflFqsORR/o7QrGf/bkxBndfI7tfgiXwLiZ6xeuCxxfd7NSIyePGIdZDlCk5iLgq0FxunEiy8bU5QPJRmkaFve9RMMSV7Yeja2P8xgZjCpuarfVnQuCBByD6dS7m9d1xE6adgskYUIP5P42srlNNJftPPJd8BnJ47mqJZIzFKr2OCZG18a4M0RY4xSeNEMOgEP/MZ8t0JmJblumlg9AyBXbRQMIZOAkKBhzhC4swuOBMnktHng5u8hxfvpIBnNblaztATum0yiDtPCcO6+QukwQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NoG5/cfMKznxZpbGlNHT1a1rvdZu/aQ+G5qIfktuEts=; b=cKA/U6AM32fPQrrg9W/AtwCrdeXslcyUapFrNrFCC+u2Ddcvu/myS1MPOBZ1gn5kxakj15VeryyvsYwAshLUb1Zcgrimdiz0gkAA7l5I0BozGuM0ztaxZFV9sjTHwS+prssES9SZR49ljdGQWCEBjwRuIhiWIUOPAnMfrGtXeK2S6jQPRQPnrGYVrnfsPB0euQ/OMDADGGdxasRbBuSjzO53FVwlG5Hkpknk2OHGJn37X/eqQkDw2wGszbev39yNKELAXsJljmH+h1KuiPRXIOuMI5ULMNObipVRtDc5t+ptJC402KfaPmqzAxI3zwRzQfd/34EYBypKj7SvqvN7Xg==
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=NoG5/cfMKznxZpbGlNHT1a1rvdZu/aQ+G5qIfktuEts=; b=uCGpYTKZrM5kEoA4LlShdPvCN1/jrQrJG7HQ1182ck5gHN/ZXFllb57JakXj+p1kgIgTLDtzi8SI2noFWdU06BXIvRrl40ftkJ+eYOEdBcRnL6SnzxZB6GA5han8pQWlgh8M+CNmh3fmKJUYua8fdG9MiCt9kDBUov4H3CkonmE=
Received: from MN2PR11MB4352.namprd11.prod.outlook.com (2603:10b6:208:18e::30) by BL1PR11MB5494.namprd11.prod.outlook.com (2603:10b6:208:31d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.8; Wed, 10 Mar 2021 13:06:48 +0000
Received: from MN2PR11MB4352.namprd11.prod.outlook.com ([fe80::cdfb:1e0f:7cb5:ac05]) by MN2PR11MB4352.namprd11.prod.outlook.com ([fe80::cdfb:1e0f:7cb5:ac05%7]) with mapi id 15.20.3912.030; Wed, 10 Mar 2021 13:06:48 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
CC: Aijun Wang <wangaj3@chinatelecom.cn>, Huzhibo <huzhibo@huawei.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, Robert Raszuk <robert@raszuk.net>, Tianran Zhou <zhoutianran@huawei.com>, Tony Li <tony.li@tony.li>, lsr <lsr@ietf.org>, wangyali <wangyali11@huawei.com>
Thread-Topic: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt
Thread-Index: AQHXCL5NpsYPKf8SF02ycDH2jqATyKplS9jggAEDRICAAgxWgIAAvmaAgAEhUgCAABBjgIAADF8AgAAHIwCAAEWzAIAC4sgAgAFnXgCAAYfbAIABTKWAgABMrgCAAaR/gIAAAgkAgAAxFoCAABqMAIABhMKAgAAP4gCAAATxgIAAAvwAgAAD2ICABWRZ8IAAxp0AgABKleCAAMKEgIAAbfMg
Date: Wed, 10 Mar 2021 13:06:48 +0000
Message-ID: <MN2PR11MB4352D1490B7947E02A4F1DEBC1919@MN2PR11MB4352.namprd11.prod.outlook.com>
References: <CAOj+MMHsDgfD8avbRtvthhd0=c-X25L9HBc0yQTby4vFQKECLQ@mail.gmail.com> <CAOj+MMEAJdqvmhfpVEc+M+v_GJ92hmjggbDWr3=gSAM4y3HkYg@mail.gmail.com> <CABNhwV1EBsej6b-++Ne2OpwMb6DMb9dubjf=M1LrOEHjn4MWmA@mail.gmail.com> <57f50a96-4476-2dc7-ad11-93d5e418f774@cisco.com> <1520992FC97B944A9979C2FC1D7DB0F405242279@dggeml524-mbx.china.huawei.com> <26f29385-eedd-444b-ce02-17facf029bd2@cisco.com> <1520992FC97B944A9979C2FC1D7DB0F4052483BC@dggeml524-mbx.china.huawei.com> <9013a79f-0db9-5ec3-5bfd-8f1ab32644d3@cisco.com> <1520992FC97B944A9979C2FC1D7DB0F40525E441@DGGEML504-MBS.china.huawei.com> <e0bfca37-d9ca-2a06-4fe9-1e6fa3374f45@cisco.com> <1520992FC97B944A9979C2FC1D7DB0F40525E4FF@DGGEML504-MBS.china.huawei.com> <45db4eee-55cf-f09e-1db3-83c30e434213@cisco.com> <1520992FC97B944A9979C2FC1D7DB0F405262C4E@DGGEML504-MBS.china.huawei.com> <ada0ec9f-a0b5-0f32-dee1-2ff4cfc70013@cisco.com> <CABNhwV2XCEi1A-KkNG7Sbd_gWfO_biuiCVRFRFaMvTo0Mayf6A@mail.gmail.com> <32e3d939-ce1b-ffaf-9ca8-ddbcfa903a9e@cisco.com> <CABNhwV0kH9E7LaZL6X=YVrDEifx1v8gsLt7n5JZ7tLmRL93kwQ@mail.gmail.com> <BY5PR11MB433750D658A877A8606B6405C1929@BY5PR11MB4337.namprd11.prod.outlook.com> <1520992FC97B944A9979C2FC1D7DB0F40526E310@DGGEML504-MBS.china.huawei.com> <BY5PR11MB433772A877BED892FA94EDF4C1929@BY5PR11MB4337.namprd11.prod.outlook.com> <CABNhwV1DD8vM_QEjWNHpo+s09rZei8sgi3dMRjqh750cQBMjyA@mail.gmail.com>
In-Reply-To: <CABNhwV1DD8vM_QEjWNHpo+s09rZei8sgi3dMRjqh750cQBMjyA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2602:306:36ca:6640:555f:d858:b242:a7b5]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e66a8dc0-8a15-4c5a-b800-08d8e3c55d47
x-ms-traffictypediagnostic: BL1PR11MB5494:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BL1PR11MB5494FD982B3125B7BCF11DD4C1919@BL1PR11MB5494.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: t6hAyr8fG6mCJssbfpfGkKJhA3enmaxdAL5AcVYEzneV3GMpgGpyBjB8CWzWT3iyZDkQlLDGGMbx48t8Mc0c7f8U0OEaxbIEtTc+d4WpPJYYiB/5bHOB7KZgVrdPKi4m0f37hmOWJ36lfd3Po5BGxrwQwrPqVUzk2pGO4HR7mEKegpd2xTDa8QYN0hksmpnzD1jouLCy829IEIAgxoLRAjrKGuoiJYQF0CVS/xmcMftt2kX/Xp3VFz5X1kaet50FlqwHhuqyc00cXsMwp+Q5cIjbjMPV39shrNYlwNq+RZVHziavX5ASNP+ZRO7zlREEQ3v0kC+yCnnv9nh0qhhjgIKYA3oZDSGNdQsh5t2u2EfvYNFu3n2v+vCSmR5/ipcuTA1HzKJq5X9JPETIky1pRQqKwA45rKtTZtS6XJb89VL1n1/FAuSPZuAwDHjv02dXwaUaksxbEBdBWjr32kSIacyh3J4fqWR9gzYfHnMeiX87OIW8Z4H0liPMviXjO2TaR/1L5WiUT9FQ4WT0zz17Vo6a4RvEVLotJrHqHKwDlR/Ilzd4dRPlnG5RUaWaqiw3VZl/iJ8mte09aAFeYY5XKB1oxB+rmLH2gmAI3jjaAMU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4352.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(39860400002)(396003)(366004)(136003)(186003)(55016002)(86362001)(66574015)(53546011)(6506007)(9686003)(52536014)(7696005)(54906003)(71200400001)(316002)(8676002)(5660300002)(8936002)(15650500001)(33656002)(30864003)(6916009)(64756008)(66556008)(66946007)(99936003)(4326008)(66576008)(76116006)(166002)(966005)(83380400001)(66446008)(478600001)(66476007)(2906002)(579004)(559001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: JzvvU51gGNXdn9vNaWX4glyvRDNHe/jdr3EvYgDVX7pNGgZNwYjZ49hM1c7o5aEjBddpmJFPvAQtY48ume7q7XhSgQxXl8r/T5OhXHZAE9Xd9ZOFG2iL9TEbGb9ms97UqqjkgCOsKvj7bj9lld1lK7wTHpQT94dLusXW2M63ofl4VZhhOl6V7aiVs22tHPTircVg5DrlquELDIcCwpqC73qdAottT4eNjECVCPg9weMgqIiIBjhoM8wMxATmZZjBFSKsq+4Opv869bwZ7C0QSTjEELeSCUWXzJJpqeok9fgmtcrbX7CmpHcGFM7FChwZ7mJ+AvCK6tpB6T0nbKutArURpexjRlQhBAEDxecaIefsaPf41sEu54IEl1DvKm/BiWAZuUFLZucUENeT0NRBW6VkuMYpl3Q1K5SoCs3slgYS82MCeN+PO/TB0o2jw+eEzcMCU6P+GG01k7eLDLiBz+vhIEObLF4U6xnqX57sTeKhhxBvS/BcQAfkKqTpkD2Twk9bw6f+qqJRUcugiImhwgf0gg7SifNfG/tXIX4EvjtHMGXbEg28qy1zxiI5IUJMpiYfvLojAbjenEjqp1ZSvxNw0y+kCkY/xSL84H82PFshkcarUCFJn1OaHPajNg0PhcS5i01X8cawEtVzW5cHgsZJqTxqrWjKyTlikNlaKNhJimcNan5gTr6ovbcIit5/HcR++fr//9O/en9TaMX1geREzKlNtB+ZVh41eJG7XhAXlRdKq+nLWW00tiJteB8aekxuf2qyGl038M6TzdAc99WrE8QtJoVOSKz71w1YkF8WUJIQwCMD8jJZd1r8IpTifFGzApY8loXXUeJfaJ2TXSVZhifgUmeO1p2fDFu36mdGxamdO4hDf5axl4Ffk5X1qEzfDMjvA/Rb23rXdjEaRLiEUr/j0vdhb9GuvFd3frPSDZKnt6mvXnLLGBvo9npNOGXj1wlWZrKHMmIRQ7EtQpV+0y8HpZkCOfo6I47r9rzPAG+6MFMJdxRmVUTQGV/64HE4/4a1Zr4GGjXJePEy3/JS429SscOsxTaP9uD0ptzRxt9+MnfXqn/qce6uuE2blx97G/6UuLfRrfseGkM0+0ZTap9/sW5mZvSn/hpoYI78UhRPgXXia9Efw5yq0+aXZ9U1AiNkaifWogcwM+kLt02HZMtPCYRgMrTeZtLbt0aiaanNLASDYJSEXPFJGc+/EBItl9hca2xyYRc0Ot7v5GgXqu3WUXhH+SQmBqOcAwozEREol7Y/SJZRh4QTEdT6+SWmjKlAHtxgMls2TRqLmj9VQZAy9310KVyyiTbt0LzcLsoWNddRFl8HPOABoNHmwVoRMObdA0mN9jRZZzAhTE6UOPCdnfKxPV+u1VP62shZKL1/GNXwnsAuDd1KsI53
Content-Type: multipart/related; boundary="_006_MN2PR11MB4352D1490B7947E02A4F1DEBC1919MN2PR11MB4352namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4352.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e66a8dc0-8a15-4c5a-b800-08d8e3c55d47
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2021 13:06:48.4529 (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: PniuGwcz07Ufeq8cpX0nuXYAlytRn2nNXcD1WmymALx2rHfSgzn72j4bNyvDQSzWvXNE6oTG0WRxURpKKiRnEA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5494
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/0VIsHWci5D6qFXmtsuLPNENxAes>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt
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: Wed, 10 Mar 2021 13:07:10 -0000
Gyan – Please read my recent reply to Aijun. I suspect it is relevant to your concern. I also am very concerned about the amount of information associated with advertising VTN related information. It is one of the reasons that I and others prefer that IGPs not be used at all to advertise this information. But this thread is discussing the need for definition of yet another way of supporting the Update process. This does not alter the scale characteristics of the solution as I have explained in my response to Aijun. The number of bits which have to be flooded does not change significantly whether the Standard Instance is used of whether a non-zero MI instance is used. That is the key point to understand in the context of this thread. Les From: Gyan Mishra <hayabusagsm@gmail.com> Sent: Tuesday, March 09, 2021 10:25 PM To: Les Ginsberg (ginsberg) <ginsberg@cisco.com> Cc: Aijun Wang <wangaj3@chinatelecom.cn>; Huzhibo <huzhibo@huawei.com>; Peter Psenak (ppsenak) <ppsenak@cisco.com>; Robert Raszuk <robert@raszuk.net>; Tianran Zhou <zhoutianran@huawei.com>; Tony Li <tony.li@tony.li>; lsr <lsr@ietf.org>; wangyali <wangyali11@huawei.com> Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt Les This TEAS draft discusses the scalability of network slices and does discuss that their could be network slices in the order of 1000s as each slice represents a service but would be no more then the number of VPN services that exist today. See section 2 VPN+ scalability. https://datatracker.ietf.org/doc/html/draft-dong-teas-enhanced-vpn-vtn-scalability-02 2. Network slicing can be used to provide isolated and customized virtual networks for tenants in different vertical industries. At the early stage of the vertical industrial service deployment, a few top tenants in some typical industries will begin to use network slicing to support their business, such as smart grid, manufacturing, public safety, on-line gaming, etc. Considering the number of the vertical industries, and the number of top tenants in each industry, the number of network slices may increase to the order of 100. 3. With the evolution of 5G, network slicing could be widely used by both vertical industrial tenants and enterprise tenants which require guaranteed or predictable service performance. The total amount of network slices may increase to the order of 1000 or more. However, it is expected that the number of network slices would still be less than the number of traditional VPN services in the network. In 3GPP [TS23501<https://datatracker.ietf.org/doc/html/draft-dong-teas-enhanced-vpn-vtn-scalability-02#ref-TS23501>] a 5G network slice is identified using Single Network Slice Selection Assistance Information (S-NSSAI), which is a 32-bit identifier comprised of 8-bit Slice/Service Type (SST) and 24-bit Slice Differentiator (SD). This allows the mobile networks (RAN and CN) to provide a large number of network slices. Although it is possible that multiple network slices in RAN and CN can be mapped to the same IETF network slice, the number of IETF network slices may still be comparable with the number of 5G network slices. Thus the scalability of IETF network slices needs to be taken into consideration. Kind Regards Gyan On Tue, Mar 9, 2021 at 3:28 PM Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> wrote: Yali – I find your responses not very helpful. Please see inline. From: wangyali <wangyali11@huawei.com<mailto:wangyali11@huawei.com>> Sent: Tuesday, March 09, 2021 6:22 AM To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>; Peter Psenak (ppsenak) <ppsenak@cisco.com<mailto:ppsenak@cisco.com>> Cc: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; Huzhibo <huzhibo@huawei.com<mailto:huzhibo@huawei.com>>; Aijun Wang <wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>>; Tony Li <tony.li@tony.li<mailto:tony.li@tony.li>>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>>; Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>> Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt Hi Les, Glad to receive your email. Please see inline [Yali]. From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, March 9, 2021 11:15 AM To: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>; Peter Psenak (ppsenak) <ppsenak@cisco.com<mailto:ppsenak@cisco.com>> Cc: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; Huzhibo <huzhibo@huawei.com<mailto:huzhibo@huawei.com>>; Aijun Wang <wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>>; Tony Li <tony.li@tony.li<mailto:tony.li@tony.li>>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>>; Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>; wangyali <wangyali11@huawei.com<mailto:wangyali11@huawei.com>> Subject: RE: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt Sooo, I have been reluctant to comment on the shortcomings of this draft because I feel there was no need for the draft to be written in the first place. I had hoped that the authors would think about this a bit more and realize the flaws in the proposed solution – or – as Acee suggested during the WG meeting – they would attempt an implementation and discover what had not yet been realized. This then would end the time the WG is spending on this – which IMO is the right outcome. As that has not yet happened, perhaps some comments can speed this process along. The goal of the draft is to support per-MFI LSDBs in the standard instance of IS-IS. Since it is not possible for a legacy node to differentiate LSP.xx-yy w MFI #1 from the same LSP with MFI #2 (or with no MFI at all), it is clear that an MFI LSP cannot be flooded to a legacy node EVER!! [Yali]: In our proposal, we considered the scenario where some routers that do not support MFI, and recommended that all MFIs share one LSP Number space in the standard instance of IS-IS protocol. And if routers that do not support MFI but receive the LSPs and SNPs carrying MFI-ID TLV, then routers SHOULD ignore the MFI-ID TLV and continues processing other TLVs. [Les:] Yes – I understand this. But, as I point out below, this case is already provided for by RFC 6823. We do discourage doing this – as we discourage your proposed use of the standard instance. But it is already defined – so your draft adds no new functionality for this case. In order to prevent this, a node has to know whether a given neighbor supports MFI or not. But since the draft defines no signaling in hellos, it cannot tell whether the neighbor supports MFI (not to mention which MFIs – which is important for avoiding flooding MFI LSPs to nodes that aren’t interested in that MFI) you are forced to rely on receiving LSPs (or SNPs) – which brings us to the chicken/egg problem. Neither I nor my neighbor can send an MFI LSP out of fear that the receiver does not support MFI. So MFI flooding is blocked. This problem can be solved by including the MFI TLV in hellos (analogous to what MI(RFRC 8202) does). But this is not the end of your issues. If you have a LAN, you could have a mix of legacy routers and MFI routers – and again you cannot allow legacy routers to receive MFI LSPs as they will look just like legacy LSPs to the legacy nodes. This means you will have to find a way to avoid ever having MFI PDUs received by legacy nodes (RFC 8202 uses different MAC multicast addresses). [Yali]: Correctly. You’re right. There indeed be a signaling in Hellos. MFI-ID TLV can be included in IS-IS Hellos. Because we want to focus on extensions to Update process, we originally plan to implement this part in the second version. We also have describe the Interoperability Considerations in the condition where some routers do not support MFI in the draft. [Les:] Glad you agree. But the point is – when you have finished your draft – you will simply end up with a variation of RFC 8202. So it won’t be simpler – which was one of your key goals. This is one of many reasons why I see no need for your draft. Sooo, once you have addressed both of these issues you will have repeated what RFC 8202 already does. No new benefits here. This then leaves you with one possible use case: support a single LSDB for all MFIs in the standard IS-IS instance. But, this use case is already provided for (though strongly discouraged) by https://tools.ietf.org/html/rfc6823#section-5 . [Yali]: This proposal is used to solve the issue that how we can isolate the impacts of non-routing information flooding under the condition that there is only the standard instance of IS-IS protocol implemented in the network and no one router support Multi-instance. Sec.5 also mentioned the issue as follows. [Les:] If – as you seem to agree – you can only support a single LSDB, there is no need for any protocol extensions and no need for the new MFI TLV. You could advertise GENINFPO for multiple apps in the standard instance. So your table below is irrelevant. ‘’ Flooding of information not directly related to the use of the IS-IS protocol in support of routing degrades the operation of the protocol. Degradation occurs because the frequency of LSP updates is increased and because the processing of non-routing information in each router consumes resources whose primary responsibility is to efficiently respond to reachability changes in the network. ‘’ So in this proposed draft, we give an optional solution by separate multiple Update processes for different kinds of information, such as following example shown in the Table (I presented in the yesterday meeting). Each Level 1/Level 2 LSPs associated with a specific MFI carries flooding information, such as routing topology, belonging to the specific MFI #0. And Level 1/Level 2 PSNPs and Level 1/Level 2 CSNP containing information about LSPs that transmitted in a specific MFI#0 are generated to synchronize the information propagated in the MFI #0 LSDB that is subdivided from a single LSDB within the standard instance of protocol. [cid:image001.png@01D7156A.AB919340] As shown in table, different flooding information can be propagated in the unique Update process. In each MFI, priority and update parameters can be customized in dependent on the requirements on the flooding rate of different information. Hence, in our proposal, we also provide an optional solution that can be used in the standard instance to solve the issue also mentioned in section 5 as follows. ‘’ One of the most egregious oversights is a failure to appropriately dampen changes in the information to be advertised; this can lead to flooding storms. “ I do understand that some folks want to advertise VTN info in IGPs and that the WG will be discussing this. I am not in favor of doing this – but I recognize it is a legitimate topic for discussion. And if the WG were to approve such functionality we have MI available to be used to provide separation. (Note that MI has been implemented and successfully deployed by multiple vendors.) [Yali]: Well, then may I post a question (or maybe a Survey) here for folks from operators? The question is that when deploying thousands of slices, are you willing to implement thousands of IS-IS instances to flood thousands of slices topologies and so on? From our side, we can't imagine what a huge project it is. We’re appreciate if you are willing to give us your answer or opinion. [Les:] This is not an appropriate response. No one – not you, not me, nor anyone else on this thread – has suggested that thousands of IS-IS instances would be required. For you to suggest this induces uncalled for hysteria. It is obvious that if you could send info for multiple applications in the standard instance you can do so in a single non-standard instance – but we would at least have separation from the routing instance. Certainly there is no need for thousands of instances. Please do not compromise a meaningful dialogue with this misdirection. If you read https://www.rfc-editor.org/rfc/rfc8202.html#section-4 there is a discussion of related issues. Section 4.3 is particularly relevant to your comment. Les draft-wang-lsr-isis-mfi is an unnecessary proposal, seriously flawed, and not achieving any of the goals stated in its introduction. I ask that the authors abandon this proposal. Les From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of Gyan Mishra Sent: Friday, March 05, 2021 8:11 AM To: Peter Psenak (ppsenak) <ppsenak@cisco.com<mailto:ppsenak@cisco.com>> Cc: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>; Huzhibo <huzhibo@huawei.com<mailto:huzhibo@huawei.com>>; Aijun Wang <wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>>; Tony Li <tony.li@tony.li<mailto:tony.li@tony.li>>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>>; Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>; wangyali <wangyali11@huawei.com<mailto:wangyali11@huawei.com>> Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt Hi Peter On Fri, Mar 5, 2021 at 10:56 AM Peter Psenak <ppsenak@cisco.com<mailto:ppsenak@cisco.com>> wrote: Gyan, On 05/03/2021 16:46, Gyan Mishra wrote: > Yali > > I agree with a Peter. > > As for resource isolation and provisioning of a VTN I think you really > need separate LSDB instances provided by MT or MI as better suited for > network slicing. MT does not provide LSDB separation, only MI does. thanks, Peter I thought that each MT topology was a separate RIB meaning separate LSDB. The RFC is confusing.😄 https://tools.ietf.org/html/rfc5120 6<https://tools.ietf.org/html/rfc5120#section-6>. MT SPF Computation Each MT MUST run its own instance of the decision process. The pseudo-node LSPs are used by all topologies during computation. Each non-default topology MAY have its attached bit and overload bit set in the MT TLV. A reverse-connectivity check within SPF MUST follow the according MT to assure the bi-directional reachability within the same MT. The results of each computation SHOULD be stored in a separate Routing Information Base (RIB), in normal cases, otherwise overlapping addresses in different topologies could lead to undesirable routing behavior, such as forwarding loops. The forwarding logic and configuration need to ensure the same MT is traversed from the source to the destination for packets. The nexthops derived from the MT SPF MUST belong to the adjacencies conforming to the same MT for correct forwarding. It is recommended for the administrators to ensure consistent configuration of all routers in the domain to prevent undesirable forwarding behavior. No attempt is made in this document to allow one topology to calculate routes using the routing information from another topology inside SPF. Even though it is possible to redistribute and leak routes from another IS-IS topology or from external sources, the exact mechanism is beyond the scope of this document. > > To me it seems a common LSDB shared among network slices VTN underlay > could be problematic with network overlap issues. > > Kind Regards > > Gyan > > On Fri, Mar 5, 2021 at 10:28 AM Peter Psenak <ppsenak@cisco.com<mailto:ppsenak@cisco.com> > <mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com>>> wrote: > > Hi Yali, > > On 05/03/2021 15:31, wangyali wrote: > > Hi Peter, > > > > Thanks for your question. Please see inline [yali3]. > > > > -----Original Message----- > > From: Peter Psenak [mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com> > <mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com>>] > > Sent: Thursday, March 4, 2021 11:20 PM > > To: wangyali <wangyali11@huawei.com<mailto:wangyali11@huawei.com> > <mailto:wangyali11@huawei.com<mailto:wangyali11@huawei.com>>>; Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com> > <mailto:hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net> > <mailto:robert@raszuk.net<mailto:robert@raszuk.net>>> > > Cc: Huzhibo <huzhibo@huawei.com<mailto:huzhibo@huawei.com> <mailto:huzhibo@huawei.com<mailto:huzhibo@huawei.com>>>; > Aijun Wang <wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn> > <mailto:wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>>>; Tony Li <tony.li@tony.li<mailto:tony.li@tony.li> > <mailto:tony.li@tony.li<mailto:tony.li@tony.li>>>; lsr <lsr@ietf.org<mailto:lsr@ietf.org> <mailto:lsr@ietf.org<mailto:lsr@ietf.org>>>; > Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com> <mailto:zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>> > > Subject: Re: [Lsr] New Version Notification for > draft-wang-lsr-isis-mfi-00.txt > > > > Hi Yali, > > > > On 04/03/2021 14:45, wangyali wrote: > >> Hi Peter, > >> > >> Please see inline [Yali2]. Thanks a lot. > >> > >> -----Original Message----- > >> From: Peter Psenak [mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com> > <mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com>>] > >> Sent: Thursday, March 4, 2021 6:50 PM > >> To: wangyali <wangyali11@huawei.com<mailto:wangyali11@huawei.com> > <mailto:wangyali11@huawei.com<mailto:wangyali11@huawei.com>>>; Gyan Mishra > >> <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com> <mailto:hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>>; Robert > Raszuk <robert@raszuk.net<mailto:robert@raszuk.net> <mailto:robert@raszuk.net<mailto:robert@raszuk.net>>> > >> Cc: Huzhibo <huzhibo@huawei.com<mailto:huzhibo@huawei.com> <mailto:huzhibo@huawei.com<mailto:huzhibo@huawei.com>>>; > Aijun Wang > >> <wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn> <mailto:wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>>>; Tony > Li <tony.li@tony.li<mailto:tony.li@tony.li> <mailto:tony.li@tony.li<mailto:tony.li@tony.li>>>; lsr > >> <lsr@ietf.org<mailto:lsr@ietf.org> <mailto:lsr@ietf.org<mailto:lsr@ietf.org>>>; Tianran Zhou > <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com> <mailto:zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>> > >> Subject: Re: [Lsr] New Version Notification for > >> draft-wang-lsr-isis-mfi-00.txt > >> > >> Hi Yali, > >> > >> On 04/03/2021 11:42, wangyali wrote: > >>> Hi Peter, > >>> > >>> Please review follows tagged by [Yali]. > >>> > >>> > >>> -----Original Message----- > >>> From: Peter Psenak [mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com> > <mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com>>] > >>> Sent: Wednesday, March 3, 2021 5:37 PM > >>> To: wangyali <wangyali11@huawei.com<mailto:wangyali11@huawei.com> > <mailto:wangyali11@huawei.com<mailto:wangyali11@huawei.com>>>; Gyan Mishra > >>> <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com> <mailto:hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>>; Robert > Raszuk <robert@raszuk.net<mailto:robert@raszuk.net> <mailto:robert@raszuk.net<mailto:robert@raszuk.net>>> > >>> Cc: Huzhibo <huzhibo@huawei.com<mailto:huzhibo@huawei.com> <mailto:huzhibo@huawei.com<mailto:huzhibo@huawei.com>>>; > Aijun Wang > >>> <wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn> <mailto:wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>>>; > Tony Li <tony.li@tony.li<mailto:tony.li@tony.li> <mailto:tony.li@tony.li<mailto:tony.li@tony.li>>>; lsr > >>> <lsr@ietf.org<mailto:lsr@ietf.org> <mailto:lsr@ietf.org<mailto:lsr@ietf.org>>>; Tianran Zhou > <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com> <mailto:zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>> > >>> Subject: Re: [Lsr] New Version Notification for > >>> draft-wang-lsr-isis-mfi-00.txt > >>> > >>> Yali, > >>> > >>> On 03/03/2021 06:02, wangyali wrote: > >>>> Hi Peter, > >>>> > >>>> Thanks for your comments. Yes. I am improving this sentence. > Please review the following update. > >>>> > >>>> OLD: " And Level 1/Level 2 PSNP and Level 1/Level 2 CSNP > containing information about LSPs that transmitted in a specific MFI > are generated to synchronize the LSDB corresponding to the specific > MFI." > >>>> > >>>> NEW: "And Level 1/Level 2 PSNP and Level 1/Level 2 CSNP > containing information about LSPs that transmitted in a specific MFI > are generated to synchronize the MFI-specific sub-LSDB. Each > MFI-specific sub-LSDB is subdivided from a single LSDB." > >>> > >>> please specify sub-LSDB. > >>> [Yali] Thanks for your comment. But to avoid introducing a new > term, I change to use "MFI-specific LSDB" instead of " MFI-specific > sub-LSDB ". And we give the explanation that "Each MFI-specific > LSDB is subdivided from a single LSDB." > >> > >> I wonder what is the difference between "MFI-specific LSDB > subdivided from a single LSDB" versus the "MFI-specific LSDB". > >> [Yali2]: Actually I am trying to optimize and accurately > describe the key point that multiple Update processes associated > with each MFI operate on a common LSDB within the zero IS-IS > instance, and each Update process is isolated from each other and > does not affect each other. > >> So we say "MFI-specific LSDB subdivided from a single LSDB", > which may explicitly indicate each MFI-specific LSDB shares a common > LSDB but each Update process associated with a MFI is isolated. > However, from your previous question and suggestions, "MFI-specific > LSDB" looks like unclear and misleading. Any good idea on improving > the expression are welcome. > > > > > > it's not the name that is as important. It's the concept that > looks questionable - how well can you isolate the update processing > if the data are part of the same LSDB and whether such update > process separation would prove to be useful at all. I don't know, so > far I have not seen any evidence. > > [yali3] This draft defines a new TLV, i.e. MFI-ID TLV, which may > be included in each Level 1/Level 2 IS-IS LSPs and SNPs. Hence, each > Level 1/Level 2 LSPs and SNPs associated with each Update Process > can be uniquely identified by MFI-ID. > > In this draft, each flooding instance has its own separated > Update process, which isolates the impact of application information > flooding on the IS-IS protocol operation. So each Level 1/Level 2 > LSP associated with a specific MFI carries flooding information > belonging to the specific MFI. And Level 1/Level 2 PSNP and Level > 1/Level 2 CSNP containing information about LSPs that propagated in > the specific MFI are generated to synchronize the MFI-specific LSDB. > > - by using the same LSDB to store the MFI specific information only a > limited separation can be achieved. Multi-instance gives you better > separation. > > - you carved the MFI specific LSP space from the common LSP space. This > may result in the non routing apps consuming the space that would > otherwise be required for regular routing information, compromising the > basic functionality of the protocol. Multi-instance does not have that > problem. > > my 2c, > Peter > > > > > > thanks, > > Peter > > > > > > > > > >> > >> thanks, > >> Peter > >> > >>> > >>> thanks, > >>> Peter > >>> > >>> > >>>> > >>>> Best, > >>>> Yali > >>>> > >>>> -----Original Message----- > >>>> From: Peter Psenak [mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com> > <mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com>>] > >>>> Sent: Tuesday, March 2, 2021 5:12 PM > >>>> To: wangyali <wangyali11@huawei.com<mailto:wangyali11@huawei.com> > <mailto:wangyali11@huawei.com<mailto:wangyali11@huawei.com>>>; Gyan Mishra > >>>> <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com> <mailto:hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>>; Robert > Raszuk <robert@raszuk.net<mailto:robert@raszuk.net> <mailto:robert@raszuk.net<mailto:robert@raszuk.net>>> > >>>> Cc: Huzhibo <huzhibo@huawei.com<mailto:huzhibo@huawei.com> <mailto:huzhibo@huawei.com<mailto:huzhibo@huawei.com>>>; > Aijun Wang > >>>> <wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn> <mailto:wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>>>; > Tony Li <tony.li@tony.li<mailto:tony.li@tony.li> <mailto:tony.li@tony.li<mailto:tony.li@tony.li>>>; lsr > >>>> <lsr@ietf.org<mailto:lsr@ietf.org> <mailto:lsr@ietf.org<mailto:lsr@ietf.org>>>; Tianran Zhou > <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com> <mailto:zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>> > >>>> Subject: Re: [Lsr] New Version Notification for > >>>> draft-wang-lsr-isis-mfi-00.txt > >>>> > >>>> Yali, > >>>> > >>>> On 01/03/2021 10:49, wangyali wrote: > >>>>> Hi Peter, > >>>>> > >>>>> Many thanks for your feedback. First of all, I'm sorry for > the confusion I had caused you from my previous misunderstanding. > >>>>> > >>>>> And I want to clarify that a single and common LSDB is shared > by all MFIs. > >>>> > >>>> well, the draft says: > >>>> > >>>> "information about LSPs that transmitted in a > >>>> specific MFI are generated to synchronize the LSDB > corresponding to > >>>> the specific MFI." > >>>> > >>>> If the above has changed, then please update the draft > accordingly. > >>>> > >>>> thanks, > >>>> Peter > >>>> > >>>> > >>>> > >>>>> > >>>>> Best, > >>>>> Yali > >>>>> > >>>>> -----Original Message----- > >>>>> From: Peter Psenak [mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com> > <mailto:ppsenak@cisco.com<mailto:ppsenak@cisco.com>>] > >>>>> Sent: Sunday, February 28, 2021 8:23 PM > >>>>> To: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com> > <mailto:hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>>; Robert Raszuk > >>>>> <robert@raszuk.net<mailto:robert@raszuk.net> <mailto:robert@raszuk.net<mailto:robert@raszuk.net>>> > >>>>> Cc: Huzhibo <huzhibo@huawei.com<mailto:huzhibo@huawei.com> <mailto:huzhibo@huawei.com<mailto:huzhibo@huawei.com>>>; > Aijun Wang > >>>>> <wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn> <mailto:wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>>>; > Tony Li <tony.li@tony.li<mailto:tony.li@tony.li> <mailto:tony.li@tony.li<mailto:tony.li@tony.li>>>; lsr > >>>>> <lsr@ietf.org<mailto:lsr@ietf.org> <mailto:lsr@ietf.org<mailto:lsr@ietf.org>>>; Tianran Zhou > <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com> <mailto:zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>>; wangyali > >>>>> <wangyali11@huawei.com<mailto:wangyali11@huawei.com> <mailto:wangyali11@huawei.com<mailto:wangyali11@huawei.com>>> > >>>>> Subject: Re: [Lsr] New Version Notification for > >>>>> draft-wang-lsr-isis-mfi-00.txt > >>>>> > >>>>> Gyan, > >>>>> > >>>>> On 26/02/2021 17:19, Gyan Mishra wrote: > >>>>>> > >>>>>> MFI seems more like flex algo with multiple sub topologies > sharing > >>>>>> a common links in a topology where RFC 8202 MI is separated at > >>>>>> the process level separate LSDB. So completely different and of > >>>>>> course different goals and use cases for MI versus MFI. > >>>>> > >>>>> I would not use the fle-algo analogy - all flex-algos operate > on top of a single LSDB, contrary to what is being proposed in MFI > draft. > >>>>> > >>>>>> > >>>>>> MFI also seems to be a flood reduction mechanism by > creating > >>>>>> multiple sub topology instances within a common LSDB. There > are a > >>>>>> number of flood reduction drafts and this seems to be another > >>>>>> method of achieving the same. > >>>>> > >>>>> MFI draft proposes to keep the separate LSDB per MFI, so the > above analogy is not correct either. > >>>>> > >>>>> thanks, > >>>>> Peter > >>>>> > >>>>> > >>>>>> > >>>>>> Gyan > >>>>>> > >>>>>> On Fri, Feb 26, 2021 at 7:10 AM Robert Raszuk > <robert@raszuk.net<mailto:robert@raszuk.net> <mailto:robert@raszuk.net<mailto:robert@raszuk.net>> > >>>>>> <mailto:robert@raszuk.net<mailto:robert@raszuk.net> <mailto:robert@raszuk.net<mailto:robert@raszuk.net>>>> wrote: > >>>>>> > >>>>>> Aijun, > >>>>>> > >>>>>> How multi instance is implemented is at the > discretion of a vendor. > >>>>>> It can be one process N threads or N processes. It > can be both and > >>>>>> operator may choose. > >>>>>> > >>>>>> MFI is just one process - by the spec - so it is > inferior. > >>>>>> > >>>>>> Cheers, > >>>>>> R. > >>>>>> > >>>>>> > >>>>>> On Fri, Feb 26, 2021 at 12:44 PM Aijun Wang > <wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn> <mailto:wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>> > >>>>>> <mailto:wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn> > <mailto:wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>>>> wrote: > >>>>>> > >>>>>> Hi, Robert: > >>>>>> > >>>>>> Separate into different protocol instances can > accomplish the > >>>>>> similar task, but it has<https://www.google.com/maps/search/ar+task,+but+it+has?entry=gmail&source=g> some deployment overhead. > >>>>>> MFIs within one instance can avoid such > cumbersome work, and > >>>>>> doesn’t affect the basic routing calculation > process. > >>>>>> > >>>>>> Aijun Wang > >>>>>> China Telecom > >>>>>> > >>>>>>> On Feb 26, 2021, at 19:00, Robert Raszuk > <robert@raszuk.net<mailto:robert@raszuk.net> <mailto:robert@raszuk.net<mailto:robert@raszuk.net>> > >>>>>>> <mailto:robert@raszuk.net<mailto:robert@raszuk.net> > <mailto:robert@raszuk.net<mailto:robert@raszuk.net>>>> wrote: > >>>>>>> > >>>>>>> Hi Yali, > >>>>>>> > >>>>>>> If this was precise, then the existing > multi-instance > >>>>>>> mechanism would be sufficient. > >>>>>>> [Yali]: MFI is a different solution we > recommend > <https://www.google.com/maps/search/lution+we+recommend?entry=gmail&source=g> > to solve > >>>>>>> this same and valuable issue. > >>>>>>> > >>>>>>> > >>>>>>> Well the way I understand this proposal MFI is > much weaker > >>>>>>> solution in terms of required separation. > >>>>>>> > >>>>>>> In contrast RFC8202 allows to separate ISIS > instances at the > >>>>>>> process level, but here MFIs as defined must > be handled by the > >>>>>>> same ISIS process > >>>>>>> > >>>>>>> This document defines an extension to > >>>>>>> IS-IS to allow*one standard instance* of > >>>>>>> the protocol to support multiple update > >>>>>>> process operations. > >>>>>>> > >>>>>>> Thx, > >>>>>>> R. > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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> > <mailto:Lsr@ietf.org<mailto:Lsr@ietf.org>>> > >>>>>>> https://www.ietf.org/mailman/listinfo/lsr > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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> > <mailto:Lsr@ietf.org<mailto:Lsr@ietf.org>>> > >>>>>> https://www.ietf.org/mailman/listinfo/lsr > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> <http://www.verizon.com/> > >>>>>> > >>>>>> *Gyan Mishra* > >>>>>> > >>>>>> /Network Solutions A//rchitect / > >>>>>> > >>>>>> /M 301 502-1347 > >>>>>> 13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> > >>>>>> /Silver Spring, MD > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > >> > > > > > > > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > /Network Solutions A//rchitect / > > /M 301 502-1347 > 13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> > /Silver Spring, MD > > -- [Image removed by sender.]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> Silver Spring, MD -- [Image removed by sender.]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD
- Re: [Lsr] New Version Notification for draft-wang… wangyali
- Re: [Lsr] New Version Notification for draft-wang… Tony Li
- Re: [Lsr] New Version Notification for draft-wang… Les Ginsberg (ginsberg)
- Re: [Lsr] New Version Notification for draft-wang… wangyali
- Re: [Lsr] New Version Notification for draft-wang… wangyali
- Re: [Lsr] New Version Notification for draft-wang… Tony Li
- Re: [Lsr] New Version Notification for draft-wang… wangyali
- Re: [Lsr] New Version Notification for draft-wang… Robert Raszuk
- Re: [Lsr] New Version Notification for draft-wang… Aijun Wang
- Re: [Lsr] New Version Notification for draft-wang… Robert Raszuk
- Re: [Lsr] New Version Notification for draft-wang… Acee Lindem (acee)
- Re: [Lsr] New Version Notification for draft-wang… Gyan Mishra
- Re: [Lsr] New Version Notification for draft-wang… Peter Psenak
- Re: [Lsr] New Version Notification for draft-wang… Gyan Mishra
- Re: [Lsr] New Version Notification for draft-wang… wangyali
- Re: [Lsr] New Version Notification for draft-wang… wangyali
- Re: [Lsr] New Version Notification for draft-wang… wangyali
- Re: [Lsr] New Version Notification for draft-wang… wangyali
- Re: [Lsr] New Version Notification for draft-wang… Tony Li
- Re: [Lsr] New Version Notification for draft-wang… Peter Psenak
- Re: [Lsr] New Version Notification for draft-wang… wangyali
- Re: [Lsr] New Version Notification for draft-wang… wangyali
- Re: [Lsr] New Version Notification for draft-wang… Peter Psenak
- Re: [Lsr] New Version Notification for draft-wang… wangyali
- Re: [Lsr] New Version Notification for draft-wang… Peter Psenak
- Re: [Lsr] New Version Notification for draft-wang… wangyali
- Re: [Lsr] New Version Notification for draft-wang… Aijun Wang
- Re: [Lsr] New Version Notification for draft-wang… Peter Psenak
- Re: [Lsr] New Version Notification for draft-wang… wangyali
- Re: [Lsr] New Version Notification for draft-wang… Gyan Mishra
- Re: [Lsr] New Version Notification for draft-wang… Peter Psenak
- Re: [Lsr] New Version Notification for draft-wang… Gyan Mishra
- Re: [Lsr] New Version Notification for draft-wang… Peter Psenak
- Re: [Lsr] New Version Notification for draft-wang… Gyan Mishra
- Re: [Lsr] New Version Notification for draft-wang… Les Ginsberg (ginsberg)
- Re: [Lsr] New Version Notification for draft-wang… Tony Przygienda
- Re: [Lsr] New Version Notification for draft-wang… Tony Przygienda
- Re: [Lsr] New Version Notification for draft-wang… wangyali
- Re: [Lsr] New Version Notification for draft-wang… Gyan Mishra
- Re: [Lsr] New Version Notification for draft-wang… Gyan Mishra
- Re: [Lsr] New Version Notification for draft-wang… Tony Przygienda
- Re: [Lsr] New Version Notification for draft-wang… Les Ginsberg (ginsberg)
- Re: [Lsr] New Version Notification for draft-wang… Aijun Wang
- Re: [Lsr] New Version Notification for draft-wang… Gyan Mishra
- Re: [Lsr] New Version Notification for draft-wang… Les Ginsberg (ginsberg)
- Re: [Lsr] New Version Notification for draft-wang… Les Ginsberg (ginsberg)
- Re: [Lsr] New Version Notification for draft-wang… Tony Przygienda
- Re: [Lsr] New Version Notification for draft-wang… Acee Lindem (acee)
- Re: [Lsr] New Version Notification for draft-wang… Gyan Mishra
- Re: [Lsr] New Version Notification for draft-wang… Les Ginsberg (ginsberg)
- Re: [Lsr] New Version Notification for draft-wang… Robert Raszuk
- Re: [Lsr] New Version Notification for draft-wang… Lizhenbin
- Re: [Lsr] New Version Notification for draft-wang… Lizhenbin
- Re: [Lsr] New Version Notification for draft-wang… Aijun Wang