RE: [lisp-interest] Re: [RRG] Publicly available LISP and shim6 implementations

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Dino et al,

I would like to give a bit more detail as to what I mean by
integrating LISP with SEAL. My proposal is that the LISP header
be modified to provide sufficient function for adapting to the
tunnel path MTU without consuming extra bytes. The way forward
is to replace the 32-bit LISP Nonce with a 32-bit field that
looks very much like the SEAL header. In fact, only 3 bytes are
needed such that you get an extra byte to encode more Locator
Reach Bits - thus extending that field to 38 bits.

Based on (lisp-08, Section 5.1), the new LISP header format I
am proposing is:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |        ID Extension (16)          |  SEAL (8) |S|M|  L/R (6)  |
 LISP  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                    Locator Reach Bits (32)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here, the "ID Extension" provides the upper 16 bits when
concatenated with the 16-bit ip_id field in the outer IPv4
header as the lower 16 bits. This gives a 32bit LISP packet
identification that uniquely identifies each LISP packet,
and avoids the ip_id wraparound issue prevalent for IPv4.
The 32 bit ID is also used as the value returned in reply
messages and serves as a suitable 32bit nonce for that
purpose. The fact that you now also gain 6 extra Locator
Reach Bits further makes this approach superior to using
a more expensive 4-byte nonce.

The 8bit SEAL field is used to control segmentation and
reassembly exactly as specified in draft-templin-seal-22.
This provides assured delivery of packets up to 2KB even
if a modest amount of segmentation and reassembly is
required, and also allows packets larger than 2KB through
without segmentation and reassembly as long as the path
MTU supports it.

All that is needed in addition is a new LISP message type
that the ETR can send to the ITR as indication that the
ITR's messages are being fragmented by in-the-network
IPv4 fragmentation. The ITR reacts to these indications
by using SEAL segmentation to tune out the in-the-network
IPv4 fragmentation.

IMHO, you are now still at the point that you could take
something like this on and be done with the ip_id
wraparound and tunnel MTU issues once-and-for-all. Why
not do it now and be done with it as opposed to a "hit
and hope" approach such as described in LISP Section 5.4?
  
Thanks - Fred
fred.l.templin@boeing.com

>-----Original Message-----
>From: Dino Farinacci [mailto:dino@cisco.com] 
>Sent: Monday, July 21, 2008 11:10 AM
>To: Olivier.Bonaventure@uclouvain.be
>Cc: Templin, Fred L; lisp-interest@lists.civil-tongue.net
>Subject: Re: [lisp-interest] Re: [RRG] Publicly available LISP 
>and shim6 implementations
>
>> Fred,
>>>
>>> Integrating LISP with SEAL is a possible next step of interest.
>>> If you would like to try putting your implementation together
>>> with SEAL, let me know:
>>>
>>>  http://osprey67.com/seal
>>
>> For the moment, our objective is to implement the documented LISP
>> specifications in OpenLISP. We believe that experimenting with the
>> mapping system is more important than looking at different ways of
>> tunneling packets. If the LISP tunneling specifications change, we'll
>> adapt once there is sufficient consensus.
>
>Good point Olivier and I agree with your focus. We shouldn't have  
>anymore huge changes even though -08 introduced the "SMR-bit".
>
>Dino
>
>>
>>
>>
>> Olivier
>>
>> -- 
>> http://inl.info.ucl.ac.be , UCLouvain, Belgium
>
>