Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Tony Li <[e-mail]>]

Hi Les,

> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/ <https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/>
>  
> Both of them discuss in their respective introductions the motivation – which is to address scaling issues in deployment scenarios where the existing IS-IS hierarchy is being asked to “stand on its head” i.e., interconnection between different L1 areas is not to be achieved by utilizing an L2 backbone – rather it is the L1 areas themselves which are required to be used for interconnection of sites (e.g., two datacenters) and the scaling properties of the existing protocol hierarchy when used in this way are not attractive.


I’m not sure where you got that perspective about Area Proxy. That is not the intent at all.

Legacy IS-IS forces a provider to expose some of the topology of an L1 area in L2 if the L1 area is to provide transit.  You literally have to make big chunks of the topology L1L2 and it all shows up in the L2 database. As a result, the amount of abstraction that’s achieved is minimal: only the portions of the L1 area that are NOT L1L2 are abstracted away.

Area Proxy turns up the abstraction dial. Nothing more, nothing less. Abstract away ALL of the L1 area topology. The L1L2 portion of the topology is still present, it’s just no longer visible in the L2 LSDB outside of the area. That’s the scalability win.

There is still an L2 backbone, that is unchanged. Only the abstraction has changed.


> 1)Is this a problem which needs to be solved by link-state protocols?


Yes. IS-IS has an inherent scalability limitation without some additional abstraction.


> Also, many datacenters use BGP (w or w/o IGP) and therefore have other ways to address such issues.


The problem comes from exactly this use case: what happens when your data center becomes a transit node for your backbone?


> 2)If link state protocols do need to solve this problem, what is the preferred way to do that?


I don’t see this as an either/or choice, nor is it one where we’re going to make a useful decision without some market input.


> The alternative is to do what we seem to be doing – allowing multiple solutions to move forward largely without comment. In which case I see no basis on which to object – anyone who can demonstrate a deployment case should then be allowed to move a draft forward – and there are then no standardized solutions.
> (The Experimental Track status for these drafts reflects that reality.)


I would suggest that, as always, the IETF is at its best when it is documenting de facto standards. :-)

Tony