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 <lsr-boun...@ietf.org> on behalf of Uma Chunduri <umac.i...@gmail..com> Sent: Wednesday, July 15, 2020 1:38 PM To: Acee Lindem (acee) <a...@cisco.com> Cc: lsr@ietf.org <lsr@ietf.org> Subject: Re: [Lsr] Request WG adoption of TTZ Acee, In-line .. On Wed, Jul 15, 2020 at 10:14 AM Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>> wrote: Speaking as WG member… See inline. From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> on behalf of Uma Chunduri <umac.i...@gmail.com<mailto:umac.i...@gmail.com>> Date: Wednesday, July 15, 2020 at 12:52 PM To: Henk Smit <henk.i...@xs4all.nl<mailto:henk.i...@xs4all.nl>> Cc: "l...@ietf..org<mailto:lsr@ietf.org>" <lsr@ietf.org<mailto:lsr@ietf.org>>, Huaimo Chen <huaimo.c...@futurewei.com<mailto:huaimo.c...@futurewei.com>> Subject: Re: [Lsr] Request WG adoption of TTZ On Wed, Jul 15, 2020 at 5:22 AM Henk Smit <henk.i...@xs4all.nl<mailto:henk.i...@xs4all.nl>> 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.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
