Subject: [lisp] #80: Router Performances

From: "lisp issue tracker" <[email-masked]>
Date: Mon, 26 Apr 2010 16:32:37 -0000

#80: Router Performances
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:                 
    Type:  technical                      |      Status:  new            
Priority:  major                          |   Component:  draft-ietf-lisp
Severity:  -                              |    Keywords:                 
------------------------------------------+---------------------------------
 '''From Y. Rekhter's review'''
 '''This is comment 35'''

 Section 7 Router Performance Considerations:

  LISP is designed to be very hardware-based forwarding friendly. By
  doing tunnel header prepending [RFC1955] and stripping instead of re-
  writing addresses, existing hardware can support the forwarding model
  with little or no modification. Where modifications are required,
  they should be limited to re-programming existing hardware rather
  than requiring expensive design changes to hard-coded algorithms in
  silicon.

 This is simply an Assertion.

  When a tunnel encapsulated packet is received by an ETR, the outer
  destination address may not be the address of the router. This makes
  it challenging for the control plane to get packets from the
  hardware. This may be mitigated by creating special FIB entries for
  the EID-prefixes of EIDs served by the ETR (those for which the
  router provides an RLOC translation). These FIB entries are marked
  with a flag indicating that control plane processing should be
  performed. The forwarding logic of testing for particular IP protocol
  number value is not necessary. No changes to existing, deployed
  hardware should be needed to support this.

 The above explanation of why no changes to existing deployed hardware
 should be needed is fairly confusing.

  On an ITR, prepending a new IP header is as simple as adding more
  bytes to a MAC rewrite string and prepending the string as part of
  the outgoing encapsulation procedure. Many routers that support GRE
  tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already support
  this action.

 This looks like another Assertion.

  When a received packet's outer destination address contains an EID
  which is not intended to be forwarded on the routable topology
  (i.e. LISP 1.5), the source address of a data packet or the router
  interface with which the source is associated (the interface from
  which it was received) can be associated with a VRF (Virtual
  Routing/Forwarding), in which a different (i.e. non-congruent)
  topology can be used to find EID-to-RLOC mappings.

 What does the part about "When a received packet's ... to be forwarded
 on the routable topology" have to do with the part about "the source
 address of a data packet ... can be associated with a VRF" ?

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