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 protected]> On Behalf Of Huaimo Chen
Sent: Thursday, July 16, 2020 12:16 PM
To: Acee Lindem (acee) <[email protected]>
Cc: [email protected]
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 <[email protected]<mailto:[email protected]>> on behalf of Uma
Chunduri <[email protected]<mailto:[email protected]>>
Sent: Wednesday, July 15, 2020 1:38 PM
To: Acee Lindem (acee) <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Subject: Re: [Lsr] Request WG adoption of TTZ
Acee,
In-line ..
On Wed, Jul 15, 2020 at 10:14 AM Acee Lindem (acee)
<[email protected]<mailto:[email protected]>> wrote:
Speaking as WG member...
See inline.
From: Lsr <[email protected]<mailto:[email protected]>> on behalf of Uma
Chunduri <[email protected]<mailto:[email protected]>>
Date: Wednesday, July 15, 2020 at 12:52 PM
To: Henk Smit <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>,
Huaimo Chen <[email protected]<mailto:[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.
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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
