Opened 9 years ago

Closed 9 years ago

#80 closed technical (fixed)

Router Performances

Reported by: luigi@… Owned by:
Priority: major Component: draft-ietf-lisp
Severity: - Keywords:
Cc:

Description

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" ?

Change History (2)

comment:1 Changed 9 years ago by jmh@…

  • Resolution set to fixed
  • Status changed from new to resolved

As the section itself is informative, and probably useful to readers, with the changes made in -11 this appears to be sufficiently addressed.

comment:2 Changed 9 years ago by luigi@…

  • Status changed from resolved to closed
Note: See TracTickets for help on using tickets.