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

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



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.


I'm getting confused here. Are you admitting that you could support host-specific mappings?

I mentioned at the last RRG where we can verify a new ITR for a given moved EID by creating /32 state in the CN's ETR. We had that working in our prototype of doing LISP mobility.

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.


Isn't that worse?  Changing every application in the known universe?

No, only the ones that might need session survivability. Which I think are very few and far between.

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