And the router changes to do a different type of longest match?And in the ETR case, the forwarding algorithm is different as well. Because you have to tell your FIB to match on high-order bits only to determine the packet needs to be translated.
I'm not sure I see the need for different longest matches. After all, this is a translation box and you're allowed to know which interfaces are 'inside' and which are 'outside'.
Packets flowing inside to outside are pretty straightforward: look up the destination id (possibly cached), add destination routing goop, perform normal longest match lookup resulting in an outbound interface, add source routing goop dependent on the outbound interface.
Packets flowing outside to inside are somewhat trickier: you know the routing goop associated with the input interface and thus the routing goop on the destination, so erase it. Now, from a reverse lookup on the source address (again, possibly cached), determine the length of the source routing goop. Erase that. Now on your internal routing table, perform a normal longest match lookup.
Did I miss something?
GSE "appears" to be a good idea but the devil is in the details. Could be completely different for host-based GSE.
Host based GSE would be fine by me, but I think that it would garner a great deal of grief, in exactly the same ways that shim6 did. Specifically, the thought of having to manage multiple addresses at each and every host is NOT something that we automated in v6. Also, Dave Thaler might provide us with some entertainment at the mere mention of host changes. ;-)
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