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

Re: IETF multihoming powder: just add IPv6 and stir



    > From: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>

    >> It might be good to get the word out that multi6 wants to recharter
    >> and work on the identifier/locator thing aka GSE++ aka 6+10. Then we
    >> can see if the pro mob is larger than the anti mob at the meeting.

    > I am not sure I want to say that we recharter to the GSE++ model.
    > ...
    > they want to present and make their case for their solution and against
    > a GSE based approach

When people start talking loosely about "GSE" I get nervous, because there
are a number of (to me) independent architectural and engineering points that
are involved in what I think of as "GSE".

(Indeed, there might be a danger that "GSE" means different things to
different people, but that's a *separate* problem from the one that I'm
talking about here.)

Anyway, I think we need to:

- keep each of these separate things clear in our mind - although of course a
	particular proposed solution will consist of a (hopefully :-)
	carefully selected set of detailed answers, one for each point.
- because if one proves problematic, that *doesn't* mean the other
	(independent) ideas are unworkable.

As I see them, the points in "GSE" are:


1 - The basic approach to multi-homing being use of more than one locator
	(I think we are approaching rough consensus on this for any
	solution, not just GSE, but list it for completeness)
2 - Separation of location and identity, using two separate and distinct
	labels, one for each function
	(Again, I think we are approaching rough consensus on this for
	any solution, but list it for completeness)
3 - Use of IPv6 addresses (or parts of them) as the namespaces for both of
	those two classes of identifiers
4 - Details of the identifier; two obvious options:
	A - Use of two complete IPv6 addresses, one for each kind of
	identifier, sometimes called "16+16"
	B - One IPv6 address, divided into two fields (the original being
	"8+8", but I now see mention of "6+10")
5 - Replacement of part or all of the location identifier by entities other
	than the endpoints of the end-end communication
	A - replacement involving the destination locator only
	B - replacement involving the source and destination locators

Some combinations have repercussions; e.g. 5 plus 4B means that either you
have to modify TCP6 (which I think we decided was unfeasible), or the
original contents of the location identifier part of the IPv6 address(es)
have to be placed back in the packet before the endpoint processes it.

Anyway, I hope this sort of framework for thinking about them is useful.

	Noel