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?
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.
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? 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 implementationsFred,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/sealFor 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 oftunneling packets. If the LISP tunneling specifications change, we'lladapt 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". DinoOlivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium