Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

2020-08-18 Thread Liu Vic
Support as co-author.

Thanks,
Liu

Les Ginsberg (ginsberg)  于2020年8月18日周二
下午3:52写道:

> Huaimo –
>
>
>
> The question I and others have asked is “what can we do with zones that
> cannot be done with areas?”.
>
>
>
> From the day several years ago when IS-IS TTZ was first presented,  your
> answer has been “with zones you can hitlessly alter the topological
> boundaries”.
>
> My response has consistently been “we can already do that with areas”.
>
>
> If you want to justify zones, you then need to provide some other use case
> that either cannot be done using areas or cannot be done hitlessly.
>
> Continuing to focus on something that can already be done with areas isn’t
> helping you.
>
>
>
>Les
>
>
>
>
>
> *From:* Huaimo Chen 
> *Sent:* Tuesday, August 18, 2020 3:18 PM
> *To:* Les Ginsberg (ginsberg) ; Les Ginsberg
> (ginsberg) ; Acee Lindem (acee)
> ; lsr@ietf.org
> *Subject:* Re: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone"
> - draft-chen-isis-ttz-11.txt
>
>
>
> Hi Les,
>
>
>
> > It is possible to merge/split areas without adjacency flaps.
>
> [HC]: While an existing area or zone is being abstracted as a single
> node or vice versa, there are the adjacency ups and downs. The areas
> merging/splitting without adjacency flaps has been done before this
> abstraction and will not reduce the service interruption during the
> abstraction.
>
>
>
> Best Regards,
>
> Huaimo
> --
>
> *From:* Les Ginsberg (ginsberg) 
> *Sent:* Tuesday, August 18, 2020 5:59 PM
> *To:* Huaimo Chen ; Les Ginsberg (ginsberg) <
> ginsberg=40cisco@dmarc.ietf..org >;
> Acee Lindem (acee) ; lsr@ietf.org <
> lsr@ietf.org>
> *Subject:* RE: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone"
> - draft-chen-isis-ttz-11.txt
>
>
>
> Huaimo –
>
>
>
> It is possible to merge/split areas without adjacency flaps.
>
> The technique has been known for many years.
>
> It requires careful planning – but it is quite feasible and has been done.
>
>
>
> You cannot justify the need for zones on this basis..
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of *Huaimo Chen
> *Sent:* Tuesday, August 18, 2020 2:33 PM
> *To:* Les Ginsberg (ginsberg)  >; Acee Lindem (acee) <
> acee=40cisco@dmarc.ietf.org>; lsr@ietf.org
> *Subject:* Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent
> Zone" - draft-chen-isis-ttz-11.txt
>
>
>
> Hi Les,
>
>
>
> > I see no need for “abstraction at arbitrary boundaries”.. Areas work just
> fine.
>
> > IS-IS already has smooth transition capability for merging/splitting
> areas...
>
>
>
> [HC]: The smooth transition capability for merging/splitting areas in
> IS-IS will not reduce the service interruption while an existing area or
> zone is being abstracted as a single node because the adjacency ups and
> downs.
>
>
>
> > Given both of the points above, I see no value in “smooth transition
> to/from zone abstraction”.
>
>
>
> [HC]:  The "smooth transition to/from zone abstraction" will reduce the
> service interruption while an existing area or zone is being abstracted as
> a single node and vice versa.
>
>
>
> Best Regards,
>
> Huaimo
> --
>
> *From:* Lsr  on behalf of Les Ginsberg (ginsberg) <
> ginsberg=40cisco@dmarc.ietf.org>
> *Sent:* Tuesday, August 18, 2020 5:06 PM
> *To:* Acee Lindem (acee) ; lsr@ietf.org <
> lsr@ietf.org>
> *Subject:* Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent
> Zone" - draft-chen-isis-ttz-11.txt
>
>
>
> I see no need for “abstraction at arbitrary boundaries”. Areas work just
> fine.
>
>
>
> IS-IS already has smooth transition capability for merging/splitting areas.
>
>
>
> Given both of the points above, I see no value in “smooth transition
> to/from zone abstraction”.
>
>
>
> If these are the principal distinguishing characteristics of TTZ as
> compared to area proxy (and I would agree they are), then I see no reason
> why this solution should be pursued as well.
>
>
>
> I am therefore opposed to WG adoption of TTZ.
>
>
>
>Les
>
>
>
>
>
>
>
> *From:* Lsr  *On Behalf Of *Acee Lindem (acee)
> *Sent:* Tuesday, August 18, 2020 7:17 AM
> *To:* lsr@ietf.org
> *Subject:* [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent
> Zone" - draft-chen-isis-ttz-11.txt
>
>
>
>
>
> Based on the discussions in the last meeting and on the mailing list
> regarding draft-chen-isis-ttz-11, the chairs feel that there are enough
> differences with draft-ietf-lsr-isis-area-proxy-03 and in the community to
> consider advancing it independently on the experimental track.
>
>
>
> These differences include abstraction at arbitrary boundaries and IS-IS
> extensions for smooth transition to/from zone abstraction.
>
>
>
> We are now starting an LSR WG adoption call for
> draft-chen-isis-ttz-11.txt. Please indicate your support or objection to
> adoption prior to Tuesday, September 2nd, 2020.
>
>
>
> Thanks,
>
> Acee and Chris
>
>
> ___
> Lsr mailing list

Re: [Lsr] Request WG adoption of TTZ

2020-07-11 Thread Liu Vic
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  于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  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 
>> 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