I have a problem with the below text:

On 2/13/10 11:39 PM, Lixia Zhang wrote:
> Because of this caching effect, and the fact that the ETR to a
> multihomed destination site is chosen at ITR, LISP design also faces
> challenges of response to component failures. LISP cannot easily test
> reachability of ultimate destinations (e.g. behind an ETR).

As a critique it suffers from lack of specificity.  To say that LISP (or
any of the other proposals, for that matter) "cannot easily" do
something, absent in this case an explanation of what the 'caching
effect' is, for lack of better words, pot shots.  What is one supposed
to do with this "information"?  No citations, no nothing.  I do not mean
to defend LISP here, but simply point out that I remain deeply concerned
about the format and content of this report.  Maybe I haven't been
paying attention for a while, but weren't reachability bits supposed to
handle a significant number of these cases?

> Another class of issues relates to network management and operations.
> - Although LISP does provide significant tools for multi-homing,
>   load-sharing, optimal-entry-selection, etc, these currently depend
> on correct
>   configuration; response to component failures is also limited.

Two problems with the above statement.  The term "limited" suffers the
exact same problem as my previous complaint.  Second, network management
always lags underlying functionality.  Unless you are saying that there
is some fundamental problem that *prevents* network management, this
would seem to be an unfair criticism.

> - LISP is currently working through NAT boxes, but only in limited
>   configurations. In particular, due to the use of fixed UDP ports, it
> is not
>   currently possible to support more than one ETR behind a NAT box.

I've not been following LISP-NAT well enough to know if the above
statement holds true, but I will say that this is the sort of specific
statement that can at least be tested, challenged, agreed to, etc.

rrg mailing list

Reply via email to