[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IETF multihoming powder: just add IPv6 and stir
we need to capture what Noel listed here for sure.
> -----Original Message-----
> From: J. Noel Chiappa [mailto:email@example.com]
> Sent: Sunday, May 04, 2003 4:00 PM
> To: firstname.lastname@example.org
> Cc: email@example.com
> Subject: Re: IETF multihoming powder: just add IPv6 and stir
> > From: Kurt Erik Lindqvist <firstname.lastname@example.org>
> >> 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.