Subject: [RAM] Different approaches for different protocols

From: RJ Atkinson <[email-masked]>
Date: Wed, 19 Dec 2007 09:59:01 -0500

There seem to be one or two assumptions implicit in most of
the notes I see archived here and elsewhere on the R&A topic.

	A) We only really need to worry about a solution that
	works for the currently deployed IPv4 network, since
	that is the only network segment that is in near-term
	danger of hitting IDR scaling limits.

I think the above assumption would be incorrect, since IPv6
has the same architectural limitations as IPv4.  Both use
the same BGP-based methods for site-multihoming, which is
the main driver of RIB/FIB entropy at present according to
various papers in the published literature.

	B) We must use the same solution for both IPv4 and IPv6,
	since it is the same fundamental problem.

I think that assumption is also incorrect, since IPv6 does
have many more bits to work with than IPv4.  Purely as an
example, a solution that is part of the 8+8 family is quite
straight-forward to implement/deploy with IPv6 because the
IPv6 address already is conceptually split into two separate
Routing Prefix and Interface ID components.  However, for
IPv4, an 8+8-like solution is more challenging.  One might
use the existing IPv4 "address" as a locator/routing prefix
and then add separate Identifiers as an IPv4 option (workable
in theory, but not in reality because routers would roll over
and whimper like a puppy when trying to send every IPv4 packet
via slow-path CPU forwarding).

So I would suggest that folks think about IPv4 and IPv6 solution
approaches separately.  For example, while one might want one of
the existing proposal for IPv4 (partly for expediency and partly
because IPv4 has more constraints), one might well want a different
more architecturally fundamental change for IPv6 (partly because
the protocol is more flexible due to extra bits in the header
and partly because we have more time to study, prototype, and
design a more elegant solution).

Ran

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 Dec 2007 16:58:12 +0100

> design a more elegant solution).

I have no issue with that notion except to add that a solution could  
be appropriate for both versions of IP despite those differences.

However, over on the internet area mailinglist Bob Hinden made the  
case that new work on IPv4 should stop and we should focus on IPv6  
exclusively and only do the necessary maintenance for IPv4. Since  
apparently the routing situation isn't so dire and solutions aren't  
coming up so fast that we need to / can address the IPv4 situation  
before we run out of IPv4 addresses, this makes for a reasonable  
argument, in my opinion.

---

From: Tony Li <[email-masked]>
Date: Wed, 19 Dec 2007 09:27:59 -0800

On Dec 19, 2007, at 7:58 AM, Iljitsch van Beijnum wrote:

> exclusively and only do the necessary maintenance for IPv4.

I don't think we got rough consensus on that point.

Tony

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 19 Dec 2007 09:39:40 -0800

> -----Original Message-----
> From: Tony Li [mailto:[email-masked]] 
> Sent: Wednesday, December 19, 2007 9:28 AM
> To: Iljitsch van Beijnum
> Cc: RJ Atkinson; [email-masked]
> Subject: Re: [RAM] Different approaches for different protocols
> 
> 

I second that; IMHO, an IPv6 coexistence with IPv4 is
the most likely scenario moving forward.

Fred
[email-masked]

---

From: Scott Brim <[email-masked]>
Date: Wed, 19 Dec 2007 12:48:37 -0500

> 	danger of hitting IDR scaling limits.

I've only seen that idea in miscellaneous speculation.  I don't think
anyone seriously believes we will be able to avoid deploying IPv6.

> Routing Prefix and Interface ID components.  

Yes, the "split up the address" set of proposed solutions assume IPv6.

> approaches separately.  For example, while one might want one of the
> existing proposal for IPv4 (partly for expediency and partly because
> IPv4 has more constraints), one might well want a different more
> architecturally fundamental change for IPv6 (partly because the
> protocol is more flexible due to extra bits in the header and partly
> because we have more time to study, prototype, and design a more
> elegant solution).

To start with we need to evaluate whether an 8+8-style approach is
better than an map&encap approach *at all*, regardless of address
family.  If it is -- which is not clear by any means -- then that will
be the time to consider multiple routing modes.

However, in that case, if production IPv6 routing gets deployed, it
might be just as reasonable to let IPv4 routing consolidate into a
more PA-style mode and not bother doing anything new for it.

swb

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Dec 2007 12:32:52 -0800

Ran, first off, really good post.

> design a more elegant solution).

So let me propose something:

1) For IPv4, use LISP encapsulation as spec'ed in the -05 draft.
2) For IPv6, use header address translation (of the high-order 8-bytes),
    spec that out as GSE++.
3) Have both use the same mapping database infrastructure.

Comments?

If we added 2) to the LISP draft would people be happy with that?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Dec 2007 12:45:57 -0800

> be the time to consider multiple routing modes.

Scott, the comments I have heard in favor of using map&encap is that  
you maintain the original addresses which the host put in the header.  
You then can build ACLs in various middle-boxes that are based on  
those (inner) addresses that don't change. So for IPv4, I see value  
there.

But for IPv6, those middle boxes can setup ACLs based on the lower- 
order 8-bytes, which, as well as above, will not change. So doing  
address swaps on the high-order 8-bytes doesn't lose information like  
it does in IPv4.

I think a GSE++ approach could work very well. The only worry I have,  
with respect to how it is spec'ed out now is that an entire 128-bits  
is in the DNS. You don't really want to have locators in the DNS. You  
really want to decouple it.

So I would propose this:

1) Put A records in DNS for IPv6 hosts as ::<eid>, where <eid> is 8- 
bytes.

2) Have socket connections use the following addresses for tcb lookups:

	source = ::<source-eid>  dest = ::<dest-eid>

3) CE routers that participate in the mapping database, will do this:

         Make ::<source-eid> into <source-locator>::<source-eid>
	Make ::<dest-eid> into <dest-locator>::<source-eid>

     where:
	<source-locator> is the CE's IPv6 address out of the address block
                          from the provider it is attached to
         <dest-locator>   is the locator returned from a mapping  
database
                          lookup for <dest-id>

4) When the packet enters the destination site, the ETR will translate  
because
    the locator is it's own address, so it changes the source and  
destination
    locator bits to 0.

5) No host changes because the checksums are always based on non-zero  
bits in
    the EID field and 0 bits in the locator field.

We can do this with LISP-ALT as the mapping database mechanism.

Should we prototype this?  Comments?

Dino

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 19 Dec 2007 17:09:09 -0500

> If we added 2) to the LISP draft would people be happy with that?

Hmm.

Suggestions:

(A) I'd encourage keeping your concepts (1) and (2) separate,
in separate drafts and ideally with separate names, at least for now.

(B) Separately, modularity and clean architecture would argue for
keeping the mapping database structure separately specified
from any other bits of protocol design.

Rationale:

For my first suggestion (A), I'll note that approach (1) above
might be used for both IPv4 and IPv6 (at least in theory),
while approach (2) above isn't obviously applicable to IPv4.

For my second suggestion (B), one might use the currently proposed
LISP encapsulation, but with some alternative (not yet designed
or proposed) mapping database schema [or vice versa].  So keeping
things separate and modular seems beneficial all around for now.

My two cents.

Ran

---

From: Tony Li <[email-masked]>
Date: Wed, 19 Dec 2007 14:48:06 -0800

<RRG co-chair hat>

Might I again ask that we move this conversation back to the RRG  
mailing list?

</RRG co-chair hat>

Tony

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 19 Dec 2007 14:59:31 -0800

> Might I again ask that we move this conversation back to the RRG  

+1

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Dec 2007 17:35:16 -0800

> things separate and modular seems beneficial all around for now.

All good points, thanks.

Dino