Subject: Re: [Lsr] Request WG adoption of TTZ

From: Huaimo Chen <[email-masked]>
Date: Tue, 7 Jul 2020 16:00:04 +0000

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-masked]; [email-masked]
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-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 7 Jul 2020 16:52:17 +0000

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-masked]> On Behalf Of Huaimo Chen
Sent: Tuesday, July 07, 2020 9:00 AM
To: Christian Hopps <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Chris,

Best Regards,
Huaimo
________________________________
From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo,

Thanks,
Chris.
[chair hat]

> On Jun 18, 2020, at 11:38 PM, Huaimo Chen <[email-masked]<mailto:[email-masked]>> wrote:
>
> A zone (block of an OSPF area) is smoothly transferred to its edges' full mess
>
> [email-masked]<mailto:[email-masked]>

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 7 Jul 2020 18:12:57 +0000

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-masked]>
Sent: Tuesday, July 7, 2020 12:52 PM
To: Huaimo Chen <[email-masked]>; Christian Hopps <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [Lsr] Request WG adoption of TTZ

Huaimo –

Thanx.

    Les

Hi Chris,

Best Regards,

Huaimo

From: Christian Hopps

Hi Huaimo,

Thanks,
Chris.
[chair hat]

> (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%7C8e8d79082cbc45a0f69208d822961d50%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297375431224246&sdata=M4TDFFc3f%2FTDkcdbdcxb%2Bswf2Nbvw%2FXyTKcM97r4MGA%3D&reserved=0> .
>
>
>
>     "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%7C8e8d79082cbc45a0f69208d822961d50%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297375431224246&sdata=K7PWcMA%2B0TFBwZAO%2FfNfLwH97noCZnmryOdmY94X2Qs%3D&reserved=0>
>
>     "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%7C8e8d79082cbc45a0f69208d822961d50%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297375431234244&sdata=bnlpaGheZMu9%2Fw1yQB3wqmrjvuPb1hQ7rCA%2F5fIR6H0%3D&reserved=0>
>
> 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%7C8e8d79082cbc45a0f69208d822961d50%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297375431234244&sdata=u5dmCsQ1wMUtmxM3tVLXsbzC6bKwXDlgLcb%2BfEaNIcE%3D&reserved=0>

---

From: Christian Hopps <[email-masked]>
Date: Tue, 7 Jul 2020 14:50:13 -0400

> On Jul 7, 2020, at 12:00 PM, Huaimo Chen <[email-masked]> wrote:
> 
> Hi Chris,
> 

[As wg member]

If the operator needed a subset of an area abstracted they could split the area and then use area proxy on the subset though, right? Restricting things to exactly the area boundary as area proxy does seems like an elegant KISS approach; it has the advantage of harnessing all the existing tools and institutional knowledge on how IS-IS areas work. This in turn simplifies management and debugability I think. While TTZ adds some extra flexibility (cuts out the area split step) I don't know that the added complexity makes sense since splitting an area is basically the same operation as configuring a zone would be.

> 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 ro…

This strikes me as the important difference from area proxy. It certainly adds complexity to things, I wonder if it's worth it?

Thanks,
Chris.
[As WG member]

---

From: [email-masked]
Date: Tue, 7 Jul 2020 12:08:47 -0700

> This strikes me as the important difference from area proxy. It certainly adds complexity to things, I wonder if it's worth it?

FWIW, we looked at this quite seriously a while ago. Turning abstraction on and off is simply not a daily occurrence. Doing it properly requires careful thought and planning. 
Where are the boundaries? What prefixes will be advertised and with what metrics? How will the affect traffic flow?

The corner cases that happen when you are in this transition are large. We have to deal with the issue of the metrics that are abstracted away.  We chose to go down the path
of intra-area vs. inter-area metrics, exactly as OSPF does. But if you do this, then you have an issue: the metrics are different when abstraction is enabled or disabled and 
different nodes will compute different paths depending on which LSPs have propagated to them. This seemed like a wonderful opportunity for forwarding loops. This
is especially problematic when abstraction is enabled, as there is now an entire area’s worth of LSPs that need to age out before you can be assured of consistency.
Yes, you can try to purge them, but purges aren’t the most reliable thing in the world.  

Net net, we felt that the complexity exceeded the benefit. Yes, there is benefit there, but from the pragmatic viewpoint of making it work in production, the risks and costs seemed very high. 
We expect that operators would want to make the change in a maintenance window anyway, and as long as you’re having a maintenance window, you might as well do things the
simpler way.

Regards,
Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 7 Jul 2020 19:29:22 +0000

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-masked]>
Sent: Tuesday, July 07, 2020 11:13 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; Christian Hopps <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Les,

Best Regards,
Huaimo
________________________________
From: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, July 7, 2020 12:52 PM
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] Request WG adoption of TTZ

Huaimo -

Thanx.

    Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Huaimo Chen
Sent: Tuesday, July 07, 2020 9:00 AM
To: Christian Hopps <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Chris,

Best Regards,

Huaimo

From: Christian Hopps

Hi Huaimo,

Thanks,
Chris.
[chair hat]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 7 Jul 2020 19:41:58 +0000

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 <[email-masked]> on behalf of Huaimo Chen <[email-masked]>
Date: Tuesday, July 7, 2020 at 12:01 PM
To: Christian Hopps <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Chris,

Best Regards,
Huaimo

Hi Huaimo,

Thanks,
Chris.
[chair hat]

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 7 Jul 2020 19:42:27 +0000

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
Sent: Tuesday, July 7, 2020 3:29 PM

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.

   Les

Hi Les,

Best Regards,

Huaimo

Huaimo –

Thanx.

    Les

Hi Chris,

Best Regards,

Huaimo

From: Christian Hopps

Hi Huaimo,

Thanks,
Chris.
[chair hat]

> (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> .
>
>
>
>     "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>
>
>     "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>
>
> 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>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 7 Jul 2020 20:33:06 +0000

Speaking as WG member:

Hi Huaimo,

Independent of the major issue with Area Proxy differentiation, I have a couple other issues that I didn’t want to include in the same Email thread.

  1.  You can’t describe IS-IS protocol details and then just include OSPF encodings and expect the readers to intuit the OSPF specific details. These area abstraction drafts modify basic protocol mechanisms and OSPF details would be better specified in an update to RFC 8099 then just adding encodings to this IS-IS TTZ draft.
  2.  The draft uses the term IS-IS Pseudo-node yet this is defined in IS-IS as a specific LSP to represent a multi-access network. I don’t know if the usage of the terminology was meant to differentiate the mechanisms from Area Proxy but I find the repurposing of the term pseudo-node in the context of IS-IS very confusing.
  3.  The document keeps referring to  “edges full mess” and I believe you mean “edges full mesh”.

Thanks,
Acee

Hi Chris,

Best Regards,
Huaimo

Hi Huaimo,

Thanks,
Chris.
[chair hat]

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 8 Jul 2020 00:42:30 +0000

Hi Acee and Chris,

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) <[email-masked]>
Sent: Tuesday, July 7, 2020 3:41 PM
To: Huaimo Chen <[email-masked]>; Christian Hopps <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Lsr] Request WG adoption of TTZ

Speaking as WG member:

Thanks,
Acee

Hi Chris,

Best Regards,

Huaimo

From: Christian Hopps

Hi Huaimo,

Thanks,
Chris.
[chair hat]

> (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> .
>
>
>
>     "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>
>
>     "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>
>
> 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>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 8 Jul 2020 00:52:34 +0000

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

Sent: Tuesday, July 07, 2020 12:42 PM

Hi Les,

Best Regards,
Huaimo

Huaimo -

   Les

From: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, July 07, 2020 11:13 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Les,

Best Regards,

Huaimo

Huaimo -

Thanx.

    Les

Hi Chris,

Best Regards,

Huaimo

From: Christian Hopps

Hi Huaimo,

Thanks,
Chris.
[chair hat]

---

From: Tony Li <[email-masked]>
Date: Tue, 7 Jul 2020 18:11:34 -0700

Hi Huaimo,

>     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:

That’s an unfortunate assumption.  We have not defined OSPF Area Proxy because it’s frankly well outside of our expertise.

The hierarchical structures of OSPF and IS-IS are intrinsically different.  While legacy IS-IS allows L2 traffic to transit an L1L2 area, my understanding is that when OSPF traffic leaves Area 0, it won’t be coming 
back.  While I don’t particularly like this aspect of the OSPF architecture, it’s NOT what we were out to fix.  

So, please don’t assume anything about OSPF Area Proxy.  

Tony

---

From: Christian Hopps <[email-masked]>
Date: Tue, 7 Jul 2020 21:21:25 -0400

> On Jul 7, 2020, at 8:42 PM, Huaimo Chen <[email-masked]> wrote:
> 
> Hi Acee and Chris,
> 
>     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..

I think the fact that the above is mixing terms (e.g., OSPF Area Proxy, which doesn't exist, and OSPF doesn't have pseudo-nodes) is really highlighting the fact that, as Acee pointed out, perhaps its not a good idea to be trying to update/modify OSPF TTZ (RFC8099), and at the same time introduce something new to IS-IS. It's very confusing right now to have these things all mixed together like this.

Thanks,
Chris.
[As WG member]

> 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.

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 8 Jul 2020 01:30:25 +0000

Hi Tony and Chris,

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.
This strikes me as the important difference from area proxy. It certainly adds complexity to things, I wonder if it's worth it?
    It is worth it because it reduces service interruption and improves customer experiences.

    When users plan to do these operations on a network, they will select a maintenance window. During this window, there should be minimum service traffic being transported in the network. However, there is still some live traffic in the network even during this window in general. If we do not provide smooth transferring between a zone/area and its single pseudo node, some live traffic will be lost even during this window while doing the transferring.

    There are some challenges for providing smooth transferring between a zone and its single pseudo node. I believe that we will be able to have a good enough solution. We have had a prototype implementation of smooth transferring a zone to the zone edges' full mess in OSPF. The testing shows that a zone (block of an OSPF area) is smoothly transferred to its edges’ full mess without any routing disruptions.  In addition, we have spent lots of time and efforts on smooth transferring between a zone and its single pseudo node. Moreover, we may get suggestions from the experts in IETF, especially in LSR WG.

Best Regards,
Huaimo

________________________________
From: Tony Li <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Tuesday, July 7, 2020 3:08 PM
To: Christian Hopps <[email-masked]>
Cc: Huaimo Chen <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Lsr] Request WG adoption of TTZ

Regards,
Tony

---

From: Aijun Wang <[email-masked]>
Date: Wed, 8 Jul 2020 10:36:09 +0800

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=[email-masked]> 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.
> Just my opinion of course…
>  
>    Les
>  
>  
> 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: [email-masked]
Date: Tue, 7 Jul 2020 19:58:55 -0700

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-masked]> wrote:
> 
> Hi, Les:
> 
>> 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).
>>  
>> From: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>>
>> To: Huaimo Chen <[email-masked] <mailto:[email-masked]>>; Christian Hopps <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
>> From: Huaimo Chen <[email-masked] <mailto:[email-masked]>> 
>> To: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>>; Christian Hopps <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> From: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]>>
>> To: Huaimo Chen <[email-masked] <mailto:[email-masked]>>; Christian Hopps <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
>> From: Lsr <[email-masked] <mailto:[email-masked]>> On Behalf Of Huaimo Chen
>> To: Christian Hopps <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> Cc: Christian Hopps; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> [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-masked] <mailto:[email-masked]>> wrote:
>> > 
>> > (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> .
>> > 
>> > 
>> > 
>> >     "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>
>> > 
>> >     "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>
>> > 
>> > [email-masked] <mailto:[email-masked]>
>> > 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-masked]
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 8 Jul 2020 03:21:52 +0000

Hi Acee,

Best Regards,
Huaimo
Sent: Tuesday, July 7, 2020 4:33 PM

Speaking as WG member:

Hi Huaimo,

  1.  You can’t describe IS-IS protocol details and then just include OSPF encodings and expect the readers to intuit the OSPF specific details. These area abstraction drafts modify basic protocol mechanisms and OSPF details would be better specified in an update to RFC 8099 then just adding encodings to this IS-IS TTZ draft.
[HC]: We will add more OSPF details. I am OK for OSPF details to be in an update to RFC 8099.
  2.  The draft uses the term IS-IS Pseudo-node yet this is defined in IS-IS as a specific LSP to represent a multi-access network. I don’t know if the usage of the terminology was meant to differentiate the mechanisms from Area Proxy but I find the repurposing of the term pseudo-node in the context of IS-IS very confusing.
[HC]: We will change it to another term.
  3.  The document keeps referring to  “edges full mess” and I believe you mean “edges full mesh”.

[HC]: You are right. It should be "edges full mesh".

Thanks,

Acee

Hi Chris,

Best Regards,

Huaimo

From: Christian Hopps

Hi Huaimo,

Thanks,
Chris.
[chair hat]

> (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%7Cf45a97241f914267c48108d822b4f739%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297507948268879&sdata=cT2JJyInfxUrxH7NSUnPu%2FSk%2Fn4orjZfQhKSA7qxktY%3D&reserved=0> .
>
>
>
>     "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%7Cf45a97241f914267c48108d822b4f739%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297507948278872&sdata=BH8KPTuyl2mpFJzvsUgbm%2FAkFu%2BqfmApP6q4K1OOf%2Bg%3D&reserved=0>
>
>     "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%7Cf45a97241f914267c48108d822b4f739%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297507948278872&sdata=gkWPibMEKIdfWpEEVc0TrfVxXEk%2BMWYNAKDPQGoeA20%3D&reserved=0>
>
> 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%7Cf45a97241f914267c48108d822b4f739%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297507948288865&sdata=XgCoWRmuGeDtW942zpInToTYrh%2BOh8NEcQMa4aObocA%3D&reserved=0>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 8 Jul 2020 13:34:36 +0000

Huaimo,
The LSR WG has been discussing IS-IS Area Abstraction in the context of flooding overhead in DC topologies for over a year now. Why are you are trying to hijack this discussion in favor of OSPF Area Abstraction??? The fact that your draft includes some OSPF encodings is NOT a differentiating feature in the context of this discussion. In fact, both Chris and I have asked that you remove the OSPF encodings from your IS-IS TTZ draft. Furthermore, if you want to respin RFC 8099 applying the IS-IS Area proxy mechanisms to OSPF, that is a totally separate discussion.
Thanks,
Acee

From: Huaimo Chen <[email-masked]>
Date: Tuesday, July 7, 2020 at 8:42 PM
To: Acee Lindem <[email-masked]>, Christian Hopps <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Acee and Chris,

Thanks,

Acee

Best Regards,
Huaimo

Speaking as WG member:

Thanks,
Acee

Hi Chris,

Best Regards,

Huaimo

From: Christian Hopps

Hi Huaimo,

Thanks,
Chris.
[chair hat]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 8 Jul 2020 13:37:55 +0000

On PTO so will be brief… Inline

Date: Tuesday, July 7, 2020 at 11:22 PM

Hi Acee,

Best Regards,
Huaimo

Speaking as WG member:

Hi Huaimo,

Just not in the IS-IS TTZ draft. OSPF and IS-IS have different protocol mechanisms and completely different terminology.

Thanks,

Acee

Thanks,

Acee

Hi Chris,

Best Regards,

Huaimo

From: Christian Hopps

Hi Huaimo,

Thanks,
Chris.
[chair hat]

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 8 Jul 2020 20:01:34 +0000

Hi Acee,

    Thank you very much for your suggestion.
    I have removed the OSPF details from the draft.

Best Regards,
Huaimo
Sent: Wednesday, July 8, 2020 9:37 AM

Hi Acee,

Best Regards,

Huaimo

Speaking as WG member:

Hi Huaimo,

Thanks,

Acee

Thanks,

Acee

Hi Chris,

Best Regards,

Huaimo

From: Christian Hopps

Hi Huaimo,

Thanks,
Chris.
[chair hat]

> (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%7C45dcdad875904effab5908d82344214f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637298122822196437&sdata=3gbIJFXC10uCM9gB5XLqW8ounDkcq7r9nEZSJQVHsA0%3D&reserved=0> .
>
>
>
>     "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%7C45dcdad875904effab5908d82344214f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637298122822206391&sdata=V5gkN1cKG1B7Vsm5cZpp%2FdSiKqSDeKpf9sMpQZ55GFA%3D&reserved=0>
>
>     "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%7C45dcdad875904effab5908d82344214f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637298122822206391&sdata=SNcvynn%2FbfJLLKjdphMCNJbLSAZioXgLfGiH5%2BZIE18%3D&reserved=0>
>
> 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%7C45dcdad875904effab5908d82344214f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637298122822216356&sdata=go1dGZ2WXSOFlyxnMd%2FW6Db3JwXf87YtycgHsaMfD%2BA%3D&reserved=0>