Speaking as WG member… See inline.
From: Lsr <[email protected]> on behalf of Uma Chunduri <[email protected]> Date: Wednesday, July 15, 2020 at 12:52 PM To: Henk Smit <[email protected]> Cc: "[email protected]" <[email protected]>, Huaimo Chen <[email protected]> Subject: Re: [Lsr] Request WG adoption of TTZ On Wed, Jul 15, 2020 at 5:22 AM Henk Smit <[email protected]<mailto:[email protected]>> 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. 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.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
