[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: review of draft-ietf-shim6-failure-detection-03.txt
El 24/06/2006, a las 13:59, Iljitsch van Beijnum escribió:
On 22-jun-2006, at 16:59, marcelo bagnulo braun wrote:
This draft works per-context exclusively. So if there are 2, 5 or 10
contexts between two hosts, this means 2, 5 or 10 times the amount
of work is done.
i agree that this would be a nice feature. the problem with this is
how do you identify the peer in such a way that you can probe all the
existing contexts.
Have a look at the revision of my reachability detection draft:
http://www.muada.com/drafts/draft-van-beijnum-shim6-reach-detect-00.txt
Note that this is an update of draft-ietf-shim6-reach-detect-01.txt
and it's not yet posted by the secretariat.
will provide feedback in a separate email...
The other option would be to use a single probe/keepalive for all the
contexts between two peers. In order to do that we need a mean to
identify the peer so that the receiver of the packet can identify all
the contexts corresponding to the same hosts and apply the received
packet to all the contexts.
Indeed.
BAsically this would introduce the notion of endpoint in the shim
context/protocol (which is not present today), since today the
granularity is ulid pairs (as oposed to endpoint pairs)
Not necessarily, read my draft.
this would be a considerable change in the protocol i guess, but may
be explored if people deem it relevant.
It makes the protocol a bit more complex, but it does allow it to be
used by many different protocols at the same time.
As a general comment, i am kind of worried about the complexity of
the resulting protocol, including shim protoc and the failure
detection protocol and i would really preffer to try to simplify the
protocol rather than making it more complex, even if this means
loosing some optimization for some cases.
I suppose the case where there are multiple contexts between two host
won't be that common that it's worth too much effort to deal with it.
But if other protocols also need this, then it would be MUCH better to
have a single code base that's shared by all of them rather than have
essentially the same thing pop up in different places.
I am concerned about having a complex protocol that may become error
prone (we already have feedback expressing this concern BTW)
I hate complexity as much as the next IETFer, but leaving the last 10%
out just because it's simpler is generally not a good solution.
may agree with that
but my comment was more a observation rather than a wish... i mean imho
we have already reached the reasonable complexity level for this
protocol (shim and faildet) and i would rather remove things rather
than add new ones...
However, it's important that there is fate sharing between the
reachability protocol and the user protocol (shim in our case). I
think this can be solved by having the quick reachability
verification stuff (= FBD) encapsulated in the user protocol, but
let the full path exploration be a protocol of its own or live under
ICMPv6 or some such.
not sure why do you think this is needed. Defining the protocol
messages in a way that they can be included in the shim6 header as
well as in the mobility header or the hip header would be good enough
to allow using the failure detection protocol in other protocols....
what am i missing?
See the discussion above, and the need for fate sharing between the
reachability protocol and the "user" protocol. If we want the
reachability detection to be shared by different users, then it can
happen that one protocol is filtered and another isn't. So we probably
want the reachability detection to be independent of the "user"
protocols and then when the reachability protocol says that something
is reachable, the user protocol does a quick check using its own
protocol number to be sure it actually works.
yes, this is true
but otoh, the nice thing of carrying all the packets of a given
protocol wihtin the same header is that you know that either all
packets of the protocol are filtered or none of the them are. If you
use different header for different packets of the protocol, it may be
the case that e.g. the establishment packets make it but the keepalive
packets are filtered, which is probably much worse than if all packets
are filtered.
That is why, when i think about reusage of the faildet protocol i am
more thinking about reusing functionality rather than the packets
themselves.
I mean, i am not thinking about using the same packet exchange to
verify reachability for mip and for shim, but just using the same
protocol and packet format for both of them. The benefit comes form
that there is no need to design multiple protocols, not form not
needing to send multiple packets
regards, marcelo