[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: about draft-ietf-shim6-proto-02.txt
marcelo bagnulo braun wrote:
Thanks for the comments. I've applied all of them unless explicitly
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
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.
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
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.
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.
"should stop" isn't correct?