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

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

Dino, 

>-----Original Message-----
>From: Dino Farinacci [mailto:dino@cisco.com] 
>Sent: Monday, July 21, 2008 10:57 PM
>To: Templin, Fred L
>Cc: Olivier.Bonaventure@uclouvain.be; Luigi Iannone; 
>lisp-interest@lists.civil-tongue.net; dmm@cisco.com; David R 
>Oran; Vince Fuller; Scott Brim; Joe Touch; Matt Mathis
>Subject: Re: [lisp-interest] Re: [RRG] Publicly available LISP 
>and shim6 implementations
>
>> 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.
>
>But we need the nonce and we can't increase the header by 4 
>bytes. And  
>why put fragmentation stuff in the packet for those packets you are  
>not fragmenting?

No; there is no increase in the header length. I think you
picked this up after reading ahead further, but you still
get a 4byte nonce with no increase in the header length.

>> 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.
>
>Now we have to get 2 16-bit numbers of different places in the packet  
>and put it together. Not worth it Fred.

Combining the 2 16-bit numbers is trival; arithmetic shift
the high-order bits then or them with the low order bits
into a 32 bit register. Plus, it makes meaningful use of
the 16-bit IPv4 ip_id where the current LISP proposal
does not. 

>> 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?
>
>Sorry, I don't get why we are doing all this?

Because you can never 100% guarantee that you won't trip
over a restricting link in the path. There is legacy 1500
gear in the Internet that will be very difficult to
eradicate, and you can never tell when an operator is
going to mis-configure a link MTU to make it appear
smaller than it actually is.

SEAL also determines the correct MTU when the path only
contains links with large MTUs. Let's say that the
restricting link has an MTU of 6KB. If the ITR initially
thinks the path to the ETR has an MTU of 8KB, it will
get back a nonce-protected MTU discovery message from the
ETR itself (not from a network middlebox or an attacker)
and adjust its path MTU estimate to 6KB. Plus, the 8KB
packet will still make it through.

Finally, SEAL works much better than classical path MTU
discovery when a route change takes an ITR->ETR tunnel
over a path with a smaller MTU. If the ITR is injecting
1000's of packets into the network towards the ETR, with
classical MTU discovery the ITR will receive 1000's of
(anonymous) MTU discovery messages coming back from the
network, plus all of the packets are dropped. With SEAL,
the ITR will receive only a low-level stream of nonce-
protected MTU discovery messsages from the ETR (due to
rate-limiting) and most/all of the packets will still
get through.

This all reminds me that I have some overly-restrictive
text to remove from the SEAL spec regarding something
I have been calling the "D" bit...

Fred
fred.l.templin@boeing.com
  


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