Re: [Lsr] Request WG adoption of TTZ

Anil Kumar <anil.ietf@gmail.com> Sat, 11 July 2020 16:22 UTC

Return-Path: <anil.ietf@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 C4AFE3A1039; Sat, 11 Jul 2020 09:22:43 -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 xzb3NwApCZKH; Sat, 11 Jul 2020 09:22:38 -0700 (PDT)
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 E3E853A1036; Sat, 11 Jul 2020 09:22:37 -0700 (PDT)
Received: by mail-il1-x131.google.com with SMTP id h16so7644781ilj.11; Sat, 11 Jul 2020 09:22:37 -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=tNPxsPSZpGEfAaV1jQv1EGLoGwV8X4xXgTu60c4ZmOs=; b=vIlb5F709Nps7uOjx9VzbsDT0q+Rn8BsYNe4f3KDvHUTFXRtlOw9/uwDI9OaKz3GCI ixcpoYqs6SPr/VCm/obG3bw04cZenyBZmPyBNQ3qFye5SwzmRN2uKgjSloLZFXmQOGUk 8J9mDEbZXzTg2vP9bYkicEvP3JKZNdlIr4DRIZ3V4q5RLrVYmBeDMrZVO8L6rdNOLVXP l5+ecvcmFL3ZaP/So9rOeWkT+9xDvHKdWrIXOBjFZCRJl+5RIweTl4WepBi754RImaaD Q5rJUX53v/hHXJ2uGbeGCLPGkiNOrPPGNSEqRSKulfPGeBykLzmJLPMS1bQ6KH5mIePM cO5w==
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=tNPxsPSZpGEfAaV1jQv1EGLoGwV8X4xXgTu60c4ZmOs=; b=CZiwk1SsXS+x8qY6PKhnqzbS2VAPEfbOyUWiTFGjs/9k8UamWJri5KnxNG1nf/PQzQ b27lq5OWjiLnuzyxFQeFYRKO06WT/dnVv3rmloTGHkCTuGkETM+IPSSeSMY1ERE7e5Lg sxGgBJDO76wK0MGMJMUp8Xj1Rq92FrzOplnHa7cmdL1Wc56BKRH7pKRSV9aPAPjBoawt WiziWFZn3gu0yIWeJQPNp4d89Am5s8ArgW8sU53d6Ma7laUJkWwpuYhRNJ/3zTaSqjt+ sILQoZPLl399hzhSIk2LaXpNSENN+/GTsMXTDFa+viLt2cmkb1wQKP2Jf2dM4BNWlFKQ 9ZDA==
X-Gm-Message-State: AOAM532N06QJxOQ4Rmz5qXVWVNXKbqqDkj5vVFYmeUlebbr4Tde/WE2a PvlQH1ilXJ9Xw4i4iJ8Ub7g3yPCTusG3KC4KYR4=
X-Google-Smtp-Source: ABdhPJxPi62EaJw/Lln91wYX+MDKbVy71NKvSZ6pgtFcJa8dK8zie8EHdt3vn45ZqWLYlSImXdKZnCMaY3vm4F2fYGU=
X-Received: by 2002:a92:b684:: with SMTP id m4mr56026074ill.153.1594484557106; Sat, 11 Jul 2020 09:22:37 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR13MB31178756BB6166B2F1807CF6F2980@MN2PR13MB3117.namprd13.prod.outlook.com> <CAF18ct4VtDckw4971SG5qeLT-Qj-o9RCRkDCA=iK7+bj8zOdyw@mail.gmail.com>
In-Reply-To: <CAF18ct4VtDckw4971SG5qeLT-Qj-o9RCRkDCA=iK7+bj8zOdyw@mail.gmail.com>
From: Anil Kumar <anil.ietf@gmail.com>
Date: Sat, 11 Jul 2020 21:52:25 +0530
Message-ID: <CAC38=VFcy=J=zOpEBThJ6-6ot-6F-PSL7MSDFfDfEpAEtKRy4A@mail.gmail.com>
To: Uma Chunduri <umac.ietf@gmail.com>
Cc: Huaimo Chen <huaimo.chen@futurewei.com>, "lsr@ietf.org" <lsr@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a0526b05aa2cdd35"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/1pwifyqy8aT-DL2c8TjA57Bjcsw>
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 16:22:44 -0000

 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
>