RE: IETF multihoming powder: just add IPv6 and stir

["Bound, Jim" <Jim.Bound@hp.com>]

we need to capture what Noel listed here for sure.
/jim

> -----Original Message-----
> From: J. Noel Chiappa [mailto:jnc@ginger.lcs.mit.edu] 
> Sent: Sunday, May 04, 2003 4:00 PM
> To: multi6@ops.ietf.org
> Cc: jnc@ginger.lcs.mit.edu
> Subject: 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
> 
>