Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen <[e-mail]>]

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) <[e-mail]>
Sent: Thursday, July 16, 2020 5:39 PM
To: Huaimo Chen <[e-mail]>; Acee Lindem (acee) <[e-mail]>
Cc: [e-mail] <[e-mail]>
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).

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 <[e-mail]> On Behalf Of Huaimo Chen
Sent: Thursday, July 16, 2020 12:16 PM
To: Acee Lindem (acee) <[e-mail]>
Cc: [e-mail]
Subject: Re: [Lsr] Request WG adoption of TTZ



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 <[e-mail]<mailto:[e-mail]>> on behalf of Uma Chunduri <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 15, 2020 1:38 PM
To: Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Lsr] Request WG adoption of TTZ



Acee,



In-line ..



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

Speaking as WG member…



See inline.



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







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

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.



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





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.



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.



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.





Thanks,
Acee





--

Uma C.