Re: [Lsr] Request WG adoption of TTZ

Hi, Les:

Using TTZ to sub divide the existing area seems more attractive. It seems TTZ can accomplish all the functions Area Proxy can provide, but area proxy can’t cover the scenarios that TTZ can solve.
Why don’t we prefer to TTZ?

Aijun Wang
China Telecom

> On Jul 8, 2020, at 08:53, Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org> wrote:
> 
> 
> Huaimo –
>  
> Sorry for ascribing area merging properties to zones.. As the base protocol mechanism in IS-IS can be used both to split and merge areas I was thinking zones could be used the same way, but I see on closer reading that you have restricted a zone to be a subset of an area (which could also be the area itself).
>  
> I think this does not detract from the main point I am trying to make – which is that unless there is reason to believe that operators would prefer to use zones rather than split an area (when necessary), this does not serve as a significant differentiator between TTZ and area-proxy.
> I think you need a more compelling differentiator to justify proceeding with both drafts.
>  
> In this regard I am agreeing with the points made by other folks (notably Chris and Tony), that the introduction of zones may well be adding unneeded complexity.
>  
> Just my opinion of course…
>  
>    Les
>  
>  
> From: Huaimo Chen <huaimo.chen@futurewei.com> 
> Sent: Tuesday, July 07, 2020 12:42 PM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Christian Hopps <chopps@chopps.org>
> Cc: lsr@ietf.org; lsr-chairs@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
>  
> Hi Les,
>  
> > I think what you are highlighting is that w TTZ an operator could apply the solution to a subset of an area (which you call a zone) – or to a set of areas (which you also call a zone). This presumes that it is expected that a customer would want to operate in a mode where the interconnections do not follow area boundaries. It isn’t clear to me that this is a compelling requirement. If there are operators who feel otherwise I would appreciate them speaking up and educating us on the requirements.
>  
> How do you get that TTZ could be used to a set of areas (which you also call a zone)? 
> A zone is a piece or block of an area.  In an area, we can define one or more zones. All these zones are within this area. For a set of areas, we can define one or more zones in each of these areas.. But we can not define a zone crossing multiple areas.
>  
> Best Regards,
> Huaimo
> From: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> Sent: Tuesday, July 7, 2020 3:29 PM
> To: Huaimo Chen <huaimo.chen@futurewei.com>; Christian Hopps <chopps@chopps.org>
> Cc: lsr@ietf.org <lsr@ietf.org>; lsr-chairs@ietf.org <lsr-chairs@ietf.org>
> Subject: RE: [Lsr] Request WG adoption of TTZ
>  
> Huaimo –
>  
> I think what you are highlighting is that w TTZ an operator could apply the solution to a subset of an area (which you call a zone) – or to a set of areas (which you also call a zone). This presumes that it is expected that a customer would want to operate in a mode where the interconnections do not follow area boundaries. It isn’t clear to me that this is a compelling requirement. If there are operators who feel otherwise I would appreciate them speaking up and educating us on the requirements.
>  
> Absent that, it seems if you want to differentiate TTZ from Area-Proxy you should be focusing on things other than the flexibility of zones over areas.
>  
>    Les
>  
>  
> From: Huaimo Chen <huaimo.chen@futurewei.com> 
> Sent: Tuesday, July 07, 2020 11:13 AM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Christian Hopps <chopps@chopps.org>
> Cc: lsr@ietf.org; lsr-chairs@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
>  
> Hi Les,
>  
>     Thank you very much for your comments.
>  
>     There are still some differences between Area Proxy and TTZ regarding to IS-IS with smooth area splitting and merging. 
>  
>     At first, the operations/configurations are different. 
>     Using Area Proxy, two steps are needed. One step is to split an IS-IS area to multiple areas through some configurations. The other step is to abstract an existing IS-IS area to a single pseudo node through another set of configurations. 
>     Using TTZ, only one step is needed, which is to abstract a zone to a single pseudo node.
>     From operations' point of view, TTZ seems simpler.
>  
>     Secondly, TTZ provides smooth transferring between a zone and its single pseudo node. That is that a zone can be smoothly transferred to a single pseudo node, and the pseudo node can be smoothly rolled back to the zone.  
> Smooth IS-IS area splitting and merging can not be used for abstracting an existing IS-IS area to a single pseudo node in Area Proxy. 
>  
> Best Regards,
> Huaimo
> From: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> Sent: Tuesday, July 7, 2020 12:52 PM
> To: Huaimo Chen <huaimo.chen@futurewei.com>; Christian Hopps <chopps@chopps.org>
> Cc: lsr@ietf.org <lsr@ietf.org>; lsr-chairs@ietf.org <lsr-chairs@ietf.org>
> Subject: RE: [Lsr] Request WG adoption of TTZ
>  
> Huaimo –
>  
> In regards to merging/splitting areas, IS-IS base protocol provides a way to do this hitlessly (this was discussed some years ago when IS-IS TTZ draft was first introduced).
> So if the major difference/advantage between area-proxy and ttz is the ability to use zones to handle area merging/splitting this does not add much value in IS-IS.
>  
> Please consider this in your responses.
>  
> Thanx.
>  
>     Les
>  
>  
> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Huaimo Chen
> Sent: Tuesday, July 07, 2020 9:00 AM
> To: Christian Hopps <chopps@chopps.org>
> Cc: lsr@ietf.org; lsr-chairs@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
>  
> Hi Chris,
>  
>     Thank you very much for your questions.
>     My answers/explanations are inline below with prefix [HC].
>  
> Best Regards,
> Huaimo
> From: Christian Hopps
> Sent: Tuesday, July 7, 2020 8:08 AM
> To: Huaimo Chen
> Cc: Christian Hopps; lsr@ietf.org; lsr-chairs@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
>  
> Hi Huaimo,
> 
> Can you speak to the differences of this with Area Proxy? They are similar solutions, right?
>  
> [HC]: There are some differences even though they looks similar. 
> At first, the target to be abstracted in Area Proxy is different from that in TTZ. 
> Area Proxy abstracts an existing area to a single pseudo node. 
> TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an area.
> An area is different from a zone in general.
>  
> Secondly, the ways in which they are applied to an area for scalability are different.
> When an area becomes bigger and bigger, we may have scalability issues. Using TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes smoothly without any interface down. Using Area Proxy, we need split the existing area into multiple areas, and then abstract one or a few areas to one or few pseudo nodes. 
> These differences will produce different user experiences. 
> For splitting an existing area into multiple areas, users may need put more efforts since it causes service interruptions in general. While splitting an area such as an OSPF area into multiple areas, the area numbers configured on some interfaces will be changed and each of these interfaces will be down with its old area number and then up with its new area number. These interface downs and ups will cause service interruptions in general. 
> For defining zones in an area, users may need less efforts since abstracting a zone to a single pseudo node is smooth without any interface down.
>  
> Moreover, TTZ provides smooth transferring between a zone and its single pseudo node. That is that a zone can be smoothly transferred to a single pseudo node, and the pseudo node can be smoothly rolled back to the zone.
>  
> BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a single pseudo node.
> In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, and a zone in an IS-IS area to a single pseudo node.
>  
> 
> 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?
>  
> [HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for abstracting a zone to the zone edges full mess. This document proposes a new solution for abstracting a zone to a single pseudo node. The new solution re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for the new solution are defined in the document.
> 
> Thanks,
> Chris.
> [chair hat]
> 
> 
> > On Jun 18, 2020, at 11:38 PM, Huaimo Chen <huaimo.chen@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