Re: [Lsr] Request WG adoption of TTZ

Liu Vic <vic.liu.cmcc@gmail.com> Sat, 11 July 2020 17:37 UTC

Return-Path: <vic.liu.cmcc@gmail.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 175523A1123; Sat, 11 Jul 2020 10:37:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2dg_mvLFhEpa; Sat, 11 Jul 2020 10:37:40 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD07A3A116B; Sat, 11 Jul 2020 10:37:35 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id d18so9330889ion.0; Sat, 11 Jul 2020 10:37:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KU6FWBMGhcD+SoEJ/xeRTyNuVOBsSbhHedh2RNkbSuU=; b=hm2IRar9iB4SdMEZ4i0iLw1vIh33v740EyJTqrsRJzGYfPqz+/GdIo9h/LDCmnDnD9 rt5rGqFHSFsU0p0WwDx9WDNeoYGpfaPI0yse2S7tf2NSVV25B0xlL57HPe33HZirgPd8 013ZffR3EqUcCNEgpcaApLiDUYR+c+kMOYhh7LFBLmKzsVKN9bT2QKX5z5nDfu2b0o9m 05fsFha7ISKNNrjPyOC619c9w/cza5hPzPd83nAXfTYI6GDvTx5wgVdJx/dLPFNASD9r fwIsCL+FWVjk6r6Ge/QJSStK/l1s0mmXIm5MVSjhmdDNvizfqvtlclb5RWs7JTvIxxl7 nQZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KU6FWBMGhcD+SoEJ/xeRTyNuVOBsSbhHedh2RNkbSuU=; b=mkcA6Tl8koFXBu3pe5JluVsDuzYHlItOo0uPNbuZon2LDX+QnY+qNwXLQsu+b/nE30 zxRzpEFVRfR7EFT9K1ufHa2fYyhkSTym8Ald6sRYOBD19adZdpK/8ncmn4Wn3cTagsxe BlYmjyzqwdQFkp4Unq+ylruKg366CKqNUOPbSS3UveVPXcVWPY7ATY/RRn8RBSx8jgch 8MwNBESAAew3yT9z+IDrXugqKPlbhbsgnajtefaw+ibFluE3Fouz0S+QpDcTgQmMQpRA RtmbP1nizUx9QSiAelEhbHyli63P9Y7o90JY0XhO0RXTMM+RhDSJL40qqKZWMm23EM5n NVyQ==
X-Gm-Message-State: AOAM5317QQXHrfXdZrYepe3XlwJrSdcjHTvy3SwlWNaLAg8xoc/gn+WH u7U6aU18uSrUNV9SveMGD2qFCjbu0o3JplFYhko=
X-Google-Smtp-Source: ABdhPJyWKKNg4WlT+wp2zssRsxv3hV8911Qnd+zO7JDiN4AlXImNWiVTb+stIk/L7+1xCYlFkaFXpaz1zYWxRiGWk/g=
X-Received: by 2002:a6b:8e94:: with SMTP id q142mr41909560iod.208.1594489054963; Sat, 11 Jul 2020 10:37:34 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR13MB31178756BB6166B2F1807CF6F2980@MN2PR13MB3117.namprd13.prod.outlook.com> <CAF18ct4VtDckw4971SG5qeLT-Qj-o9RCRkDCA=iK7+bj8zOdyw@mail.gmail.com> <CAC38=VFcy=J=zOpEBThJ6-6ot-6F-PSL7MSDFfDfEpAEtKRy4A@mail.gmail.com>
In-Reply-To: <CAC38=VFcy=J=zOpEBThJ6-6ot-6F-PSL7MSDFfDfEpAEtKRy4A@mail.gmail.com>
From: Liu Vic <vic.liu.cmcc@gmail.com>
Date: Sat, 11 Jul 2020 10:37:25 -0700
Message-ID: <CAE+E3M6nBd+JsNzGLeXrXxX_12DnA9ORBa=jYzJKZF5tqAD_WQ@mail.gmail.com>
To: Anil Kumar <anil.ietf@gmail.com>
Cc: Uma Chunduri <umac.ietf@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>, Huaimo Chen <huaimo.chen@futurewei.com>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b82e7b05aa2de963"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/OzSlyiEh-gIe5ckGzR8m-Nfa6gU>
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: Sat, 11 Jul 2020 17:37:42 -0000

Using TTZ for network scalability will keep good customer experience. TTZ
draft should be adopted.
I would support the IS-IS TTZ solution for WG adoption.

Vic

Anil Kumar <anil.ietf@gmail.com> 于2020年7月11日周六 上午9:22写道:

>
>  I would support the IS-IS TTZ solution for WG adoption.
>
> With Regards
> Anil S N
>
> On Sat, Jul 11, 2020 at 4:38 AM Uma Chunduri <umac.ietf@gmail.com> wrote:
>
>>  I would support the IS-IS TTZ solution for WG adoption.
>>
>>
>> Of course, obviously not with OSPF encodings or concepts only relevant to
>> OSPF (thx for the updated version).
>>
>> Thanks for the good work which was started way back on TTZs with OSPF
>> protocol first (RFC 8099).
>>
>>
>> I will send my specific comments/suggestions a bit later.
>>
>> --
>>
>> Uma C..
>>
>>
>>
>> On Thu, Jun 18, 2020 at 8: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
>>>
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>