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

[Dino Farinacci <dino@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.  ;-(

Can be very coarse 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?

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.

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

Right, but it's not clear that the way we present them as different  
mapping systems, cannot be integrated into one protocol. So don't rule  
out this option.

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

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