Hi Acee and Chris,
Thank you very much for your comments.
> I agree with Chris – when the IS-IS TTZ draft adopted the approach of having
> the area/zone leader originate a single LSP abstracting the zone/area last
> Oct, the main differentiation between the two approaches is the zone/area
> terminology. The other substantive difference is the fact that the Area Proxy
> draft includes a much more comprehensive specification of the protocol
> mechanisms required for area/zone abstraction. I have no doubt that the Area
> Proxy details could also be amended from area proxy to TTZ, but that is
> exactly Chris’s point with which I agree – there essentially isn’t a
> difference.
Thanks,
Acee
There are really some differences between TTZ and Area Proxy, which are
listed below for OSPF and IS-IS:
Differences between OSPF TTZ and OSPF Area Proxy (note: assume that OSPF
Area Proxy is similar to IS-IS Area Proxy even though OSPF Area Proxy is not
defined in the Area Proxy draft) include:
1). It seems that OSPF Area Proxy can not be amended to OSPF TTZ. OSPF TTZ
abstracts a zone to a single pseudo node. This abstraction is supported by the
extensions to OSPF, and some of these extensions are not defined in OSPF Area
Proxy. For example, the extensions for the edge nodes of the zone are not
defined in OSPF Area Proxy.
2). OSPF Area Proxy abstracts an existing OSPF area to a single pseudo
node. OSPF TTZ abstracts a zone to a single pseudo node. A zone is a piece or
block of an OSPF area. An OSPF area is different from a zone in general.
3). The ways in which they are applied to an OSPF area for scalability are
different. When an OSPF area becomes bigger and bigger, we may have scalability
issues. Using OSPF TTZ, we can abstract one or a few zones in the OSPF area to
one or few pseudo nodes smoothly without any interface down. Using OSPF Area
Proxy, we need split the existing OSPF area into multiple OSPF areas, and then
abstract one or a few OSPF areas to one or few pseudo nodes. Some people may
like the one step operation in OSPF TTZ. Others may like the two step
operations in OSPF Area Proxy.
4). The user experiences are different. For splitting an existing OSPF area
into multiple OSPF areas, users may need put more efforts since it causes
service interruptions in general. While splitting an OSPF area into multiple
OSPF 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 OSPF area, users may need
less efforts since abstracting a zone to a single pseudo node is smooth without
any interface down.
5). OSPF 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.
Differences between IS-IS TTZ and IS-IS Area Proxy are similar to
the above 1). 2). 3). and 5) between OSPF TTZ and OSPF Area Proxy.
Best Regards,
Huaimo
________________________________
From: Acee Lindem (acee) <a...@cisco.com>
Sent: Tuesday, July 7, 2020 3:41 PM
To: Huaimo Chen <huaimo.c...@futurewei.com>; Christian Hopps
<cho...@chopps..org>
Cc: lsr@ietf.org <lsr@ietf.org>; lsr-cha...@ietf.org <lsr-cha...@ietf.org>
Subject: Re: [Lsr] Request WG adoption of TTZ
Speaking as WG member:
I agree with Chris – when the IS-IS TTZ draft adopted the approach of having
the area/zone leader originate a single LSP abstracting the zone/area last Oct,
the main differentiation between the two approaches is the zone/area
terminology. The other substantive difference is the fact that the Area Proxy
draft includes a much more comprehensive specification of the protocol
mechanisms required for area/zone abstraction. I have no doubt that the Area
Proxy details could also be amended from area proxy to TTZ, but that is exactly
Chris’s point with which I agree – there essentially isn’t a difference.
Thanks,
Acee
From: Lsr <lsr-boun...@ietf.org> on behalf of Huaimo Chen
<huaimo.c...@futurewei.com>
Date: Tuesday, July 7, 2020 at 12:01 PM
To: Christian Hopps <cho...@chopps.org>
Cc: "lsr@ietf.org" <lsr@ietf.org>, "lsr-cha...@ietf.org" <lsr-cha...@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-cha...@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.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/<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%7C7779c4b1ed954adaa0d208d822add1e0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297477252127169&sdata=G%2Brszv6ll3oakjBaLDb2gzmjIZIrDG9Blex7Z%2Bef1C0%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%7C7779c4b1ed954adaa0d208d822add1e0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297477252127169&sdata=6951PcBvIPoGgxAszIF93YI69%2FORgE0CpRETu3rwQWQ%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%7C7779c4b1ed954adaa0d208d822add1e0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297477252137162&sdata=EFsagcO6yD%2FWkbvOZUl4GYetH9V2666e5jBpIe9AYZY%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
> Lsr@ietf.org
> 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%7C7779c4b1ed954adaa0d208d822add1e0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297477252147161&sdata=q5XRF%2BzUp2p10IamQiOfi%2BmHwH4GDc6esYmxFJoATXs%3D&reserved=0>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
