RE: Identifier/locator recap

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

> > Could you write up your technical idea without a lot of man 
> hours to 
> > describe and why it solves the multihome problem.
> 
> I'm not Tony, but:
> 
> Traditional multihoming as is done in IPv4 will not scale.
> 
> An alternative is to give each host in a multihomed site an 
> address for each ISP the site is connected to. When (the link 
> to) one ISP fails, the communciation is diverted over the 
> other ISP. However, current transport protocols are unable to 
> jump to new addresses in mid-session. Solution: separate the 
> identifier and locator functions of the IP address. Transport 
> protocols then use the identifier, which doesn't change 
> during the lifetime of the session, while IP uses the 
> locator, which may be changed at any time in order to route 
> around broken parts of the network.

I think the MIPv6 MHH is on the right track and it is an excellent piece
of technical work.  I have read it twice and I believe it could work.

But I also like the note to all in GAPI which states we have two sets of
space. THe unicast space and the MHH space.  I for now like that
thinking model.

> 
> A few things that need to be addressed to make this happen:
> 
> - Locators must always be present in each packet. But what about the
>   identifiers? Do we include them in each packet (= tunneling) or are
>   they implied?

If we can make them implied its an extra condition check for routers and
hosts but will make the overall architecture less heavy and less to
manage.  I believe in overload though it is complex to implement not
impossible.

> 
> - How do we discover identifiers and/or locators?

Still parsing the PI space MHAP.  But that is on the right road.

> 
> - How to we authenticate the relationship between locators and
>   identifiers?
> 
> There is also the question of what makes good identifiers. 
> HIP uses the fingerprint of a cryptographic key. MHAP uses 
> provider-independent IPv6 addresses that aren't visible in 
> the global routing table. I myself have suggested to use 
> FQDNs as the first choice.

I suggest not being dependent on crypto anything is wise it implies PKI
to the solution and I fear that is a non-starter?

> 
> Note that there seems consensus here that we shouldn't try to 
> revive GSE or 8+8: some kind of "16+16" would be much easier 
> to deploy.

No comment.  I agree with Tony lets get the Macro done.

I do think we need to work on the Model so it is clear to all and then
we can do the architecture and then apply implementation discussion?

/jim
> 
> Iljitsch
> 
>