Re: [Lsr] Request WG adoption of TTZ

"Acee Lindem (acee)" <acee@cisco.com> Tue, 07 July 2020 20:33 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 2BE753A0AD8; Tue, 7 Jul 2020 13:33:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=W7+QiRMS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=P/nR2qCc
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 nlSnZvuTrwFT; Tue, 7 Jul 2020 13:33:12 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B803A0ADF; Tue, 7 Jul 2020 13:33:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34071; q=dns/txt; s=iport; t=1594153990; x=1595363590; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+OVavABBTw/aEbDt1Ndmo0BNBEQSU8PU/ir3E/i3BCo=; b=W7+QiRMSEOiIbtW2P5x/FVbKWTRb8g7mHG4Rfhgglqpbx/PA6m4iAeWt lmIalz+Zuki63AnM39sP6Jk8qFq0cKcFMeA3J5xBXb2oytGfm7l09reyr tuQL+1b1E9bQrhBSR46bxd85NLTvCeEXo56qqhcXrDNISnikc6NKtGSEU k=;
IronPort-PHdr: =?us-ascii?q?9a23=3A3785ZxZ9G+chZyM9GkBJyB//LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QWTD4vG9+9ehvXbsubrXmlTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBrGCu8CQfBR?= =?us-ascii?q?j+cwFyI7e9Fovblc/i0ee09tXaaBlJgzzoZ7R0IV22oAzdu9NQj5FlL/M6yw?= =?us-ascii?q?DCpT1DfOEFyA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C1AADT2gRf/40NJK1gGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEBAQEBAQEBAQGCCoEjLyMuB29YLywKhCiDRgONKiW?= =?us-ascii?q?BAZdZgUKBEANVCwEBAQwBARgBCgoCBAEBhEcCF4F6AiQ4EwIDAQELAQEFAQE?= =?us-ascii?q?BAgEGBG2FWwyFbgEBAQECAQEBEBEKEwEBLAsBBAsCAQgRAwEBAQEgCgICAiU?= =?us-ascii?q?LHQgCBAEJBAUbB4MEAYF+TQMOIAEOnzQCgTmIYXaBMoMBAQEFgTYCDkFCgk8?= =?us-ascii?q?Ygg4DBoE4AYJoigEaggCBEAEnDBCBT0kHLj5rGQGBVwEBAwGBJgESASYDFwE?= =?us-ascii?q?GB4JpM4Itjw0JGIMNhkOKYZEwCoJciEuQfwMdgnOYRoNkRI9DgVOBZXmHPpR?= =?us-ascii?q?FAgQCBAUCDgEBBYFqImZwcBU7KgGCPlAXAg2OHhiDWYUUhUJ0NwIGAQcBAQM?= =?us-ascii?q?JfI5IAYEQAQE?=
X-IronPort-AV: E=Sophos;i="5.75,325,1589241600"; d="scan'208,217";a="524146221"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Jul 2020 20:33:09 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 067KX9xI027443 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Jul 2020 20:33:09 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 7 Jul 2020 15:33:08 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 7 Jul 2020 16:33:08 -0400
Received: from NAM04-BN3-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; Tue, 7 Jul 2020 16:33:08 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cUb8O9JtTQRc59X371sca2sAJ3uj67FvT4ZYlMPN663c7jrQbnyzn0ReM3olgwluSvWSgfvECkuGqQ6ssqsRYr8Fyd7H23nnfSjESadPTa0ztRipIvJQV4PzPosEPIXpvhZXV2PS6JpFfSk/wQB1ZZjF3iRT6hhxero0pTmiu/Z7bMm0lE62RfbK0pfRlf9tWczDRCyNlLlGlApx+FofPjiK0TVjo4XfY7g39i5C3741SA2B/GW/JQBF6ufvM07AO59l+BoXXQmON5s5ggkqwlA0tM9XsyiKzd8jSYYttwQzLCjF5lFGGMtZ4co/zpeJXCPxEuazMuemZYezpqBkdw==
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=+OVavABBTw/aEbDt1Ndmo0BNBEQSU8PU/ir3E/i3BCo=; b=hhdRKyaHsxR7L3cciGu761a7IU302dNFfYuSqLJWM6M89tUIa+vkEkssTON31mLhNHS4nJVgC4jTuZq/eg/TGTJU/rNsGRkYEAq7QeLYrcKyqc95iVHWMKGmQTC/XVF8l4KGE/0rHzCV7QJds++jjERGkcIbmS6dbPHVE2DwhgBtj/Iqb0viY9LHQFMK+Yc4uOF4+tUi+ENhW8XUzpWr/Y3gdicsDLm/kLHyvO6ANXxldA1Y4LQDmYMH7zRQriazajlocTiTRv0Z+yzIN5/J9g8pwnu1y04IKb3NlQuk43uvXfsh4lta8eZA8TMtCnsbXiS1i+xYLeQlu1c1GCAevw==
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=+OVavABBTw/aEbDt1Ndmo0BNBEQSU8PU/ir3E/i3BCo=; b=P/nR2qCc+TDgBA9vzp3I4hGOdPQkz59j2GbyDVncyFw5NxYfdvSvcWcl/QfFI6VzTJfWk3pp84f04410goFwjiYBxKcX3sKF0WizevxNI7mdu4ISbznSHNTKceBGUV0UmxkGtMP/qT+jjBxAbHycQgYzvtG2+YpcFdRK154syCo=
Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BY5PR11MB4134.namprd11.prod.outlook.com (2603:10b6:a03:18e::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.27; Tue, 7 Jul 2020 20:33:07 +0000
Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::70a6:bb5b:16b:4f9b]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::70a6:bb5b:16b:4f9b%7]) with mapi id 15.20.3153.029; Tue, 7 Jul 2020 20:33:07 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Huaimo Chen <huaimo.chen@futurewei.com>, Christian Hopps <chopps@chopps.org>
CC: "lsr@ietf.org" <lsr@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>
Thread-Topic: [Lsr] Request WG adoption of TTZ
Thread-Index: AQHWVGicPoPdjzgOb0WVPu9ygU3J3aj8T8KA
Date: Tue, 7 Jul 2020 20:33:06 +0000
Message-ID: <88A859DB-34D7-4695-A433-0C39D20749EB@cisco.com>
References: <MN2PR13MB3117B443411BDA4E4F4DFC03F2660@MN2PR13MB3117.namprd13.prod.outlook.com>
In-Reply-To: <MN2PR13MB3117B443411BDA4E4F4DFC03F2660@MN2PR13MB3117.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.38.20061401
authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [136.56.133.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 31073cba-5049-40ee-c815-08d822b4f4d6
x-ms-traffictypediagnostic: BY5PR11MB4134:
x-microsoft-antispam-prvs: <BY5PR11MB413410EF8937332DDE9FB035C2660@BY5PR11MB4134.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0457F11EAF
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: MEvHtGTM8QsRvoX1D5zUFAHV+RDcFKHcPnMirQKKNaSLm7b/HgG1aUfyynefZhZ45TYNLTxcigMPsfqhYwkjsqJj/1rd9E2RSQea3fsj7mmoBwafCBkj98ndTmxgwDJze947wiFfgTSlU9IpGqjdsDVXfQnnw+6ouTiw1hZ0VxLsxvSG3pUob9xe/vY2R5Ox+2ppmYrpe7UszKIdBxHxU/KtRKIgQHQQgpm7rZkeArXThoJwxjJtg+CJ55CN2YLE0RhtlpuC2bdsS+4FfHnXcIiPvrA3A5fPlj9EYVhBdteyyBcI2VAcAq82JfHQIQOvOYESplyrIdhXtAXk0RoULGgidn44S/JicsuR02U9triivKd5++nZ4iQQxw39LhtzVW45Od1Z+hIDQXzYzJxwdg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(39860400002)(136003)(366004)(396003)(83380400001)(478600001)(86362001)(8676002)(6506007)(2906002)(53546011)(5660300002)(316002)(166002)(54906003)(966005)(66574015)(36756003)(6512007)(6486002)(71200400001)(8936002)(110136005)(33656002)(91956017)(76116006)(26005)(186003)(4326008)(2616005)(66946007)(66556008)(64756008)(66446008)(66476007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: P5dK9GQwS4CxV/I2ql4v2JaCNn/lqexM3tXruRo/CWSaLs3CRLdN5Dj9ie86/sRyiLETbUoofzWBGizD3ze1xvWTFOrD3xM7Xb/M2W4vkyUNtOoMnw2sFQ55Cni26QI6sdGSyLVCRaM8VhKAFummeqVxIxGAq4UudCfLcnH/b3MQ6/937S9aRe1Al6eS2mVp4HBEv/bHV4UMEiPVMqIYhWZ7aUWBc6Ej/v5MlKh2KWFktC0b1FBmy8apqCS3f7936DcEZgcRxsjYEJl43+O8NuvMVt56F0mc3due1C+PjOYVWoHRjO511tAVoYcVX8pnsGd34nkVdMmZmP4HrA7iLM1AgaHtqlgD+KHnivwckIpi3WjZbL+BlWLanFOnHCPatibLe0rJMEWKa3QVUESPIp5LeEbNtrtIj3FAgvtJ6bqf/ziQz6JJ/e2uBnOAAReZTTDrhP2M30uPicylADk4wh6XcPZ1vDwCptiYWseoWUJOpokjDIs6L6Qmz7LTP8h7
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_88A859DB34D74695A4330C39D20749EBciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 31073cba-5049-40ee-c815-08d822b4f4d6
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2020 20:33:06.7670 (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: OuHLEX8BmG0Sp9cmqIGkb6lslrLW8LX7TQzWGeT92iTghaHzg5u14+Gry0+pacZx
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4134
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/DsgjmHxDGVHyyaQyMAypI8gw5ps>
Subject: Re: [Lsr] Request WG adoption of TTZ
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: Tue, 07 Jul 2020 20:33:18 -0000

Speaking as WG member:

Hi Huaimo,

Independent of the major issue with Area Proxy differentiation, I have a couple other issues that I didn’t want to include in the same Email thread.


  1.  You can’t describe IS-IS protocol details and then just include OSPF encodings and expect the readers to intuit the OSPF specific details. These area abstraction drafts modify basic protocol mechanisms and OSPF details would be better specified in an update to RFC 8099 then just adding encodings to this IS-IS TTZ draft.
  2.  The draft uses the term IS-IS Pseudo-node yet this is defined in IS-IS as a specific LSP to represent a multi-access network. I don’t know if the usage of the terminology was meant to differentiate the mechanisms from Area Proxy but I find the repurposing of the term pseudo-node in the context of IS-IS very confusing.
  3.  The document keeps referring to  “edges full mess” and I believe you mean “edges full mesh”.


Thanks,
Acee

From: Lsr <lsr-bounces@ietf.org> on behalf of Huaimo Chen <huaimo.chen@futurewei.com>
Date: Tuesday, July 7, 2020 at 12:01 PM
To: Christian Hopps <chopps@chopps.org>
Cc: "lsr@ietf.org" <lsr@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Chris,

    Thank you very much for your questions.
    My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo
________________________________
From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; lsr-chairs@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar solutions, right?

[HC]: There are some differences even though they looks similar.
At first, the target to be abstracted in Area Proxy is different from that in TTZ.
Area Proxy abstracts an existing area to a single pseudo node.
TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an area.
An area is different from a zone in general.

Secondly, the ways in which they are applied to an area for scalability are different.
When an area becomes bigger and bigger, we may have scalability issues. Using TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes smoothly without any interface down. Using Area Proxy, we need split the existing area into multiple areas, and then abstract one or a few areas to one or few pseudo nodes.
These differences will produce different user experiences.
For splitting an existing area into multiple areas, users may need put more efforts since it causes service interruptions in general. While splitting an area such as an OSPF area into multiple areas, the area numbers configured on some interfaces will be changed and each of these interfaces will be down with its old area number and then up with its new area number. These interface downs and ups will cause service interruptions in general.
For defining zones in an area, users may need less efforts since abstracting a zone to a single pseudo node is smooth without any interface down.

Moreover, TTZ provides smooth transferring between a zone and its single pseudo node. That is that a zone can be smoothly transferred to a single pseudo node, and the pseudo node can be smoothly rolled back to the zone.

BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a single pseudo node.
In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, and a zone in an IS-IS area to a single pseudo node.


There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i found it confusing to have this document also talking about TTZ for OSPF; is it redefining it, updating it, just referring to it?

[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for abstracting a zone to the zone edges full mess. This document proposes a new solution for abstracting a zone to a single pseudo node. The new solution re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for the new solution are defined in the document.

Thanks,
Chris.
[chair hat]


> On Jun 18, 2020, at 11:38 PM, Huaimo Chen <huaimo.chen@futurewei.com> wrote:
>
> Hi Chris and Acee, and everyone,
>
>
>
>     I would like to request working group adoption of "Topology-Transparent Zone"
>
> (TTZ for short) https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ .
>
>
>
>     This draft comprises the following solutions for helping to improve scalability:
>
>         1) abstracting a zone to a single pseudo node in IS-IS,
>
>         2) abstracting a zone to a single pseudo node in OSPF,
>
>         3) abstracting a zone to zone edges' full mess in IS-IS, and
>
>         4) transferring smoothly between a zone and a single pseudo node.
>
>     A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or
>
> non-backbone area).
>
>
>
>     When a network area becomes (too) big, we can reduce its size in the sense
>
> of its LSDB size through abstracting a zone to a single pseudo node or
>
> abstracting a few zones to a few pseudo nodes.
>
>
>
>     While a zone is being abstracted (or transferred) to a single pseudo node,
>
> the network is stable. There is no or minimum service interruption.
>
>
>
>     After abstracting a few zones to a few pseudo nodes, if we want to reconstruct
>
> them, we can transfer (or roll) any of the pseudo nodes back to its zone smoothly
>
> with no or minimum service interruption.
>
>
>
>     We had a prototype implementation of abstracting a zone to zone edges' full
>
> mess in OSPF. The procedures and related protocol extensions for transferring
>
> smoothly from a zone to zone edges' full mess are implemented and tested.
>
> A zone (block of an OSPF area) is smoothly transferred to its edges’ full mess
>
> without any routing disruptions. The routes on every router are stable while
>
> the zone is being transferred to its edges' mess. It is very easy to operate
>
> the transferring.
>
>
>
>     There are two other drafts for improving scalability: "Area Proxy for IS-IS"
>
> (Area Proxy for short) and "IS-IS Flood Reflection" (Flood Reflection for short).
>
>
>
>     "Area Proxy" https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03
>
> abstracts an existing IS-IS L1 area to a single pseudo node.
>
>
>
>     "Flood Reflection" https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01
>
> abstracts an existing IS-IS L1 area to its edges' connections via one or more
>
> flood reflectors.
>
>
>
>     We believe that TTZ has some special advantages even though
>
> Area Proxy and Flood Reflection are very worthy. We would like
>
> to ask for working group adoption of TTZ.
>
>
> Best Regards,
>
> Huaimo
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr