Re: [Lsr] Request WG adoption of TTZ

[Christian Hopps <[e-mail]>]

Hi Huaimo,

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

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?

Thanks,
Chris.
[chair hat]


> On 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://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