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

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

Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar solutions, right?

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?

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: Donald Eastlake <[email-masked]>
Date: Fri, 10 Jul 2020 13:08:13 -0400

I support adoption of the IS-IS TTZ draft.

It seems more flexible and capable although some
editorial/nomenclature improvements in the draft would be good. I will
send some more detailed suggestions to the authors.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: LEI LIU <[email-masked]>
Date: Fri, 10 Jul 2020 10:42:29 -0700

I support the adoption of the TTZ draft.

The operation on TTZ is simple. Smooth transferring between a zone and a
single node will improve customer experience. The work on TTZ should be
moved forward.

Thanks,
Best regards,

Lei

On Thu, Jun 18, 2020 at 8:38 PM Huaimo Chen <[email-masked]>
wrote:

>     "Area Proxy"
> https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03
>
>     "Flood Reflection"
> https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01
>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 10 Jul 2020 20:39:48 +0000

I also support the adoption of TTZ draft.

The Virtual Zone concept would be very useful for the Overlay networks. The proposed TTZ can group a set of nodes not geographically together into one virtual area to scale virtual overlay networks with lots of nodes. Those kind overlay networks are getting more momentum in SDWAN and CDN environment.

Linda Dunbar

From: Lsr <[email-masked]> On Behalf Of LEI LIU
Sent: Friday, July 10, 2020 12:42 PM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] Request WG adoption of TTZ

The operation on TTZ is simple. Smooth transferring between a zone and a single node will improve customer experience. The work on TTZ should be moved forward.

Thanks,
Best regards,

Lei

On Thu, Jun 18, 2020 at 8: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%7Clinda.dunbar%40futurewei.com%7Cf4502b794e7a4b66836408d824f8c059%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299998093803058&sdata=tqunOWC7trBoFu3XBvAFrLDzyFdlLQl9xYMtMdPSMgo%3D&reserved=0> .

non-backbone area).

the transferring.

    "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%7Clinda.dunbar%40futurewei.com%7Cf4502b794e7a4b66836408d824f8c059%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299998093808054&sdata=OxU3ikjVtGtL7piPPc2WJQ8GatTz1XMnoREwVA00%2F2E%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%7Clinda.dunbar%40futurewei.com%7Cf4502b794e7a4b66836408d824f8c059%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299998093818056&sdata=jiSeOvvxabugWULFhFag%2BvVHEbmXBF6mza9cSwbi5t8%3D&reserved=0>

flood reflectors.

Best Regards,

Huaimo
_______________________________________________
Lsr mailing list
[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%7Clinda.dunbar%40futurewei.com%7Cf4502b794e7a4b66836408d824f8c059%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637299998093823049&sdata=mqXl2c5rWwvbP%2BW6iRJCK8%2FtTktq56eKhfB53gF4y38%3D&reserved=0>

---

From: Haoyu Song <[email-masked]>
Date: Fri, 10 Jul 2020 21:03:07 +0000

IS-IS TTZ is useful and I support the adoption of the TTZ draft too.
Thanks!

Haoyu
From: Linda Dunbar <[email-masked]>
Sent: Friday, July 10, 2020 1:40 PM
To: LEI LIU <[email-masked]>; Huaimo Chen <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] Request WG adoption of TTZ

Linda Dunbar

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of LEI LIU
Sent: Friday, July 10, 2020 12:42 PM
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Request WG adoption of TTZ

Thanks,
Best regards,

Lei

non-backbone area).

the transferring.

flood reflectors.

Best Regards,

Huaimo

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 10 Jul 2020 16:07:54 -0700

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.

---

From: Christian Hopps <[email-masked]>
Date: Sat, 11 Jul 2020 07:42:13 -0400

> On Jul 10, 2020, at 4:39 PM, Linda Dunbar <[email-masked]> wrote:
> 

I'm not sure I follow this use-case. The intent of TTZ is to treat a bunch of nodes as a single node (or subset of nodes in early work) to reduce the link-state DB size and flooding requirements, AFAICT.

Thanks,
Chris.
[As WG member]

> On Thu, Jun 18, 2020 at 8:38 PM Huaimo Chen <[email-masked]> wrote:

---

From: Christian Hopps <[email-masked]>
Date: Sat, 11 Jul 2020 07:44:55 -0400

> On Jul 10, 2020, at 7:07 PM, Uma Chunduri <[email-masked]> wrote:
> 
> 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).

Has RFC8099 been deployed by anyone?

I would be very interested in hearing from operators who have experience with TTZ since RFC8099 has been around for over 3 years now.

Thanks,
Chris.
[As WG member]

---

From: Anil Kumar <[email-masked]>
Date: Sat, 11 Jul 2020 21:52:25 +0530

With Regards
Anil S N

---

From: Liu Vic <[email-masked]>
Date: Sat, 11 Jul 2020 10:37:25 -0700

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 <[email-masked]> 于2020年7月11日周六 上午9:22写道：

>> Uma C..

---

From: Yanhe Fan <[email-masked]>
Date: Sun, 12 Jul 2020 14:32:48 +0000

I support adaption of this IS-IS TTZ draft. It is a useful work to address network scalability.

Thanks,
Yanhe

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Donald Eastlake
Sent: Friday, July 10, 2020 1:08 PM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] Request WG adoption of TTZ

It seems more flexible and capable although some editorial/nomenclature improvements in the draft would be good. I will send some more detailed suggestions to the authors.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA  [email-masked]

---

From: Kiran Makhijani <[email-masked]>
Date: Mon, 13 Jul 2020 19:36:44 +0000

I support IS-IS TTZ adoption for its value in reducing LSDB through abstraction.
-Kiran

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Yanhe Fan
Sent: Sunday, July 12, 2020 7:33 AM
To: Donald Eastlake <[email-masked]>; Huaimo Chen <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] Request WG adoption of TTZ

Thanks,
Yanhe

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Donald Eastlake
Sent: Friday, July 10, 2020 1:08 PM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] Request WG adoption of TTZ

Thanks,
Donald

On Thu, Jun 18, 2020 at 11:38 PM Huaimo Chen <[email-masked]> wrote:
> (TTZ for short) https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2F&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C72917e53d6d94074876208d826709d01%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637301612416445576&amp;sdata=yxhI0GPxnBm5t0hosQNld4qq7O4bu3V2p4RExVjMcqE%3D&amp;reserved=0 .
>
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-li-lsr-isis-area-proxy-03&amp;data=02%7C01%7
> Ckiranm%40futurewei.com%7C72917e53d6d94074876208d826709d01%7C0fee8ff2a
> 3b240189c753a1d5591fedc%7C1%7C0%7C637301612416445576&amp;sdata=E95AXx%
> 2Bq4Xul3auIUt%2FUI203nvzgDODJDOs8l1Dlk9o%3D&amp;reserved=0
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-przygienda-lsr-flood-reflection-01&amp;data=
> 02%7C01%7Ckiranm%40futurewei.com%7C72917e53d6d94074876208d826709d01%7C
> 0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637301612416445576&amp;sdat
> a=iNunk3YCV%2FiXEEYNYxozwgRlavMPB%2B%2FF1k6K6CCcWkA%3D&amp;reserved=0
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Ckiranm%40future
> wei.com%7C72917e53d6d94074876208d826709d01%7C0fee8ff2a3b240189c753a1d5
> 591fedc%7C1%7C0%7C637301612416445576&amp;sdata=P9I3KSsJb84wDSs6kaVrI%2
> B5bfPRF2MNt1JyTvJea6wc%3D&amp;reserved=0

_______________________________________________
Lsr mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C72917e53d6d94074876208d826709d01%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637301612416445576&amp;sdata=P9I3KSsJb84wDSs6kaVrI%2B5bfPRF2MNt1JyTvJea6wc%3D&amp;reserved=0
_______________________________________________
Lsr mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C72917e53d6d94074876208d826709d01%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637301612416445576&amp;sdata=P9I3KSsJb84wDSs6kaVrI%2B5bfPRF2MNt1JyTvJea6wc%3D&amp;reserved=0

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 14 Jul 2020 04:09:01 +0000

I support the adoption of IS-IS TTZ draft.
1).  It seems that Area Proxy can not be amended to IS-IS TTZ. IS-IS TTZ abstracts a zone to a single node. This abstraction is supported by the extensions to IS-IS, and some of these extensions are not defined in Area Proxy. For example, the extensions for the edge nodes of the zone are not defined in Area Proxy.
2). IS-IS TTZ abstracts a zone to a single node. A zone is any target block or piece of an IS-IS area, which is to be abstracted. This seems more flexible and convenient to users.
3). IS-IS TTZ provides smooth transferring between a zone and its single virtual node. That is that a zone can be smoothly transferred to a single virtual node, and the virtual node can be smoothly rolled back to the zone. This should improve customer experience since converting any block of an area to a single node is smooth with minimum or no service interruption.
4). Using IS-IS TTZ for network scalability may reduce the users' workload or make their work easier. They may put less efforts on planning a zone to be abstracted to a node. After the zone is abstracted to a node, the node can be rolled back to the zone smoothly if they want to redefine the zone.

BTW, RFC 8099 (OSPF TTZ) is for abstracting a zone of an OSPF area to its edges full mesh. IS-IS TTZ is much better than RFC 8099 regarding to improving network scalability since IS-IS TTZ focuses on abstracting a zone to a single node.

Best Regards,
Huaimo
________________________________
From: Kiran Makhijani <[email-masked]>
Sent: Monday, July 13, 2020 3:36 PM
To: Yanhe Fan <[email-masked]>; Donald Eastlake <[email-masked]>; Huaimo Chen <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [Lsr] Request WG adoption of TTZ

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Yanhe Fan
Sent: Sunday, July 12, 2020 7:33 AM
To: Donald Eastlake <[email-masked]>; Huaimo Chen <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] Request WG adoption of TTZ

Thanks,
Yanhe

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Donald Eastlake
Sent: Friday, July 10, 2020 1:08 PM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] Request WG adoption of TTZ

Thanks,
Donald

On Thu, Jun 18, 2020 at 11:38 PM Huaimo Chen <[email-masked]> wrote:
> (TTZ for short) https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2F&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce6b542df05de428ba29a08d82764136c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637302658065143399&amp;sdata=A4bYj%2B6ViMLIBApX1qQj93306nRIyL4aKs5QR0t%2B%2FJg%3D&amp;reserved=0 .
>
>

_______________________________________________
Lsr mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce6b542df05de428ba29a08d82764136c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637302658065143399&amp;sdata=KwLx8g2O6zpPJPCqDRytf5XfZVoBu%2FZSMPP7Tw9kkLw%3D&amp;reserved=0
_______________________________________________
Lsr mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce6b542df05de428ba29a08d82764136c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637302658065143399&amp;sdata=KwLx8g2O6zpPJPCqDRytf5XfZVoBu%2FZSMPP7Tw9kkLw%3D&amp;reserved=0

---

From: Tony Li <[email-masked]>
Date: Mon, 13 Jul 2020 21:20:38 -0700

Hi Huaimo,

> 1).  It seems that Area Proxy can not be amended to IS-IS TTZ. 

I feel that this is somewhat imprecise.

From my perspective, our attempts to collaborate have been hampered by governmental regulations that are wholly out of our control. The suggestions that I’ve made for continued collaboration within the bounds of those controls have not been well received. Thus, to say that something cannot be done is overstating the case.  We have simply not been wiilling to do so, which is most unfortunate.  Who can say what could happen if we could find a way for all three proposals to collaborate?

Regards,
Tony

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 14 Jul 2020 04:34:15 +0000

Hi Tony，

    The details is underlined above. It says that some of the extensions in IS-IS TTZ are not defined in Area Proxy. It seems accurate if we look at the details.

Best Regards,
Huaimo
________________________________
From: Tony Li <[email-masked]>
Sent: Tuesday, July 14, 2020 12:20 AM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo,

Regards,
Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 13 Jul 2020 21:47:46 -0700

Hi Huaimo,

>     The details is underlined above. It says that some of the extensions in IS-IS TTZ are not defined in Area Proxy. It seems accurate if we look at the details

Apparently, we have very different understandings of the words “amended to”.

And so it goes.

Regards,
Tony

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 14 Jul 2020 16:52:37 +0000

Christian, 

The SDWAN use case  is about grouping a set of nodes in geographically different locations to be one TTZ zone being treated as one Virtual Node. 

Linda

-----Original Message-----
From: Christian Hopps <[email-masked]> 
Sent: Saturday, July 11, 2020 6:42 AM
To: Linda Dunbar <[email-masked]>
Cc: Christian Hopps <[email-masked]>; LEI LIU <[email-masked]>; Huaimo Chen <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] Request WG adoption of TTZ

Thanks,
Chris.
[As WG member]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 14 Jul 2020 16:58:31 +0000

Linda, 

So the IS-IS runs over the overlay in your SDWAN solution? Have you deployed this? __

Acee

On 7/14/20, 12:52 PM, "Linda Dunbar" <[email-masked]> wrote:

    Christian, 

    Linda

    -----Original Message-----
    From: Christian Hopps <[email-masked]> 
    Sent: Saturday, July 11, 2020 6:42 AM
    To: Linda Dunbar <[email-masked]>
    Cc: Christian Hopps <[email-masked]>; LEI LIU <[email-masked]>; Huaimo Chen <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: [Lsr] Request WG adoption of TTZ

    Thanks,
    Chris.
    [As WG member]

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 14 Jul 2020 17:26:01 +0000

Acee, 

We have deployment of using BGP to group a set of SDWAN nodes as one entity and exchange link/paths/ports information among sites/nodes. 

TTZ could be another option. 

Linda

-----Original Message-----
From: Acee Lindem (acee) <[email-masked]> 
Sent: Tuesday, July 14, 2020 11:59 AM
To: Linda Dunbar <[email-masked]>; Christian Hopps <[email-masked]>
Cc: LEI LIU <[email-masked]>; Huaimo Chen <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] Request WG adoption of TTZ

Linda, 

Acee

    Christian, 

    Linda

    -----Original Message-----
    From: Christian Hopps <[email-masked]> 
    Sent: Saturday, July 11, 2020 6:42 AM
    To: Linda Dunbar <[email-masked]>
    Cc: Christian Hopps <[email-masked]>; LEI LIU <[email-masked]>; Huaimo Chen <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: [Lsr] Request WG adoption of TTZ

    Thanks,
    Chris.
    [As WG member]

    > (TTZ for short) https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2F&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C787e31692b91480c725c08d828172572%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303427174223715&amp;sdata=%2F4hwW%2FHPgVyrbjmdXOSZCZezIaDj8UbVrlXWDLjrgkU%3D&amp;reserved=0 .
    > 
    > 
    > 
    >     "Area Proxy" https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-lsr-isis-area-proxy-03&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C787e31692b91480c725c08d828172572%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303427174223715&amp;sdata=Mxbq2EqOfFhwncb5gIdvTYsFM67igcBneuuX9J636qc%3D&amp;reserved=0
    > 
    >     "Flood Reflection" https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-przygienda-lsr-flood-reflection-01&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C787e31692b91480c725c08d828172572%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303427174233711&amp;sdata=nIRWxpe9NSa2fy7xZb7HvVDns6og7UsX9kbpYlb9ZIE%3D&amp;reserved=0
    > 
    > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C787e31692b91480c725c08d828172572%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303427174233711&amp;sdata=vffz12fjWVF%2FBmxMWk47LujDJAyIlyFvmD6hzLiMGsQ%3D&amp;reserved=0
    > 
    > 
    > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C787e31692b91480c725c08d828172572%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303427174233711&amp;sdata=vffz12fjWVF%2FBmxMWk47LujDJAyIlyFvmD6hzLiMGsQ%3D&amp;reserved=0

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 14 Jul 2020 17:31:55 +0000

Linda, 

On 7/14/20, 1:26 PM, "Linda Dunbar" <[email-masked]> wrote:

    Acee, 

I don't see how it would work to replace BGP and RR with IS-IS TTZ for  SDWAN Fabric setup. However, that is probably a topic that would be better addressed in the RTG WG. 

Thanks,
Acee

    Linda

    -----Original Message-----
    From: Acee Lindem (acee) <[email-masked]> 
    Sent: Tuesday, July 14, 2020 11:59 AM
    To: Linda Dunbar <[email-masked]>; Christian Hopps <[email-masked]>
    Cc: LEI LIU <[email-masked]>; Huaimo Chen <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: [Lsr] Request WG adoption of TTZ

    Linda, 

    Acee

        Christian, 

        Linda

        -----Original Message-----
        From: Christian Hopps <[email-masked]> 
        Sent: Saturday, July 11, 2020 6:42 AM
        To: Linda Dunbar <[email-masked]>
        Cc: Christian Hopps <[email-masked]>; LEI LIU <[email-masked]>; Huaimo Chen <[email-masked]>; [email-masked]; [email-masked]
        Subject: Re: [Lsr] Request WG adoption of TTZ

        Thanks,
        Chris.
        [As WG member]

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 14 Jul 2020 17:57:24 +0000

Acee, 

Many networks have BGP or/and ISIS. 
Encoding of BGP messages are discussed in IDR WG, and the encoding of ISIS is discussed LSR WG. 
The TTZ zone draft is about ISIS encoding of TTZ, therefore, the discussion should be in the LSR Wg, instead of RTGwg (in my opinion). 

Maybe, the discussion on why TTZ should replace BGP can be in RTGwg. But this TTZ zone draft is not about replacing BGP. 

Linda 

-----Original Message-----
From: Acee Lindem (acee) <[email-masked]> 
Sent: Tuesday, July 14, 2020 12:32 PM
To: Linda Dunbar <[email-masked]>; Christian Hopps <[email-masked]>
Cc: LEI LIU <[email-masked]>; Huaimo Chen <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] Request WG adoption of TTZ

Linda, 

    Acee, 

Thanks,
Acee

    Linda

    -----Original Message-----
    From: Acee Lindem (acee) <[email-masked]> 
    Sent: Tuesday, July 14, 2020 11:59 AM
    To: Linda Dunbar <[email-masked]>; Christian Hopps <[email-masked]>
    Cc: LEI LIU <[email-masked]>; Huaimo Chen <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: [Lsr] Request WG adoption of TTZ

    Linda, 

    Acee

        Christian, 

        Linda

        -----Original Message-----
        From: Christian Hopps <[email-masked]> 
        Sent: Saturday, July 11, 2020 6:42 AM
        To: Linda Dunbar <[email-masked]>
        Cc: Christian Hopps <[email-masked]>; LEI LIU <[email-masked]>; Huaimo Chen <[email-masked]>; [email-masked]; [email-masked]
        Subject: Re: [Lsr] Request WG adoption of TTZ

        Thanks,
        Chris.
        [As WG member]

        > (TTZ for short) https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2F&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cd8af0da5bafd40e70fce08d8281bd3e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303447263980613&amp;sdata=L8xHMIno4kitHe9mnfLNJ0yeRTbRrKX3gVK6AnbAet4%3D&amp;reserved=0 .
        > 
        > 
        > 
        >     "Area Proxy" https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-lsr-isis-area-proxy-03&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cd8af0da5bafd40e70fce08d8281bd3e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303447263980613&amp;sdata=y84q%2B9%2FYddSZo%2FYEDgPNWgByUl2IzxVdrKAGqTAPxHE%3D&amp;reserved=0
        > 
        >     "Flood Reflection" https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-przygienda-lsr-flood-reflection-01&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cd8af0da5bafd40e70fce08d8281bd3e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303447263980613&amp;sdata=3yJFlhcApc9Bi1sOlJpHNy96Ux9TIVVXLFT0YXWXrWo%3D&amp;reserved=0
        > 
        > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cd8af0da5bafd40e70fce08d8281bd3e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303447263980613&amp;sdata=LMpTmkWQy6eTxYdEdYMcuhz%2BI6jq%2B3Z3V1SVV86VDjc%3D&amp;reserved=0
        > 
        > 
        > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cd8af0da5bafd40e70fce08d8281bd3e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303447263980613&amp;sdata=LMpTmkWQy6eTxYdEdYMcuhz%2BI6jq%2B3Z3V1SVV86VDjc%3D&amp;reserved=0

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 14 Jul 2020 18:02:14 +0000

Linda, 

On 7/14/20, 1:57 PM, "Linda Dunbar" <[email-masked]> wrote:

    Acee, 

But you just said "TTZ is another option?" And if IS-IS isn't running over the SDWAN overlay, how is IS-IS TTZ even applicable to solving any problem in SDWAN?

Thanks,
Acee

    Linda 

    -----Original Message-----
    From: Acee Lindem (acee) <[email-masked]> 
    Sent: Tuesday, July 14, 2020 12:32 PM
    To: Linda Dunbar <[email-masked]>; Christian Hopps <[email-masked]>
    Cc: LEI LIU <[email-masked]>; Huaimo Chen <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: [Lsr] Request WG adoption of TTZ

    Linda, 

        Acee, 

    Thanks,
    Acee

        Linda

        -----Original Message-----
        From: Acee Lindem (acee) <[email-masked]> 
        Sent: Tuesday, July 14, 2020 11:59 AM
        To: Linda Dunbar <[email-masked]>; Christian Hopps <[email-masked]>
        Cc: LEI LIU <[email-masked]>; Huaimo Chen <[email-masked]>; [email-masked]; [email-masked]
        Subject: Re: [Lsr] Request WG adoption of TTZ

        Linda, 

        Acee

            Christian, 

            Linda

            -----Original Message-----

            Thanks,
            Chris.
            [As WG member]

---

From: Henk Smit <[email-masked]>
Date: Wed, 15 Jul 2020 14:22:25 +0200

Huaimo Chen wrote on 2020-07-14 06:09:

>  2). IS-IS TTZ abstracts a zone to a single node. A zone is any target
> block or piece of an IS-IS area, which is to be abstracted. This seems
> more flexible and convenient to users.

I don't agree that this convenience is really beneficial.
I actually think this convenience is a downside.

Link-state protocols are not easy to understand. And we already
have the misfortune that IS-IS and OSPF use different names for things.
Adding the new concept of a "zone", while we already have the
concept of an area makes things only more complex.

How often will this new flexibility be used in the real world ?
I still haven't seen an answer to Christian Hopp's simple question:
"Has RFC8099 been deployed by anyone ?"
Anyone who has an answer ?

My favorite rule of RFC1925 is rule 12:
    In protocol design, perfection has been reached not when there is
    nothing left to add, but when there is nothing left to take away.

Adding a new concept, with very little benefit, hurts the protocol
in the long run. The ability to abstract an area, and not also a zone,
is strong enough to be worthwhile, imho.

henk.

---

From: John E Drake <[email-masked]>
Date: Wed, 15 Jul 2020 14:19:09 +0000

I agree w/ Henk.  The TTZ seems to be a gratuitous addition.

Yours Irrespectively,

John

Juniper Business Use Only

> From: Lsr <[email-masked]> On Behalf Of Henk Smit
> Sent: Wednesday, July 15, 2020 8:22 AM
> Cc: [email-masked]
> [External Email. Be cautious of content]
> 
> 
> Link-state protocols are not easy to understand. And we already have the
> misfortune that IS-IS and OSPF use different names for things.
> Adding the new concept of a "zone", while we already have the concept of an
> area makes things only more complex.
> 
> Adding a new concept, with very little benefit, hurts the protocol in the long run.
> The ability to abstract an area, and not also a zone, is strong enough to be
> worthwhile, imho.
> 
> henk.
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
> 6yMaO-
> gk!Qd22Qan7jubM_Vup5P5G6gsGg_horPl4PSDx8qS_v03ZIb8sNalgwEsGJ7Q61cc
> $

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 15 Jul 2020 14:36:44 +0000

+1

I think Henk has spoken eloquently here - as have others before him.

Abstracting an area may be useful - the WG has yet to fully decide on that.
But nothing so far has demonstrated that we need to go even further and abstract a subset of an area.

   Les

> From: Lsr <[email-masked]> On Behalf Of John E Drake
> Sent: Wednesday, July 15, 2020 7:19 AM
> To: Henk Smit <[email-masked]>; Huaimo Chen
> <[email-masked]>
> Cc: [email-masked]

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 15 Jul 2020 09:37:43 -0700

Dear Chris,

> Has RFC8099 been deployed by anyone?

The simple answer is I don't know. I would let the authors of 8099 speak up
who might know about the deployment status and how this experimental RFC
helped.

I also believe this question is more relevant if there is a BIS document
for the same as discussed in the list for further enhancements and
possible deployment experience (as it's possible who is using this and
might not be active here).

--
Uma C.

> I would be very interested in hearing from operators who have experience
> with TTZ since RFC8099 has been around for over 3 years now.
>

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 15 Jul 2020 09:52:35 -0700

I actually think not  having more configuration across the network to
enable a new feature is more useful even if
you don't do this operation every single day (especially if you want to
roll back).

> concept of an area makes things only more complex.

Agree in general.

I would say this is no more complex than what has been adopted already or
the slew of proposals we have been seeing here.

I too think as some other said we should have ideally adopted only one
proposal by merging whatever possible.
As  that is not the case and 2 parallel proposals have already been
accepted as WG experimental track, and given the interest/support on this
particular topic
I would think it's reasonable to continue this experiment in IS-IS too as
is done in OSPF.

--
Uma C.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 15 Jul 2020 17:14:19 +0000

Speaking as WG member…

See inline.

From: Lsr <[email-masked]> on behalf of Uma Chunduri <[email-masked]>
Date: Wednesday, July 15, 2020 at 12:52 PM
To: Henk Smit <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Huaimo Chen <[email-masked]>
Subject: Re: [Lsr] Request WG adoption of TTZ

On Wed, Jul 15, 2020 at 5:22 AM Henk Smit <[email-masked]<mailto:[email-masked]>> wrote:

I actually think not  having more configuration across the network to enable a new feature is more useful even if
you don't do this operation every single day (especially if you want to roll back).

Agree in general.

I would say this is no more complex than what has been adopted already or the slew of proposals we have been seeing here.

I too think as some other said we should have ideally adopted only one proposal by merging whatever possible.
As  that is not the case and 2 parallel proposals have already been accepted as WG experimental track, and given the interest/support on this particular topic
I would think it's reasonable to continue this experiment in IS-IS too as is done in OSPF.

I think that the two proposals that have already been adopted as experimental are VERY different in the way they solve the problem of better LSDB scalability across an IS-IS routing domain. Conversely, now that the IS-IS TTZ has adopted the Area Proxy mechanisms of having an Area/Zone leader generate a single LSP representing the Area/Zone, the two proposals are very similar. I agree with Henk, Les, and John that the purported advantages of TTZ are not required. These advantages being arbitrary abstraction boundaries and a description of the transition mechanisms.

Thanks,
Acee

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 15 Jul 2020 10:38:27 -0700

Acee,

In-line ..

On Wed, Jul 15, 2020 at 10:14 AM Acee Lindem (acee) <[email-masked]> wrote:

> Speaking as WG member…
>
>
>
> See inline.
>
>
>
> *From: *Lsr <[email-masked]> on behalf of Uma Chunduri <
> [email-masked]>
> *Date: *Wednesday, July 15, 2020 at 12:52 PM
> *To: *Henk Smit <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Huaimo Chen <
> [email-masked]>
> *Subject: *Re: [Lsr] Request WG adoption of TTZ
>
>
>
>
>
>
>
> I think that the two proposals that have already been adopted as
> experimental are VERY different in the way they solve the problem of better
> LSDB scalability across an IS-IS routing domain.
>

You are right, of course. IS-IS TTZ draft focuses on abstracting a zone
(i.e., block) of an IS-IS area to a single node.

RFC 8099 is for abstracting a zone of an OSPF area to its edges full mesh.
So, afais, IS-IS TTZ is much better than RFC 8099 regarding improving
network scalability.

Conversely, now that the IS-IS TTZ has adopted the Area Proxy mechanisms of
> having an Area/Zone leader generate a single LSP representing the
> Area/Zone, the two proposals are very similar.
>

Thanks for pointing this;

> I agree with Henk, Les, and John that the purported advantages of TTZ are
> not required.
>
These advantages being arbitrary abstraction boundaries and a description
> of the transition mechanisms.
>

I would leave this to folks who want to deploy, if these advantages matter
for them or not matter much.

Thank you!

--
Uma C.

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 16 Jul 2020 00:41:28 +0000

Hi Henk,

"Adding a new concept, with very little benefit, hurts the protocol in the long run. The ability to abstract an area, and not also a zone, is strong enough to be worthwhile, imho."

Your conclusion here seems very subjective.
What's the criterion the evaluate the benefit? What I see the TTZ does have benefit.
I am also wandering how it hurts the protocol in the long run?
...

Tianran

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Henk Smit
Sent: Wednesday, July 15, 2020 8:22 PM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] Request WG adoption of TTZ

Link-state protocols are not easy to understand. And we already have the misfortune that IS-IS and OSPF use different names for things.
Adding the new concept of a "zone", while we already have the concept of an area makes things only more complex.

Adding a new concept, with very little benefit, hurts the protocol in the long run. The ability to abstract an area, and not also a zone, is strong enough to be worthwhile, imho.

henk.

---

From: Henk Smit <[email-masked]>
Date: Thu, 16 Jul 2020 10:45:54 +0200

Hello Tianran,

Warning, long email again.

> What's the criterion to evaluate the benefit?

As people have asked before, did any provider or
enterprise ever use rfc8099 in their network ?

As I wrote, one of my criteria is rfc1925. I like
technology to be understandable. I like protocols to
be (relatively) easy to implement. The more unused
cruft there is, the further we get away from that goal.

I'll give you an example. Did you, or your company ever
implement rfc2973 ? That's mesh-groups in IS-IS.
I'm sure some customers put it on their wishlist.
Did any provider or customer ever use it ?
I asked this question at my last job, and nobody knew the
answer. I suspect nobody in the world ever used mesh-groups.

Around the time I got in touch with IS-IS, in spring 1996,
there was a problem that was seen 2 of the 3 largest ISPs
in the US (UUnet and iMCI). Both networks melted because
of IS-IS. All routers in their networks were 100% cpu
time running IS-IS, busy exchanging LSPs. While no progress
was made. The only solution was to reboot all routers in
the backbone at the same time (several hundred routers).
This happened more than once in both networks.

To relieve the burden of flooding, mesh-groups were
implemented, and rfc2973 was written. However, a short
while later I became the sole IS-IS programmer for that
router vendor. I was able to reproduce the problem in the lab.
I then realized what the issue was. A fix of 10 lines
of extra code fixed the problem. No customer ever reported
those meltdowns again. That fix was the real solution.
Not writing another RFC.

In the mean-time, we have an extra RFC, about mesh-groups.
Every book and manual on IS-IS has to spent time explaining
what mesh-groups are. Every vendor has to implement it.
Even when nobody in the world is using it. Mesh-groups were
a superfluous idea. What I (and many others) are saying is
that we don't want to specify and implement unnecessary things.
Even when nobody is using such a thing, it will live on forever.

> What I see the TTZ does have benefit.

Yes, TTZ and proxy-areas have benefit. Nobody is disagreeing.

But what people don't like is the new concept of a zone.
If you can abstract exactly one area into exactly one proxy-LSP,
that is good enough for 99.9 % of cases. In OSPF it is harder to
split or merge an area. In IS-IS it is a lot easier. So a
network operator can design and change his areas first. And
then implement proxy-areas as she/he wishes. Without much
downtime.

If we introduce the concept of a "zone", someone is going to
have to explain that to everybody in the world who uses IS-IS.
Have you ever taught a class on IS-IS to people who don't know
routing protocols very well ?

> I am also wandering how it hurts the protocol in the long run ?

Adding stuff that nobody uses makes everything more complex.
I know it seems as if the goal over the last 15 years was to make
every thing more complex. So what's the problem with adding yet
another RFC ?

But I like simple things.

henk.

Tianran Zhou wrote on 2020-07-16 02:41:

> > "Adding a new concept, with very little benefit, hurts the protocol in
> > the long run. The ability to abstract an area, and not also a zone, is
> > strong enough to be worthwhile, imho."
> 
> ....

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 16 Jul 2020 10:19:02 +0000

Hi Henk,

Thanks very much for your long email.
I fully agree with what you said on the criterion. This is generally always correct. 
But still you cannot score a draft with it.
That means I can probably say most of the IETF RFCs has  no use. 
I can also list one hundred RFCs that is not implemented. Are you going to obsolete them all?
Who knows if they are useful in the future?
If you find it no use, just not to implement it. How could it make your system complex?

Best,
Tianran

-----Original Message-----
From: Henk Smit [mailto:[email-masked]] 
Sent: Thursday, July 16, 2020 4:46 PM
To: Tianran Zhou <[email-masked]>
Cc: Huaimo Chen <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Request WG adoption of TTZ

Hello Tianran,

> What's the criterion to evaluate the benefit?

As people have asked before, did any provider or enterprise ever use rfc8099 in their network ?

As I wrote, one of my criteria is rfc1925. I like technology to be understandable. I like protocols to be (relatively) easy to implement. The more unused cruft there is, the further we get away from that goal.

I'll give you an example. Did you, or your company ever implement rfc2973 ? That's mesh-groups in IS-IS.
I'm sure some customers put it on their wishlist.
Did any provider or customer ever use it ?
I asked this question at my last job, and nobody knew the answer. I suspect nobody in the world ever used mesh-groups.

Around the time I got in touch with IS-IS, in spring 1996, there was a problem that was seen 2 of the 3 largest ISPs in the US (UUnet and iMCI). Both networks melted because of IS-IS. All routers in their networks were 100% cpu time running IS-IS, busy exchanging LSPs. While no progress was made. The only solution was to reboot all routers in the backbone at the same time (several hundred routers).
This happened more than once in both networks.

To relieve the burden of flooding, mesh-groups were implemented, and rfc2973 was written. However, a short while later I became the sole IS-IS programmer for that router vendor. I was able to reproduce the problem in the lab.
I then realized what the issue was. A fix of 10 lines of extra code fixed the problem. No customer ever reported those meltdowns again. That fix was the real solution.
Not writing another RFC.

In the mean-time, we have an extra RFC, about mesh-groups.
Every book and manual on IS-IS has to spent time explaining what mesh-groups are. Every vendor has to implement it.
Even when nobody in the world is using it. Mesh-groups were a superfluous idea. What I (and many others) are saying is that we don't want to specify and implement unnecessary things.
Even when nobody is using such a thing, it will live on forever.

But what people don't like is the new concept of a zone.
If you can abstract exactly one area into exactly one proxy-LSP, that is good enough for 99.9 % of cases. In OSPF it is harder to split or merge an area. In IS-IS it is a lot easier. So a network operator can design and change his areas first. And then implement proxy-areas as she/he wishes. Without much downtime.

If we introduce the concept of a "zone", someone is going to have to explain that to everybody in the world who uses IS-IS.
Have you ever taught a class on IS-IS to people who don't know routing protocols very well ?

Adding stuff that nobody uses makes everything more complex.
I know it seems as if the goal over the last 15 years was to make every thing more complex. So what's the problem with adding yet another RFC ?

henk.

Tianran Zhou wrote on 2020-07-16 02:41:

> > "Adding a new concept, with very little benefit, hurts the protocol 
> > in the long run. The ability to abstract an area, and not also a 
> > zone, is strong enough to be worthwhile, imho."
>

---

From: Christian Hopps <[email-masked]>
Date: Thu, 16 Jul 2020 07:54:11 -0400

My comments about what the WG should be doing are "As WGChair", I'm not commenting directly on TTZ, but on the broader comments/questions below.

> On Jul 16, 2020, at 6:19 AM, Tianran Zhou <[email-masked]> wrote:
> 
> Hi Henk,
> 
> I can also list one hundred RFCs that is not implemented.

This is not what we strive for in LSR.

>  Are you going to obsolete them all?

No, but we as a WG can strive to not contribute to this problem.

> Who knows if they are useful in the future?

LSR is not a research WG or a technical journal.

> If you find it no use, just not to implement it. How could it make your system complex?

This statement flies in the face of market realty.

People who have to fill RFPs from prospective customers, knowing that they are competing against other vendors filling those same RFPs out, can tell you why you can't just "not implement RFCs" if you don't want to, even when they will never actually be used by those same customers. The short answer is: RFPs are very often not written by the engineers that actually build and run the customer's networks; however, answers to RFPs have a direct impact on which vendors products are purchased by the customers.

So lots of unused RFCs leads to lots of useless code being written to win customers, which then leads to huge protocol code bases that are too complex and fragile, as well as protocols that are hard to comprehend and thus manage properly, and so ultimately destabalize the internet -- we have failed at this point.

This may be less of an issue with other WGs; however, the IGPs are a *critical* part of the internet infrastructure, and they need to be treated as such, and we should strive to do so.

Thanks,
Chris.

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 16 Jul 2020 19:16:13 +0000

Hi Acee,

> Conversely, now that the IS-IS TTZ has adopted the Area Proxy mechanisms of having an Area/Zone leader generate a single LSP representing the Area/Zone, the two proposals are very similar.

[HC]:  It looks like the other way around. In 2013, IS-IS TTZ .00 draft describes the mechanism of having a Zone DR (called TTZ-DR) to generate a single LSP for representing the single node abstracted from the Zone. DR and Leader are just two different names of the same node. In 2018, Area Proxy .00 draft presents the mechanism of having an Area leader to generate a single LSP representing the node abstracted from the Area. There are some big differences between IS-IS TTZ and Area Proxy even though they are similar.

>I think that the two proposals that have already been adopted as experimental are VERY different in the way they solve the problem of better LSDB scalability across an IS-IS routing domain.

[HC]: The three proposals (the two adopted as experimental recently and IS-IS TTZ) are all very different even though they solve the same problem for better LSDB scalability. It is would be reasonable and beneficial to allow IS-IS TTZ to move forward also as experimental.

>I agree with Henk, Les, and John that the purported advantages of TTZ are not required. These advantages being arbitrary abstraction boundaries and a description of the transition mechanisms.

[HC]: It seems that reducing the service interruption, making operations to be simple, and so on are expected by users in general.

Best Regards,
Huaimo
________________________________
From: Lsr <[email-masked]> on behalf of Uma Chunduri <[email-masked]>
Sent: Wednesday, July 15, 2020 1:38 PM
To: Acee Lindem (acee) <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Lsr] Request WG adoption of TTZ

Acee,

In-line ..

On Wed, Jul 15, 2020 at 10:14 AM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Speaking as WG member…

See inline.

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of Uma Chunduri <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 15, 2020 at 12:52 PM
To: Henk Smit <[email-masked]<mailto:[email-masked]>>
Cc: "lsr@ietf..org<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Request WG adoption of TTZ

Agree in general.

I think that the two proposals that have already been adopted as experimental are VERY different in the way they solve the problem of better LSDB scalability across an IS-IS routing domain.

You are right, of course. IS-IS TTZ draft focuses on abstracting a zone (i.e., block) of an IS-IS area to a single node.

RFC 8099 is for abstracting a zone of an OSPF area to its edges full mesh.  So, afais, IS-IS TTZ is much better than RFC 8099 regarding improving network scalability.

Conversely, now that the IS-IS TTZ has adopted the Area Proxy mechanisms of having an Area/Zone leader generate a single LSP representing the Area/Zone, the two proposals are very similar.

I agree with Henk, Les, and John that the purported advantages of TTZ are not required.

These advantages being arbitrary abstraction boundaries and a description of the transition mechanisms.

I would leave this to folks who want to deploy, if these advantages matter for them or not matter much.

Thank you!

--
Uma C.

Thanks,
Acee

--

Uma C.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 16 Jul 2020 21:39:00 +0000

Huaimo -

I am not going to comment on the history issues - though I understand why that is of significance to you.

Otherwise, I don't think you are appreciating the key point many of us are making - which is that we do not need to introduce a new concept "zone" (subset of an area).
It is sufficient to operate on an area.

      "reducing the service interruption, making operations to be simple, and so on"

does not require introduction of zones.  We can already do so using areas - including merging/splitting of an area.

The argument then against moving forward with both Area Proxy and TTZ is that they are redundant.

Until you demonstrate something compelling which cannot be done with an area but can be done with a zone, I simply do not see why we need to introduce zones to the protocol.

    Les

From: Lsr <[email-masked]> On Behalf Of Huaimo Chen
Sent: Thursday, July 16, 2020 12:16 PM
To: Acee Lindem (acee) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Acee,

Best Regards,
Huaimo
________________________________
From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of Uma Chunduri <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, July 15, 2020 1:38 PM
To: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Request WG adoption of TTZ

Acee,

In-line ..

Speaking as WG member...

See inline.

Cc: "lsr@ietf...org<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Huaimo Chen <[email-masked]<mailto:[email-masked]>>

Agree in general.

Thank you!

--
Uma C.

Thanks,
Acee

--

Uma C.

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 17 Jul 2020 03:18:12 +0000

Thanks. I am really glad to understand the LSR chair's thoughts.
Well OK. I understand LSR would like a high bar for IGP extension.
But your comparison with " research WG or a technical journal " makes no sense. It's common sense.
And your statement on the complexity twisted too many none engineer reasons.
I would like the IETF to be more pure on technique.
Anyway, I respect the tradition of this WG.
I just want to know if the WG request for interop and implementation report for every draft?

Thanks,
Tianran

-----Original Message-----
From: Christian Hopps [mailto:[email-masked]] 
Sent: Thursday, July 16, 2020 7:54 PM
To: Tianran Zhou <[email-masked]>
Cc: Christian Hopps <[email-masked]>; Henk Smit <[email-masked]>; [email-masked]; Huaimo Chen <[email-masked]>
Subject: Re: [Lsr] Request WG adoption of TTZ

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Fri, 17 Jul 2020 07:09:14 -0400

> On Jul 16, 2020, at 11:18 PM, Tianran Zhou <[email-masked]> wrote:
> 

[As a general IETF participant]

I believe we all would like this, but real-world dynamics impose none-the-less.

> I just want to know if the WG request for interop and implementation report for every draft?

[chair hat] We always prefer to have this. We do not always get it, unfortunately.

Thanks,
Chris.

---

From: Huaimo Chen <[email-masked]>
Date: Sat, 18 Jul 2020 01:47:17 +0000

Hi Les,

    > “reducing the service interruption, making operations to be simple, and so on”

 does not require introduction of zones.  We can already do so using areas – including merging/splitting of an area.

[HC]: Smooth merging/splitting of an area seems not reduce the service interruption while Area Proxy is abstracting an existing IS-IS area to a single node because the adjacency ups and downs. IS-IS TTZ seems reduce the service interruption while it is abstracting a zone to a single node since it provides a smooth transferring from a zone to the single node. In addition, operations on IS-IS TTZ for abstracting a zone to a single node seems simpler than creating a new L1 area (through merging/splitting of an area in some cases) and abstracting the L1 area to a single node.

> Until you demonstrate something compelling which cannot be done with an area but can be done with a zone, I simply do not see why we need to introduce zones to the protocol.

[HC]: It seems that “reducing the service interruption, making operations to be simpler" provided by IS-IS TTZ with a zone should be compelling enough.

Best Regards,
Huaimo
________________________________
From: Les Ginsberg (ginsberg) <[email-masked]>
Sent: Thursday, July 16, 2020 5:39 PM
To: Huaimo Chen <[email-masked]>; Acee Lindem (acee) <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: RE: [Lsr] Request WG adoption of TTZ

Huaimo –

I am not going to comment on the history issues – though I understand why that is of significance to you.

Otherwise, I don’t think you are appreciating the key point many of us are making – which is that we do not need to introduce a new concept “zone” (subset of an area).

      “reducing the service interruption, making operations to be simple, and so on”

does not require introduction of zones.  We can already do so using areas – including merging/splitting of an area.

    Les

Hi Acee,

Best Regards,

Huaimo

Acee,

In-line ..

Speaking as WG member…

See inline.

Agree in general.

Thank you!

--

Uma C.

Thanks,
Acee

--

Uma C.

---

From: [email-masked]
Date: Fri, 17 Jul 2020 19:46:22 -0700

Hi Huaimo,

> > Until you demonstrate something compelling which cannot be done with an area but can be done with a zone, I simply do not see why we need to introduce zones to the protocol..
> 

My apologies if this comes off as too preachy, but perhaps it will help if we are a bit more explicit about out thinking in case language is gettiing in the way. 

Engineering is all about trade-offs. With everything that we design there are benefits (hopefully) and costs (hopefully obvious). In any design, we want the benefits to outweigh the costs. Unfortunately, the evaluation of those benefits and costs are subjective. 

You’ve just seen Area Proxy go through a major revision because some of us felt that the costs (a couple of extra TLV code points) were too high.  Some of us disagree. ;-)

No one is suggesting that the zone concept has no value. No one is saying that smooth transitions have no value. It’s very clear that they do.  If we could do that with zero costs, we certainly would. However, the costs are non-zero in additional complexity and additional code.

What we’re trying to tell you is that in our humble opnion, the tradeoff isn’t in favor of TTZ. The costs are higher than the benefits.

There is no definitive right answer in subjective situations. We, as a community, have to come to rough consensus. Frequently to get there, there have to be compromises and tough decisions.

Regards,
Tony