Re: [Lsr] Request WG adoption of TTZ

[Uma Chunduri <[e-mail]>]

Acee,

In-line ..

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

> Speaking as WG member…
>
>
>
> See inline.
>
>
>
> *From: *Lsr <[e-mail]> on behalf of Uma Chunduri <
> [e-mail]>
> *Date: *Wednesday, July 15, 2020 at 12:52 PM
> *To: *Henk Smit <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, Huaimo Chen <
> [e-mail]>
> *Subject: *Re: [Lsr] Request WG adoption of TTZ
>
>
>
>
>
>
>
> On Wed, Jul 15, 2020 at 5:22 AM Henk Smit <[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.
>