Hi Aijun, Subdividing an existing area is entirely possible with Area Proxy. You just have to split the area and then apply Area Proxy. ;-)
Tony > On Jul 7, 2020, at 7:36 PM, Aijun Wang <[email protected]> wrote: > > 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) >> <[email protected]> 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 <[email protected]> >> Sent: Tuesday, July 07, 2020 12:42 PM >> To: Les Ginsberg (ginsberg) <[email protected]>; Christian Hopps >> <[email protected]> >> Cc: [email protected]; [email protected] >> 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) <[email protected] >> <mailto:[email protected]>> >> Sent: Tuesday, July 7, 2020 3:29 PM >> To: Huaimo Chen <[email protected] >> <mailto:[email protected]>>; Christian Hopps <[email protected] >> <mailto:[email protected]>> >> Cc: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>>; >> [email protected] <mailto:[email protected]> <[email protected] >> <mailto:[email protected]>> >> 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 <[email protected] >> <mailto:[email protected]>> >> Sent: Tuesday, July 07, 2020 11:13 AM >> To: Les Ginsberg (ginsberg) <[email protected] >> <mailto:[email protected]>>; Christian Hopps <[email protected] >> <mailto:[email protected]>> >> Cc: [email protected] <mailto:[email protected]>; [email protected] >> <mailto:[email protected]> >> 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) <[email protected] >> <mailto:[email protected]>> >> Sent: Tuesday, July 7, 2020 12:52 PM >> To: Huaimo Chen <[email protected] >> <mailto:[email protected]>>; Christian Hopps <[email protected] >> <mailto:[email protected]>> >> Cc: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>>; >> [email protected] <mailto:[email protected]> <[email protected] >> <mailto:[email protected]>> >> 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 <[email protected] <mailto:[email protected]>> On Behalf Of >> Huaimo Chen >> Sent: Tuesday, July 07, 2020 9:00 AM >> To: Christian Hopps <[email protected] <mailto:[email protected]>> >> Cc: [email protected] <mailto:[email protected]>; [email protected] >> <mailto:[email protected]> >> 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; [email protected] <mailto:[email protected]>; [email protected] >> <mailto:[email protected]> >> 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 <[email protected] >> > <mailto:[email protected]>> 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/ >> > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C75f4f5312fa844cf550f08d822ac104f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297469707064779&sdata=xTQTyugiZZo33ux%2FR2BJj3DnndDA91WoDhDxVNe98o0%3D&reserved=0> >> > . >> > >> > >> > >> > 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 >> > <https://nam11.safelinks..protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-lsr-isis-area-proxy-03&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C75f4f5312fa844cf550f08d822ac104f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297469707069758&sdata=piaGNu9T7aRbFxztE%2FrOgZfBDW9vHoG47rSCu82chIw%3D&reserved=0> >> > >> > 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 >> > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools..ietf.org%2Fhtml%2Fdraft-przygienda-lsr-flood-reflection-01&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C75f4f5312fa844cf550f08d822ac104f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297469707074736&sdata=MNnJKqu6gx3eKvBHwLjO7dfPct9Xk2Lssx0CqNbp2j8%3D&reserved=0> >> > >> > 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 >> > [email protected] <mailto:[email protected]> >> > https://www.ietf.org/mailman/listinfo/lsr >> > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C75f4f5312fa844cf550f08d822ac104f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297469707079716&sdata=JtIdEQt1Q%2FyGcytjVBy0ZVmHN4LY6JHpdXmz9k5yzc4%3D&reserved=0>_______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/lsr > <https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
