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

[Tony Li <tli@cisco.com>]

> > I thought that ALT carried aggregated EID information.  How does  
> > the correspondent host get EID-specific information?
>
> Site-based EID-prefixes are injected into the ALT topology. ALT  
> routers can further aggregate into the core. A source site sends a  
> data packet or Map-Request to an specific EID that follows the  
> route on the ALT topology to get to the ETR at the destination site  
> which returns a Map-Reply with the a locator-set for the site-based  
> EID-prefix.


Again leaving you at prefix granularity.  ;-(


> 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?


> The more specific bits of an EID will be lost, but the mapping data  
> is not lost because it is returned in the Map-Reply.


I get that, but if you have EID-specific mapping data, doesn't it get  
lost in preference to a EID prefix reply?

> > Just in case I've confused anyone, I side with Einstein when it  
> > comes to complexity.  ;-)
>
> So using one mapping system would be better then.


Not what I meant.  Einstein said ~as simple as possible, but no  
simpler~.  One, integrated mapping system that has multiple modes may  
be the right answer.  Pushes to some nodes, pulls from others, etc....


> > > 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?

Tony


--
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