Subject: [MBONED] Fwd: [RRG] The use of UDP in LISP

From: Marshall Eubanks <[email-masked]>
Date: Thu, 13 Dec 2007 13:41:10 -0500

This applies to the AMT use of UDP in IPv6 as well. My personal  
feeling is that
RFC2460 will need to be changed.

Regards
Marshall

Begin forwarded message:

> From: Lars Eggert <[email-masked]>
> Date: December 13, 2007 8:33:45 AM EST
> To: ext Dino Farinacci <[email-masked]>
> Cc: Iljitsch van Beijnum <[email-masked]>, Routing Research  
> Group list <[email-masked]>
> Subject: Re: [RRG] The use of UDP in LISP
>
> On 2007-12-10, at 19:17, ext Dino Farinacci wrote:
>>> Could you elaborate a bit, please? It may be the jetlag, but I  
>>> can't follow.
>>
>> Now with UDP-Lite, which we did not have to do with checksum-0- 
>> based-UDP:
>>
>> o Check on another field to determine how many bytes we have to  
>> checksum.
>> o Build a pseudo-header which prepends the checksummed data.
>
> Thanks for elaborating. Yes, there is some extra work. But assuming  
> LISP and other UDP tunnels will limit the UDP-Lite checksum  
> coverage to the minimum (i.e., just the header), things become very  
> lightweight. (But yes, not as lightweight as not doing any  
> checksumming.)
>
> As long as LISP is a research effort, it is very free in following  
> the published RFCs. But as soon as we're starting to talk about  
> standardization, it is important that LISP follow the RFCs that  
> define the behavior of the protocols that it uses. (After all,  
> you'd want people to follow the MUST and SHOULDs in any future LISP  
> RFCs, right?)
>
> That pretty much leaves these options on how to go forward:
>
>   * use UDP with checksums
>   * use UDP-Lite with minimal checksum coverage
>   * push to update RFC2460, then use UDP with no checksums
>   * use a different protocol than UDP for tunneling
>
> I have no preference among those four.
>
> Lars
>
> --
> to unsubscribe send a message to [email-masked] with the
> word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

_______________________________________________
MBONED mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mboned

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 13 Dec 2007 13:41:10 -0500

Regards
Marshall

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 13 Dec 2007 10:49:20 -0800

Cross posting to MBONED.

> LISP and other UDP tunnels will limit the UDP-Lite checksum coverage  
> to the minimum (i.e., just the header), things become very  

Light weight but not light weight enough. Still a non-starter for  
product development.

> define the behavior of the protocols that it uses. (After all, you'd  
> want people to follow the MUST and SHOULDs in any future LISP RFCs,  
> right?)

And we have to make standards practical for vendors to implement or  
vendors sway from the standard and create defacto standards. Please  
don't take this lightly. This is really important to make protocols  
implementable and not too expensive where non-standard alternatives  
are sought.

The pressing point, as Marshall points out, is AMT. This issue is  
holding AMT from going forward on standards track. We need a  
resolution soon.

>  * use a different protocol than UDP for tunneling

1, 2, and 4 are non-starters. The only option is 3 IMO.

> I have no preference among those four.

That's good. Now who is going to update the spec?

I provided text which Marshall has forwarded, who is going to insert  
it? The IPv6 working group?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 13 Dec 2007 10:49:20 -0800

Cross posting to MBONED.

Dino

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 13 Dec 2007 14:02:12 -0500

On Dec 13, 2007, at 1:49 PM, Dino Farinacci wrote:

> Cross posting to MBONED.
>
>> Thanks for elaborating. Yes, there is some extra work. But  
>> assuming LISP and other UDP tunnels will limit the UDP-Lite  
>> checksum coverage to the minimum (i.e., just the header), things  
>> become very lightweight. (But yes, not as lightweight as not doing  
>> any checksumming.)
>
>> you'd want people to follow the MUST and SHOULDs in any future  
>> LISP RFCs, right?)
>
> I provided text which Marshall has forwarded, who is going to  
> insert it? The IPv6 working
> group?

I think it would be up to us (those who are interested) to prepare a  
new draft (not a bis, but just an addition), and submit it  
(presumably) to IPv6 Maintenance (6man).

I would like to get more input from people making high volume routers  
about these points before that.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 13 Dec 2007 14:02:12 -0500

Regards
Marshall

---

From: Lars Eggert <[email-masked]>
Date: Fri, 14 Dec 2007 10:05:00 +0200

Hi,

> 1, 2, and 4 are non-starters. The only option is 3 IMO.

I wouldn't want to eliminate 2 or 4 immediately.

IMO, 4 is an option, because UDP was explicitly designed as an end-to- 
end protocol, i.e., not something that routers would need to implement  
on the line card. If I correctly remember the discussions around  
removing the IPv6 checksum and making transport checksums mandatory,  
the desire to remove the IPv6 checksum was exactly to simplify router  
processing, and shift the checksumming burden to the end hosts.

The issue we're running in now is that UDP's apparent attractiveness  
as a router tunneling scheme conflicts with these earlier design  
decisions. The reasons I have heard for why UDP is the right choice  
for this are middlebox traversal and load-balancing. The former  
shouldn't be an issue for LISP, because we're talking about router- 
router tunnels. (AMT may be different.) The second can be achieved  
through other means for another tunneling protocol.

Further, 2 is IMO an option, because I find it personally completely  
acceptable that a major revamp of the routing architecture of the  
Internet will require minor modifications to line cards. I know that  
I'll get strong disagreement for this position, but I always felt that  
the statement that LISP wouldn't require hardware modifications was  
optimistic, and made at a time when the full consequences of the  
proposal weren't understood

> it? The IPv6 working group?

A short draft needs to be written that updates RFC2460, and it will  
need to go through 6man and IESG approval. Your text is a good  
starting point, but the real work will be the consensus building  
required to make it go forward.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 14 Dec 2007 10:05:00 +0200

Hi,

Lars