Hi Huaimo,

>     > “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.
> 
> [HC]: Smooth merging/splitting of an area seems not reduce the service 
> interruption while Area Proxy is abstracting an existing IS-IS area to a 
> single node because the adjacency ups and downs. IS-IS TTZ seems reduce the 
> service interruption while it is abstracting a zone to a single node since it 
> provides a smooth transferring from a zone to the single node. In addition, 
> operations on IS-IS TTZ for abstracting a zone to a single node seems simpler 
> than creating a new L1 area (through merging/splitting of an area in some 
> cases) and abstracting the L1 area to a single node.
> 
> > 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..
> 
> [HC]: It seems that “reducing the service interruption, making operations to 
> be simpler" provided by IS-IS TTZ with a zone should be compelling enough.
> 


My apologies if this comes off as too preachy, but perhaps it will help if we 
are a bit more explicit about out thinking in case language is gettiing in the 
way. 


Engineering is all about trade-offs. With everything that we design there are 
benefits (hopefully) and costs (hopefully obvious). In any design, we want the 
benefits to outweigh the costs. Unfortunately, the evaluation of those benefits 
and costs are subjective. 

You’ve just seen Area Proxy go through a major revision because some of us felt 
that the costs (a couple of extra TLV code points) were too high.  Some of us 
disagree. ;-)

No one is suggesting that the zone concept has no value. No one is saying that 
smooth transitions have no value. It’s very clear that they do.  If we could do 
that with zero costs, we certainly would. However, the costs are non-zero in 
additional complexity and additional code.

What we’re trying to tell you is that in our humble opnion, the tradeoff isn’t 
in favor of TTZ. The costs are higher than the benefits.

There is no definitive right answer in subjective situations. We, as a 
community, have to come to rough consensus. Frequently to get there, there have 
to be compromises and tough decisions.

Regards,
Tony

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to