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

Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures





On Jan 27, 2008, at 2:28 AM, Dino Farinacci wrote:

Can be very coarse prefix granularity.


Even worse.  ;-(

No not worse. Good when it can be coarse. And when it can't because of locator-set differences, then a site's allocation because more specific.

If you move and you don't need session survivability you *can* change both. And to make that movement compatible with existing trends and deployed sites, you get a DHCP address (you as a host) that will be used as an EID. You (as a host) don't have locators per say, but the site you are at does (the IP addresses of the ETRs).

If you move and want session survivability, the EID must move with the host (and the host stack has to retain the address when the interface goes down, this is not common). This is the case where the RLOCs change for a single EID (versus the EID-prefix because the home site doesn't move, NEMO aside for a moment).

Why do we need both options?

It is not very clear an end-user needs TCP-connection survivability across moves but would require sessions (moving watching, phone calls, etc) to have survivability.

So I guess I"m not seeing anything that's TCP specific here. If you can provide survivability for one transport, isn't it going to fall out for other transports?

If you do it at the session layer, then you don't care what transport you use so you don't care if the transport can support it.

A node *can* roam and preserve its original IP address, but we should not put that in the underlying routing. It can be done in connection
signaling a la MIPv6.

Fair, but unless we're willing to open the transports to actually add that to connection signaling, that's going to prove challenging. So far, all of the feedback on host changes (transport layer or otherwise) is all negative.

If the original IP address *stays* with the host, it continues to use it. So there are no hot changes.

Then how do you change the connection signaling?

I don't understand the question.


So we're postulating that we accomplish some level of mobility by connection level signaling. This is certainly doable. However, you seem to claim that you can do this connection level signaling without involving host changes. I'm trying to understand how this is possible. Implementing MIPv6 does seem like a host change.

I think you can do it with application changes and not protocol stack changes.

Dino


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg