Re: shim header in every shimmed packet

[Erik Nordmark <erik.nordmark@sun.com>]

Iljitsch van Beijnum wrote:

> Right. I haven't thought much about the issues around locator  updating 
> because I was kind of assuming this wouldn't happen in the  presense of 
> HBA.

But it can with CGA.

> > But the current design also uses uncoordinated teardown of the  
> > context state, which can result in one end not having any context  
> > state any more, even though the peer might send packets using that  
> > context.
> > With the context tag in the packets that need to be rewritten by  the 
> > receiver, we can detect this condition. But your 'single bit'  scheme 
> > would seem to need some different way to detect this missing  state. 
> > Any ideas on how to do this?
>
>
> That would be something that we explore in the "how to safely  suppress 
> the shim header after rewriting" document but in the case  where the 
> locator sets for the different ULIDs are disjoint this  isn't an issue: 
> the receiver without state that receives a shimmed  packet without a 
> shim header will know this because the packet is  addressed at a 
> locator-only address. It can then either send back a  shim error or an 
> ICMP error.

Yes, but I thought we wanted the capability to do this in other cases 
than the disjoint case (I've never been a fan of each host that has N 
ULIDs needing to create (N*N - N) extra locators).

It seems to me that we can't make sure the we got the handling of the 
"bit" correct until we know how the sender and receiver will use this 
capability.

   Erik