Acee, In-line ..
On Wed, Jul 15, 2020 at 10:14 AM Acee Lindem (acee) <[email protected]> wrote: > 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]> 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
