Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[[e-mail]]

Hi Robert,


> Of course the objective of the draft is clear and I do not think anyone is questioning that. There was however topic of data and control plane congruence requirement and I think we all agreed by now that this is rather required in link state protocol as it is defined today. 
> 
> As to the overall direction which I think initial Aijun's mail brought up was if hierarchy is actually best answer to scale a protocol. 


It’s the best answer that we have today.


> Divide and conquer is great strategy, but as such it could be realized with flat levels interconnected by ISIS LSP reflectors as pure control plane scaling solution (still reusing most of today's machinery - leaking, summarization etc ...) Some form of DIS analogy except here to interconnect many flat levels. 


If you have a number of areas all at a single level, you need to have some mechanism for computing paths between the areas.  You suggest ‘LSP reflectors’ which might suggest carrying all LSPs from one area and putting them into another area.  That approach has the same scalability properties as just running one single, giant area. I would not recommend this.  

If I take a less literal interpretation of ‘LSP reflectors’, then you are performing summarization, not reflection, at area boundaries. If no further information about the inter-area topology is known, then this devolves to a distance-vector like approach, where summaries circulate between areas and cumulative metric information is used to select the optimal path.  Effectively, you’re running RIP for your level 2 protocol, with all of the benefits and deficiencies of RIP.

If you would like an incremental improvement, you could carry path information with your summaries, and perform a path vector based path selection.  Effectively, you’re running BGP as your level 2 protocol, with all of the benefits and deficiencies of BGP.

And, of course, if you would like to carry full topology information in level 2, you could have the properties of a link-state protocol at level 2. IMHO, this is optimal at this time.

Now, if someone wants to come along and provide an entirely new concept in routing protocols, they could certainly do so, but we really haven’t made significant progress in this area for 25 years, so waiting would seem to well over everyone’s retirement event horizon.



> So I think the overall point to the WG is if building additional data and control plane levels is the most optimal solution to scale link state protocols up. Sure it can be done and it will be one more optional tool in the toolbox, but is this the right/best tool for the job ? 


I submit that the question is largely irrelevant to the matter of working group adoption.  We are not obligated to select only the best, if only because that can change over time. Further, we have no other proposals on the table.  Our proposal is the natural and logical extension of the two-level hierarchy that was originally conceived for IS-IS. From the perspective of getting to ‘running code’ it is the obvious choice because almost all of the code written for level 2 can be trivially abstracted for other levels. We have demonstrated significant working group interest already, so we should move forward so that we can enable people to use this tool if they choose to.

Regards,
Tony