Tony,
> The new LSP seems to imply a forklift of the whole network which area proxy > does not require, in fact flood reflection has been carefully constructed to > touch minimum possible amount of nodes in the network and additionally allow > a node-by-node migration. To be accurate, area proxy requires that the nodes within the area support area proxy. No upgrade of the nodes outside of the abstracted area is required. Only software upgrades are requires, so no forklifts are required. > Also, AFAIS area proxy preconditions far more configuration that has to be > "just so" on interfaces and nodes and it has to align L1 and L2 carefully by > e.g. preconditioning which interfaces are in and whjich are out. Understanding which interfaces are an area boundary is expedient for not having changes at adjacency formation time. IS-IS is quite flexible and will happily allow L1 and L2 adjacencies in any combination to co-exist on a single LAN. In the Arista implementation, we found it helpful to have additional specific configuration to explicitly understand the intended abstraction. Other implementations may not require this. We have yet to see any issue with this in a practical network. > The "area lead" is same thing pretty much as PGL in PNNI and will exhibit its > own set of complexities the draft does not address yet. I know it's terse > statement ;-) Not only is it terse, it’s content free. If you have no issues that you can cite, then this is simply Fear, Uncertainty, and Doubt. > Just purely as personal experience and subjective view, I didn't see > implementation of area proxy yet & depending what overall system features you > expect to work with it I would venture the implementation complexity will be > significantly higher than flood reflection. You don’t have any information, but you want us to believe your opinion. > Because the draft seems to "read simpler" is not correlated with simplicity > in resulting implementation and deployment complexity in terms of system wide > features you expect to work ;-) As simple exercise, think how would you > synchronize the overload bit on startup to prevent the system trying to > forward before all nodes (which may be mix of different systems) in area > proxy have the necessary FIB ;-) No synchronization is required. If an L1L2 system within the abstracted area has the overload bit set, then its information is not included in the proxy LSP. > Or what happens if someone manages to set overload within the area & > partition it (not hypothetical, real customer discussions from hands-on > operational experience). Partition of the area has been a longstanding problem within IS-IS and has never had an acceptable solution. Area Proxy does not claim to fix the problem. As with legacy IS-IS, operators understand this and create sufficient redundancy within the area so that the odds of a partition are extremely low. In the case of a modern data center as the abstracted area, there can easily be 128 way redundancy, so the odds of a partition are already minimal. Tony _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
