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

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

>-----Original Message-----
>From: Dino Farinacci [mailto:dino@cisco.com] 
>Sent: Tuesday, July 22, 2008 5:28 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
>
>>>> 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.
>
>What I'm saying is that I want the nonce easily acceptable, 
>and if you  
>do that, you'll need to add the header length.
>
>>>> 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.
>
>No, it's not trivial.

I have it coded in Linux and I am satisfied with the
performance characteristics. There are a lot more
heavy-weight aspects of processing IP packets than
this, and it constitutes only a small number of
instructions. 

> And where do I get the other 16-bits in 
>the IPv6  
>case? There is no ID field in the IPv6 header.

You don't; you continue to use the current format in
Section 5.2 of lisp-08, and you use IPv6 path MTU
discovery. This is suboptimal wrt to IPv4 using SEAL
in a number of ways, however (see below).

>The point I'm making is that you are putting extra mechanism in for  
>really no gain. So why would an implementor want to do this.

There is gain; see seal-22, Section 12. That section
fails to mention the additional benefit that path MTU
feedback comes *only* from the ETE and not from an
anonymous network middlebox or an anonymous hacker
that could be sending fake messages from anywhere
in the Internet.

>>>> 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.
>
>I am not arguing this point anymore. We've been over this before.

But, you can't just sweep it under the rug and hope it
never comes back to bite you. 1500 bytes has become the
de facto "Internet cell size", and weeding out all of the
deployed gear would be a task on about the same scale as
replacing IPv4. You also can't prevent an operator who
might not like what you're doing "accidentally"
misconfiguring a link MTU.

>> 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.
>
>We need to find out when paths have small MTUs and not large ones. If  
>they are large and we default to thinking they are large we 
>don't need  
>to do anything.

What you need is 1) a mechanism that discovers the actual path
MTU from the ITE->ETE w/o dependence on a fragile network-based
ICMP mechansim, and 2) a mechanism that ensures delivery of
packets up to 2KB even if the path MTU is smaller than 2KB.
That is what SEAL does.

(BTW, I mis-spoke on the 8KB example above; packets no
larger than 2KB will still make it through if they incur IPv4
fragmentation, but packets larger than 2KB will not. That would
require too much IPv4 reassembly, and would make for inconsistent
handling of large packets that would confuse an end system.)

>The only value of a new mechanism is to tell us when the path MTU is  
>1500 bytes.

No; there is more value than just that; getting 1500 byte
packets through when the path MTU is marginal is a major
benefit. Forgot to mention that SEAL addresses the issues
raised in RFC4459 ("MTU and Fragmentation Issues with
In-the-Network Tunneling").

Fred
fred.l.templin@boeing.com
 
>
>Dino
>