Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen <[e-mail]>]

I support the adoption of IS-IS TTZ draft.
1).  It seems that Area Proxy can not be amended to IS-IS TTZ. IS-IS TTZ abstracts a zone to a single node. This abstraction is supported by the extensions to IS-IS, and some of these extensions are not defined in Area Proxy. For example, the extensions for the edge nodes of the zone are not defined in Area Proxy.
2). IS-IS TTZ abstracts a zone to a single node. A zone is any target block or piece of an IS-IS area, which is to be abstracted. This seems more flexible and convenient to users.
3). IS-IS TTZ provides smooth transferring between a zone and its single virtual node. That is that a zone can be smoothly transferred to a single virtual node, and the virtual node can be smoothly rolled back to the zone. This should improve customer experience since converting any block of an area to a single node is smooth with minimum or no service interruption.
4). Using IS-IS TTZ for network scalability may reduce the users' workload or make their work easier. They may put less efforts on planning a zone to be abstracted to a node. After the zone is abstracted to a node, the node can be rolled back to the zone smoothly if they want to redefine the zone.

BTW, RFC 8099 (OSPF TTZ) is for abstracting a zone of an OSPF area to its edges full mesh. IS-IS TTZ is much better than RFC 8099 regarding to improving network scalability since IS-IS TTZ focuses on abstracting a zone to a single node.

Best Regards,
Huaimo
________________________________
From: Kiran Makhijani <[e-mail]>
Sent: Monday, July 13, 2020 3:36 PM
To: Yanhe Fan <[e-mail]>; Donald Eastlake <[e-mail]>; Huaimo Chen <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: RE: [Lsr] Request WG adoption of TTZ

I support IS-IS TTZ adoption for its value in reducing LSDB through abstraction.
-Kiran

-----Original Message-----
From: Lsr <[e-mail]> On Behalf Of Yanhe Fan
Sent: Sunday, July 12, 2020 7:33 AM
To: Donald Eastlake <[e-mail]>; Huaimo Chen <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Lsr] Request WG adoption of TTZ

I support adaption of this IS-IS TTZ draft. It is a useful work to address network scalability.

Thanks,
Yanhe

-----Original Message-----
From: Lsr <[e-mail]> On Behalf Of Donald Eastlake
Sent: Friday, July 10, 2020 1:08 PM
To: Huaimo Chen <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Lsr] Request WG adoption of TTZ

I support adoption of the IS-IS TTZ draft.

It seems more flexible and capable although some editorial/nomenclature improvements in the draft would be good. I will send some more detailed suggestions to the authors.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA  [e-mail]

On Thu, Jun 18, 2020 at 11:38 PM Huaimo Chen <[e-mail]> wrote:
>
> Hi Chris and Acee, and everyone,
>
>
>
>     I would like to request working group adoption of "Topology-Transparent Zone"
>
> (TTZ for short) https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2F&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce6b542df05de428ba29a08d82764136c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637302658065143399&amp;sdata=A4bYj%2B6ViMLIBApX1qQj93306nRIyL4aKs5QR0t%2B%2FJg%3D&amp;reserved=0 .
>
>
>     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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-li-lsr-isis-area-proxy-03&amp;data=02%7C01%7
> Ckiranm%40futurewei.com%7C72917e53d6d94074876208d826709d01%7C0fee8ff2a
> 3b240189c753a1d5591fedc%7C1%7C0%7C637301612416445576&amp;sdata=E95AXx%
> 2Bq4Xul3auIUt%2FUI203nvzgDODJDOs8l1Dlk9o%3D&amp;reserved=0
>
> abstracts an existing IS-IS L1 area to a single pseudo node.
>
>
>
>     "Flood Reflection"
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-przygienda-lsr-flood-reflection-01&amp;data=
> 02%7C01%7Ckiranm%40futurewei.com%7C72917e53d6d94074876208d826709d01%7C
> 0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637301612416445576&amp;sdat
> a=iNunk3YCV%2FiXEEYNYxozwgRlavMPB%2B%2FF1k6K6CCcWkA%3D&amp;reserved=0
>
> 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
> [e-mail]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Ckiranm%40future
> wei.com%7C72917e53d6d94074876208d826709d01%7C0fee8ff2a3b240189c753a1d5
> 591fedc%7C1%7C0%7C637301612416445576&amp;sdata=P9I3KSsJb84wDSs6kaVrI%2
> B5bfPRF2MNt1JyTvJea6wc%3D&amp;reserved=0

_______________________________________________
Lsr mailing list
[e-mail]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce6b542df05de428ba29a08d82764136c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637302658065143399&amp;sdata=KwLx8g2O6zpPJPCqDRytf5XfZVoBu%2FZSMPP7Tw9kkLw%3D&amp;reserved=0
_______________________________________________
Lsr mailing list
[e-mail]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce6b542df05de428ba29a08d82764136c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637302658065143399&amp;sdata=KwLx8g2O6zpPJPCqDRytf5XfZVoBu%2FZSMPP7Tw9kkLw%3D&amp;reserved=0