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.i...@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.i...@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.c...@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
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to