Re: [Lsr] Request WG adoption of TTZ

[Uma Chunduri <[e-mail]>]

 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 <[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://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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>