Subject: RE: IETF multihoming powder: just add IPv6 and stir

From: "Bound, Jim" <[email-masked]>
Date: Sun, 11 May 2003 05:02:09 -0400

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

> -----Original Message-----
> From: J. Noel Chiappa [mailto:[email-masked]] 
> Sent: Sunday, May 04, 2003 4:00 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: IETF multihoming powder: just add IPv6 and stir
> 
> 
>     > From: Kurt Erik Lindqvist <[email-masked]>
> 
>     >> 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
> 
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 11 May 2003 11:21:01 +0200

> we need to capture what Noel listed here for sure.

At the same time we have to be careful that we don't go through this 
list and pick the option we like best for each item. It's pretty clear 
that any solution will include some parts that aren't great. The only 
way to judge the "not great" part is by evaluating the solution as a 
whole and compare it to other fleshed out solutions.