Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Kiran Makhijani <kiranm@futurewei.com> Thu, 03 September 2020 21:07 UTC

Return-Path: <kiranm@futurewei.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 EA0FA3A0F02 for <lsr@ietfa.amsl.com>; Thu, 3 Sep 2020 14:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_REMOTE_IMAGE=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com
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 3It20zQCFjkF for <lsr@ietfa.amsl.com>; Thu, 3 Sep 2020 14:07:01 -0700 (PDT)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2093.outbound.protection.outlook.com [40.107.237.93]) (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 54DCE3A0EC1 for <lsr@ietf.org>; Thu, 3 Sep 2020 14:07:01 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LlOr0AjhpTF4+XTXfjoDz0FExu6AV+e7entzyf7/+KQXKj2o6VKsNV4shHIjzP1SFme+dd96kx+7yztk7ZHlxFQ4t8rXYU0YSY2z4cjSiyZQCdRtCkRXN+yK9D5nLcCuns0ICaH969QVYkNvPM4n63AJoGjtyVkxDYCWlyWruIZoSI4xst4dPg02f70W5a/+HstfWnLiuAeByc+BE2Ob8L8xXQAbGuH0NMntpkgpzQs48PSOO8rMy5SR+1y7dL8QRcPdKwZ6bfH3QgiaUdzHns+OEKtIC5pEB8NI1DpiNwBFOkFn54PGl7p6PdF84zAM8b9kYxskqEXOd8V6SXDshg==
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=j59nItWcdPGFMg1uOuNRPZsiGGgBq0mT/cUx6LLF+tk=; b=PkhS00qDU9SLRpjVKTkawPsOgm3VXGCA2Jo/EeNaS8FENgpWL7TRUyDUBZ4tPkgxLUhmCQ6ZjvWvbe2NEf7wtlWEdzUzZhFhpgih5yCr8F/TmVS4OLBtoWSkmWCttHVeVGAjW/j9iiFlYZFG6e8a47Pqg21dQAReegY6KU4FBwJX1J40a5jIkT0zbxkD64tBSOLfETM2Zw/kY3CaXiopMxZHdjLRolg5AAwVwaLL4KMk0Q8ztAY3k9MAvhxh/Ez3UiUKJOHTEhbd4X+ditRiuRAP7ojEv+4yRRfNPncbJzmt0jMnokd5C5AlYZyrOUGEtAjXQFCoId8yeZSWehPKNg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j59nItWcdPGFMg1uOuNRPZsiGGgBq0mT/cUx6LLF+tk=; b=e1vSRCQYO9HJUDJnfsmQqEis4BBE8x4/4bNlFCruX7A26RiwpiSA0lNnhf6xVIrOzklSrgwDfSJQhl1RVWUyMaGRNw1wqp/I8WbhpvnGw8r9toc9ochopdpIczgCdtdPOLdi6K2oQEzcRIV4o44BpyjphUQsCg2+BSbqKA6a1Yo=
Received: from BYAPR13MB2437.namprd13.prod.outlook.com (2603:10b6:a02:cb::23) by BY5PR13MB3812.namprd13.prod.outlook.com (2603:10b6:a03:21b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.5; Thu, 3 Sep 2020 21:06:53 +0000
Received: from BYAPR13MB2437.namprd13.prod.outlook.com ([fe80::4596:6de4:d7fe:66ee]) by BYAPR13MB2437.namprd13.prod.outlook.com ([fe80::4596:6de4:d7fe:66ee%3]) with mapi id 15.20.3348.014; Thu, 3 Sep 2020 21:06:52 +0000
From: Kiran Makhijani <kiranm@futurewei.com>
To: Gyan Mishra <hayabusagsm@gmail.com>, Robert Raszuk <robert@raszuk.net>
CC: Les Ginsberg <ginsberg@cisco.com>, "tony.li@tony.li" <tony.li@tony.li>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>, Huaimo Chen <huaimo.chen@futurewei.com>
Thread-Topic: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt
Thread-Index: AQHWdWo2KYWgaPUbtk6IEMCEThi+P6k+WrRAgAACWkyAAAswwIAAAtBBgAAGkACAFNDdQoAAtFOAgADCeoCAABjfAIAAQTeAgAARyQCAAEn4gIACDqwQ
Date: Thu, 03 Sep 2020 21:06:52 +0000
Message-ID: <BYAPR13MB243725BD9069645BB040725BD92C0@BYAPR13MB2437.namprd13.prod.outlook.com>
References: <F30AFA48-367E-4B32-B6E1-390B07507410@cisco.com> <BY5PR11MB4337D71462A6D7AF48C0E75EC15C0@BY5PR11MB4337.namprd11.prod.outlook.com> <MN2PR13MB3117C2EB2A0275AAC50671D1F25C0@MN2PR13MB3117.namprd13.prod.outlook.com> <BY5PR11MB4337CC18142C5355FB00BB80C15C0@BY5PR11MB4337.namprd11.prod.outlook.com> <MN2PR13MB3117E8AE76A4A22ECD649B68F25C0@MN2PR13MB3117.namprd13.prod.outlook.com> <BY5PR11MB4337FDF6AD2773B7DB70D67EC15C0@BY5PR11MB4337.namprd11.prod.outlook.com> <MN2PR13MB3117C29A75A371B630C62B00F22E0@MN2PR13MB3117.namprd13.prod.outlook.com> <975EC661-7C9F-4E0E-8B3D-EF3F0584659A@tony.li> <04351a69c1ee48f9b9f2f22b349db01a@huawei.com> <BDFC2601-B568-4211-A8E7-6C2EAC95F4EB@tony.li> <3d930fc3401449769e2f016c5d7bb0c2@huawei.com> <CAOj+MMHJXTcGrgcQmyHSCiX4uBwFB47PuChCcxvTHFZQpWJ7OQ@mail.gmail.com> <CABNhwV2-F-vXY2rRXmzmVZipLQ_gxc_7hVqa51phxkTH-7RYxQ@mail.gmail.com>
In-Reply-To: <CABNhwV2-F-vXY2rRXmzmVZipLQ_gxc_7hVqa51phxkTH-7RYxQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [67.188.27.49]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 23d03878-f7cb-4311-622d-08d8504d485d
x-ms-traffictypediagnostic: BY5PR13MB3812:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BY5PR13MB381289439CB36BDEFABC7B2AD92C0@BY5PR13MB3812.namprd13.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: 1gP0xnLAYAJy+cByEwD7wWN36CVoiJGw/9KJBqMym4sTcwi2ByRonJkyiT3astWAdvm1x3bL6oyYwGixxs0JcaJOaQ++OpPR5EgTuL4S7XII0evsAeBdv9/O+Dxmc1Synb3QcfN6D6tGh4DFWcmoiPg0V/RsHWFHGW429f4AtpDPR6U7Rz5OAEEqfIYFT1EjM4Z1GeSiSjdqxFAY5rlv9H5NaFLBzYkkif5oSxZtrwNs5QT/AXYXADpEqTQERkhHPVjboFX3TNugNJpRo3j5VWF0IMLAFfud/NOpjdQO//Ze3Rdp6twRLDmkKNMrdBDEI7KBbVXUsiU9DPJsqfKkkpTfwtQCR8WdVpApJZHC5PztH58GEM+TWgwawdRe7QccecyV2WP7M4sUrBcJjFOKTA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR13MB2437.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39840400004)(346002)(376002)(366004)(136003)(396003)(64756008)(76116006)(6506007)(53546011)(7696005)(166002)(54906003)(8936002)(2906002)(478600001)(66476007)(66946007)(26005)(66556008)(83380400001)(4326008)(316002)(110136005)(66446008)(86362001)(9686003)(5660300002)(33656002)(71200400001)(966005)(55016002)(186003)(107886003)(8676002)(52536014); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: TaVZLpfWA7ocqnpv7EIjNTHFje7nh6m2x2K0algLlNeXsGvV7ME6UY9snVuzBOXwCUg5Nr3o7GIccuq2WsP5ddzWs8kPpQmxlbNMs6G9CElJ0v2sTlMWXq2hO4MyILAnRjK7U9dy+4ovzVX+W68DZ6ltwlf8/CMszihH5CiUov5ljNHwRA25ha3yHk2AsfKverE9/0MLX0agXFts2L3RJKg3XBMFLXJaQPbPO6WdieMymDWACcVjXLy9n8TJWtDkdib0m+sNW8+woS9Je3sKpcvVLJO0rsiS3aXHGNx3tADnaOUO1Lj0n/JxKP7HadXptMK5yQtDRNisjG0egUkZ1eQnmLQT8Ur6j29dpfeCc8E/VIlKIcS8GRLhOs7tZJbcH8izk7LGtJemTm6i5kdTg8eNEj55lirz+cCBal4Nl6tvg8g77bEOfdyBfXGkTTcJgQEOFeMWf1l7xXTCgZEE9GoQBQNCyUGzph4Pfga1ldoaGVjUgyG557AYn8Uoq41a72MciyrQQMrbeAs7R2pLemV1X2p4KaoCaGmjN/+Wse1uROOieBIvZRhaKVM71W0r4MTMWK37Ry2sL6nK37i8T7aQL68JLxmWswLeF1g+MomNGbW2Pdwvgfh2bxL/02XFHzJbktJm1hC4UjKQSnncHQ==
Content-Type: multipart/alternative; boundary="_000_BYAPR13MB243725BD9069645BB040725BD92C0BYAPR13MB2437namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR13MB2437.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 23d03878-f7cb-4311-622d-08d8504d485d
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2020 21:06:52.8969 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QDFrj5z+Nhc5Kj6fyLr4AQdx+oV4TQHCSIyPFJYoAM3jmAZGvrjI0r0sSL6mRDzWhPAgrhUkYjdFPOaqtS2+Xw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3812
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/wfEs3AL1CtJFEVTXoQfYukUpoGE>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.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: Thu, 03 Sep 2020 21:07:04 -0000

Yup, that can be done. But I see steps such as ATT configuration as an additional effort when splitting areas. With TTZ, this propagation is not needed. Given that an operator has chosen to split the area anyway, TTZ process and config steps are relatively simple explained earlier (https://mailarchive.ietf.org/arch/msg/lsr/NxNJRUulSnGaR5PNBJv5x1kxUTw/).
-Kiran

From: Lsr <lsr-bounces@ietf.org> On Behalf Of Gyan Mishra
Sent: Wednesday, September 2, 2020 6:29 AM
To: Robert Raszuk <robert@raszuk.net>
Cc: Les Ginsberg <ginsberg@cisco.com>; tony.li@tony.li; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>; Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>; lsr@ietf.org; Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>; Huaimo Chen <huaimo.chen@futurewei.com>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt


Since careful planning and design is required to split a L1 Area into L1a L1b using TTZ as this is a major effort to plan out.  It maybe easier as part of the planning effort to just create two separate L1 areas that have different L1/L2 attachment points for the attach bit to be propagated.  Use existing ISIS machinery to now create two new smaller L1 areas.

Kind Regards

Gyan

On Wed, Sep 2, 2020 at 5:04 AM Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:

>  acknowledged problem (IGP scalability)

Great so we see the problem description. This is progress !

Allow me to observe two points:

* IGP scalability can be easily solved with the additional levels of current abstraction instead of introducing new types of abstraction into it. Ref: draft-ietf-lsr-isis-extended-hierarchy

* Most scaling aspects I have seen in practical deployments with IGPs are not caused by the suboptimal protocol design. Those are caused by requirements introduced by some transport technologies which (at least originally) required flooding of host routes domain wide for exact match of FECs to prefixes. I do not see how TTZs would address that aspect in any better way than areas can.

Thx,
R.


On Wed, Sep 2, 2020 at 10:00 AM Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>> wrote:













Hi Tony,



My intension was not to talk about math/engineering/marketing or compare the size of marketing

department. Them are not relevant to this thread.

I want to make clear about IETF process. In my understanding the document does not need to be

perfect at this stage, as long as it is in the right direction to solve some acknowledged problem( IGP scalability). Comments will be helpful if it could provide ideas about how to improve.

But IMO the discussion in the mailing list about this draft has gone off the rails of technology,

including keeping challenging tradeoff between value and complexity, which seems reasonable at the first sight, but at this stage, has turned out to be a question with no right answer and may bring endless argument.





Thanks

Xuesong





From: Tony Li [mailto:tony1athome@gmail.com<mailto:tony1athome@gmail.com>]

On Behalf Of tony.li@tony.li<mailto:tony.li@tony.li>


Sent: Wednesday, September 2, 2020 12:07 PM


To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>


Cc: Huaimo Chen <huaimo.chen@futurewei.com<mailto:huaimo.chen@futurewei.com>>; Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>>; Les Ginsberg <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org>


Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt









Hi Xuesong,










Apologies first if I have missed any history of this discussion. But I’m not sure that we have to evaluate whether a method

is “optimal” before WG adoption. Why not adopt some alternative solutions and leave the choice to industry/market?












First off, this is engineering, not theoretical math.  Optimal is not the issue. Heck, optimal isn’t even a goal.








What we are looking for is value and value that outweighs the complexity.







Leaving the choice to the market is a bad idea. The market does NOT make sound technical decisions. It makes pseudo-random decisions not based on technical merits. The canonical example here is VHS vs Betamax. Better

technology lost.







Second, the market is unduly influenced by marketing. The size of your marketing department exceeds the size of my entire (not tiny) company. And it’s still second to that of Cisco.







Marketing does not make good technical and architectural decisions. That’s our job.







Tony











_______________________________________________


Lsr mailing list


Lsr@ietf.org<mailto:Lsr@ietf.org>


https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Ckiranm%40futurewei.com%7Cbf82756deb714596bfd108d84f444b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637346502051754821&sdata=wdakWTmkB8JIKCqDCBdMW56irI8Il6rNAnzHPNzd7IA%3D&reserved=0>



_______________________________________________

Lsr mailing list

Lsr@ietf.org<mailto:Lsr@ietf.org>

https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Ckiranm%40futurewei.com%7Cbf82756deb714596bfd108d84f444b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637346502051764815&sdata=3pldswAxXCXRwWk7hUb9HcE6yENHFAGplsblbji1q9w%3D&reserved=0>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7Cbf82756deb714596bfd108d84f444b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637346502051764815&sdata=Fk%2F2rg%2FZ4gsqMesojLS%2BL0Wt9sF6zLUgKe9kwrMfPZo%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD