[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RRG] Re: [RAM] Different approaches for different protocols



On 2007-12-20 15:46, Dino Farinacci wrote:

On 2007-12-20 09:32, Dino Farinacci wrote:
Ran, first off, really good post.
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).
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++.

As far as I can tell, that whole line of thinking was thrown out
of the boat when the RIRs and ISPs declined to accept the recommendation
that *all* site prefixes should be /48 or shorter. I don't see any way
to revive a (6+2)+8 type of proposal now, unless you can figure out
how to deal with variable length routing goop.

Actually might be a good thing. Those 2 bytes will be useful (read: necessary) for site subnetting. So maybe we should call it 6+2+8 where the 6 is global-locator, the 2 is a site-based locator, and the 8 is an ID.

Dino

P.S. The 8+8 proposal didn't clearly tell me how sites wouldn't have to subnet renumber when they gave the Routing Goop back. Again, need the decoupling.

Sure, but that was covered in the 2nd ("GSE") version
draft-ietf-ipngwg-gseaddr-00.txt which quickly replaced the
original 8+8 draft.

The problem for sites arises if different ISPs give them different
prefix lengths --- that will really mess things up at the subnet
level.

On 2007-12-20 15:54, Tony Li wrote:


We've done variable length before...  ;-)

In any case, if we go down this path, we are making enough other changes (e.g., shifting away from PI prefixes) that we shouldn't feel overly constrained. We could decide, for example, to reserve some address space for 6+10 and then migrate into that...

Sure. There's plenty of space to do that. But don't forget the
other big problem of 8+8 or GSE -- the transport layer has to be
fixed up too, unless you can arrange for all goops to have the
same checksum ;-)

    Brian

--
to unsubscribe send a message to rrg-request@psg.com 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