Subject: [lisp] #86: On the design goals and requirements (comment 10 reported by Y. Rekhter)

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 28 Apr 2010 04:50:34 -0000

#86: On the design goals and requirements (comment 10 reported by Y. Rekhter)
-------------------------------+--------------------------------------------
Reporter:  wmhaddad@…          |       Owner:                 
    Type:  technical           |      Status:  new            
Priority:  major               |   Component:  draft-ietf-lisp
Severity:  -                   |    Keywords:                 
-------------------------------+--------------------------------------------
 Section 2

 Some of the design goals of this proposal include:

 1.  Require no hardware or software changes to end-systems (hosts).

 2.  Minimize required changes to Internet infrastructure.

 3.  Be incrementally deployable.

 4.  Require no router hardware changes.

 5.  Minimize the number of routers which have to be modified.  In
      particular, most customer site routers and no core routers
      require changes.

 6.  Minimize router software changes in those routers which are
     affected.

 7.  Avoid or minimize packet loss when EID-to-RLOC mappings need to
      be performed.

 Wrt (2), (5), and (6) above, how could one determine whether this proposal
 really minimizes required changes?

 Wrt (4), if this statement means existing routers could be software
 upgraded to be LISP routers, this statement is questionable, for a number
 of reasons, covered elsewhere in this critique.  These include control
 plane bandwidth (existing routers typically have much lower "punt"
 processing bandwidth than hardware switching bandwidth) and
 the complex LISP forwarding plane, which may not be implementable in
 microcoded forwarding engines, especially those that are older (but still
 widely deployed).

 Wrt claim in (5) that "no core routers require changes", that is
 incorrect, as section 5 (p.16) states that:

   If the assumption proves true and transit networks with links
   limited to 1500 byte MTUs are corner cases, it would seem more
   cost-effective to either upgrade or modify the equipment in those
   transit networks to support larger MTUs or to use existing
   mechanisms for accommodating packets that are too large.

 Also, the notion that "no core routers require change(s)" is questionable
 unless one defines the proxies in [INTERWORK] as being non-core routers.

 Wrt (7) above, how could one determine whether this proposal really
 minimizes packet loss?  What needs to be documented is how LISP compares
 with the current routing model in terms of minimizing packet loss.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/86>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues