Re: about draft-ietf-shim6-proto-02.txt

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

marcelo bagnulo braun wrote:

Thanks for the comments. I've applied all of them unless explicitly 
indicated below.


> 4.3  Overview of Shim Control Messages
>
>    There is a No Context error message defined, when a control or
>    payload packet arrives and there is no matching context state at the
>    receiver.  When such a message is received, it will result in the
>    destruction of the shim context and a re-establishment.
>
>
> I guess that this is under discussion, but just as a remainder...
> I guess that the current idea would be not to discard but to try to 
> recover the lost context, right?
> ( i mean reestablishment without previous discard)

Yep; Context Error will go away and be replaced with R1bis.

> 6.1  Conceptual Data Structures
>
> I don't know if timers involved should be included in here, but in case 
> they should, i guess that at least the time used to tear down the 
> context should be described here.
> An option for this would be the time elapsed since the last data or 
> control packet associated to the context was exchanged.
> The timers involved in context establishment may also need to be 
> included here.

I've added some vague words on this.

> In addition, i guess that the multiple timers involved in path 
> exploration and failure detection would be needed, but probably those 
> are better to be described in the failure detection protocol document.

Yes.

> 7.2  Concurrent context establishment
>
>    If a host has received an I1 and sent an R1, then a ULP can trigger
>    it to send an I1 message itself, since it doesn't retain any state
>    when receiving the I1 message.  Thus while one end is sending an I1
>    the other is sending an I2.
>
> I am not sure in this case why it is useful that the initiator replies 
> to the I1 sent by the responder with an R2... as i see it, the previous 
> I2 message should get to the responder, making him to issue a R2 back. 

Perhaps I'm misunderstanding, and "initiator" isn't well-defined when 
both ends are initiating at about the same time.

But AFAICT, if a host receives an I1 that matches an existing context, 
it needs to respond with an R2. This is needed e.g., when the first R2 
is dropped and the peer goes back to retransmitting the I1.

> The R2 sent by the initiator will have no effect in the responder as i 
> understand it... wouldn't make sense to remove this R2 then? Perhaps it 
> would be better to reply with an I2 instead of an R2?
> I mean, that the initiator replies to the I1 of the responder by 
> repeating the I2 instead of sending a new R2... this would keep the 
> roles simpler imho, since the initiator would always send I messages and 
> the responder R messages...

Does the above make things more clear? I've added similar text to the draft.

> 7.4  Context confusion
>
> I think that the context confusion scenarios may be even more complex 
> than the cases described.

Yes, if the locator sets are not known as part of the context 
establishment, then things are harder.

But if sufficient things are exchanged during context establishment, 
then the host can tell whether the peer is the same at the latest when
receiving R2/I2.
The locators aren't needed AFAICT, the CGA PDS should be sufficient.

Does that work?

> 7.5  Sending I1 messages
>
>    If, after several retransmissions, there is no response, then most
>    likely the peer does not implement the shim6 protocol, or there could
>    be a firewall that blocks the protocol.
>
> Or that a failure has just affected the path between the ulids... right?
> would it make sense to try to recover here? i.e. using alternative 
> locator pairs for exchanging the initial exchange packets and carrying 
> different ULID pair as an option?

The shim would only know the ULID pair during the context establishment, 
so I don't think it can currently try anything different.
It is true that if/when we have the the "super-API" that allows 
applications to specify the two IPv6 address sets and ask the shim to 
setup a context, then things would be different.
But I think we can defer this until that point in time.

> Editorial
>
> Abstract
>
>    The hosts in a site which has multiple
>    provider allocated IPv6 address prefixes, will use the shim6 protocol
>    specified in this document to setup state with peer hosts, so that
>    the state can later be used to failover to a different locator pair,
>    should the original one stop working.
>
> s/stop/stops

"should stop" isn't correct?

   Erik