Re: [RAM] Re: LISP-01 I-D

[Dino Farinacci <dino at cisco.com>]

> As i understand it, the new version of LISP described in this 01  
> version of the draft, no longer uses pure IP in IP tunneling, but  
> adds a LISP header to the packets (which contains the nonce for  
> security reasons) right?

That is correct. We are using UDP encapsulation with a LISP header  
for the following reasons:

o Get through firewalls
o ITR hashes on inner header to produce a source port LAG router can  
hash on
o Can carry nonce for ETR anti-spoofing
o Can carry Locator reachability bits

> In section 7, it is stated that:
>
> 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 could support the forwarding
>    model with little or no modification.
>
> MB> in the new version, not only the IP header needs to be added  
> but also the LISP header, so i guess this is not the only action  
> that needs to be performed. Would this still be hardware friendly  
> meaning that you could do little reprogramming of the software in  
> the router to support that? I mean, this appending of the LISP  
> header is supposed to be done for every data packet, right? In the  
> previous

On the ITR, yes if you can preload an encapsulation string that  
contains the outer IP header, the UDP header, and the LISP header.

There is a per-packet selection of the source-port but we felt it was  
important enough to make LAGs work well in the core (which use 5- 
tuple hashing to load-split
traffic over the members of the LAG).

The locator reachability bits and the nonce for a resolved EID entry  
can be preloaded in the encapsulation string.

> version, when IP in IP tunneling was used, i guess the IP in IP  
> encapsulation was already available in hardware, but i guess that  
> the new LISP header will need to be added to the hardware?

Well what was proposed (IP protocol number 4) isn't in a lot of  
hardware. GRE and L2TP are the popular encapsulations.

>    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.

Right. But let's first solve the problems we need to solve. If ITRs  
and ETRs are placed at CE routers, the performance requirement isn't  
as strong as in other parts of the network (you would need around a 1  
Gig of forwarding performance which can be done in software these days).

>    A few implementation techniques can be used to incrementally
>    implement LISP:
>
>
>    o  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 [RFC3056] or 6to4 tunneling [RFC2784] can already
>       support this action.
>
> MB> same applies here, not only adding the outer IP header is  
> needed but also the new LISP header needs to be added

Right, like I said above, you just need to add more bytes.

The problem is on the ETR that has to parse the new format. Typically  
this is either done via:

o Hardwired silicon (in an ASIC).
o In software using general purpose processors.
o In microcode for line-rate performance.

In the later 2 cases, it is much easier to rev the product.

> Regards, marcelo

Thanks again for your comments,
Dino

_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram