Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling

From: [email-masked] (Noel Chiappa)
Date: Tue, 15 Sep 2009 11:09:57 -0400 (EDT)

> From: Magnus Westerlund <[email-masked]>

    > At the same time I do understand the gain of not having to do the
    > checksum.

Doing UDP checksums on all packets is just a total non-starter. On some
boxes, it's incredibly expensive:

  http://www.ietf.org/mail-archive/web/lisp/current/msg00773.html

and on others it's impossible:

  http://www.ietf.org/mail-archive/web/lisp/current/msg00770.html

It may be that there's just no choice for IPv6 that works for all parties
(ISPs, routers, hosts).

	Noel

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 15 Sep 2009 11:23:29 -0400

> It may be that there's just no choice for IPv6 that works for all  

I actually think of the parties as ISPs, higher-end routers and lower- 
end routers.  Many lower-end routers (such as CPE equipment, home  
gateways, small business gateways) are implemented using commodity or  
semi-customer hardware and general-purpose operating systems.  I don't  
picture hosts implementing LISP in the short-to-mid term, although  
there may be advantages to keeping that option open for the future.

My understanding of the ISP requirements is that LISP has to work with  
LAG/ECMP equipment, not (specifically) that we have to use UDP.  Is  
that correct?

If so, we could explore other options for IPv6 to meet the LAG/ECMP  
requirements, such as using different IPv6 IIDs for different flows.

I'd also like to get a better understanding of the state of the  
current IPv6 LAG/ECMP deployment, including how/if those systems could  
be upgraded to use the IPv6 flow label as part of the flow- 
identification.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 15 Sep 2009 11:25:24 -0400

On Sep 15, 2009, at 11:23 AM, Margaret Wasserman wrote:
>
> I actually think of the parties as ISPs, higher-end routers and  
> lower-end routers.  Many lower-end routers (such as CPE equipment,  
> home gateways, small business gateways) are implemented using  
> commodity or semi-customer hardware and general-purpose operating  
> systems.

s/semi-customer/semi-custom

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 15 Sep 2009 11:45:44 -0400

> It may be that there's just no choice for IPv6 that works for all  

Just to make my personal interests clear in this discussion, there is  
something I think you should all know...

Sam Hartman and I are currently working on a LISP implementation (with  
his company, Painless Security) that is designed to be portable to  
several general-purpose and embedded operating systems.  Our  
implementation is targeted at exactly the sort of lower-end router  
(home gateway, CPE equipment or small business gateway) that I have
been discussing.  It currently uses the IP stack and other facilities  
provided by the operating systems on which it runs.

So, in addition to my interest in producing a good LISP protocol that  
will benefit the Internet, I have some personal interest in the  
outcome of this discussion.

I can also say, rather authoritatively, that there is at least one  
LISP implementation that is targeted at these environments.

Margaret

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Sep 2009 11:55:58 -0400

This is a very reasonable question in this context.
Unfortunately, the answers are not clear cut.

I have been able to find several vendors of relevant devices that could 
upgrade.
I have also found at least one vendor where an upgrade to handle 
ECMP/LAG on the basis of IPv6 flow spec would be hard (or even not 
possible in nay meaningful time frame).
Several vendors have not answered me.

But counting vendors probably does not tell us much.
If we count boxes, a LOT of boxes would be very hard to upgrade.

Yours,
Joel

Margaret Wasserman wrote:
...
> I'd also like to get a better understanding of the state of the current 
> IPv6 LAG/ECMP deployment, including how/if those systems could be 
> upgraded to use the IPv6 flow label as part of the flow-identification.
> 
> Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 15 Sep 2009 12:05:55 -0700

Also note, if we depend on core routers to upgrade, LISP deployment  
will probably take a decade.

There are tons of routers out there that do 5-tuple hashes on both an  
IPv4 and IPv6 headers to load-split traffic over ether-channels, port- 
channels, and multi-link GRE tunnels.

We have two choices if we don't want to upgrade core routers, TCP or  
UDP. If we use GRE, L2TP, or even IPsec, the core routers will get  
greater than 10 gig flows (from the LAG router's point of view) that  
can't be put on one member of a LAG. So you will cut the bandwidth of  
these boxes by 1/nth where n is the number of members of a LAG.

IMHO, if we do this, LISP is a non-starter. If we do this, all the  
benefit of LISP working "over-the-top" is gone.

Dino

On Sep 15, 2009, at 8:55 AM, Joel M. Halpern wrote:

> I have been able to find several vendors of relevant devices that  
> could upgrade.
>> current IPv6 LAG/ECMP deployment, including how/if those systems  
>> could be upgraded to use the IPv6 flow label as part of the flow- 
>> identification.
>> Margaret
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 15 Sep 2009 15:10:23 -0400

On Sep 15, 2009, at 3:05 PM, Dino Farinacci wrote:

> There are tons of routers out there that do 5-tuple hashes on both  
> an IPv4 and IPv6 headers to load-split traffic over ether-channels,  
> port-channels, and multi-link GRE tunnels.

What do they do for non-UDP/TCP traffic?  Do they load balance based  
on the three-tuple (2 addresses and a protocol/next-header value)?

Margaret

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Sep 2009 12:40:06 -0700

Margaret,

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Tuesday, September 15, 2009 8:46 AM
> To: Noel Chiappa
> Cc: [email-masked]; [email-masked]
> Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1MTU
Handling
> provided by the operating systems on which it runs.

Operation within these sorts of use cases brings on a much
broader set of considerations, including autoconfiguration,
enterprise virtual partitioning, provider-independent and
provider-aggregated addressing, {host,router}-to-{host,router}
tunneling, MTU diversity, mobile ad-hoc networking, etc. And,
we already have technologies that fit these spaces, namely
ISATAP, VET, and SEAL.

As you know, ISATAP is already widely deployed. We also
have it implemented in Linux in addition to the commercial
implementations that already exist. We also have early
linux implementations of VET and SEAL. RANGER tells how
it all fits together, and RANGERS outlines applicability
to the various use cases.

To help understand the positioning a bit better, VET is
also known as "ISATAP Version 2".

Fred
[email-masked]