Hi Jinmei.
Yes, we've already discussed this sort of thing, probably several
times.
I was assuming this, but probably browsed the list too little
diligently. I'm sorry; my mistake.
Now going to specific points...
- its initial Router Solicitation after interface (re-)
initialization (D1) [RFC 2461bis] - joining the solicited-nodes
multicast address after interface (re-) initialization (D2) [RFC
2462bis] - joining the solicited-nodes multicast address before
starting DAD triggered on a multicast RA (D3) [RFC 2462bis]
Hmm..., regarding D2, it seems we can apply the same approach as D1
in 2461bis.
As far as I see, we should either do that, or RFC 2461bis' relaxation on
D1 for MNs would be useless in most situations.
Regarding D3, I'm not sure if we can make it for 2462bis, since this
event is not (necessarily) triggered by moving a link, and it may be
difficult to find a prudent condition like the one described in
2461bis for D1. Recall that our first priority in 2462bis is to
avoid disruption for existing implementations, not to provide mobile
nodes an easy way out.
Besides, even if we remove D3, the mobile node will still face a
delay in this case, because the responding router will impose a
random delay before sending an RA.
Well, here is the scenario I am thinking of: A MN uses unsolicited
RAs---neither RSs, nor link-layer triggers---to detect IP-attachment
changes. Assuming that routers send their RAs every 50ms on average,
which is what RFC 3775 allows them to do, this movement-detection
strategy works better than sending RSs. The reason is the random delay
for solicited RAs, as you say. Even if the MN would use L2 triggers, it
would still have to send an RS and await the random RA-delay in order to
find out the new prefix(es).
So, RFC 3775's frequent (unsolicited) RAs can be leveraged for movement
detection quite nicely. But when it comes to configuring the new
address, the MN ends up having to wait for D2 or D3 to send the MLD
Report. In other words, eliminating D1 turns out to be useless as long
as D2 and D3 are still there.
I guess my point is that, conceptually, RFCs 246[12]bis impose ONE
SINGLE delay for the first transmitted message whenever there is a
danger for contention. If an RS is the first transmitted message, the
RS needs to wait (D1). If a MLD Report is the first, it will be delayed
(D2). Same with the NS for DAD after a multicast RA (D3). Once the MN
has awaited one of these delays, it does no longer need to await the others.
Contention may happen due to simultaneous boot-up of multiple hosts, or
due to synchronized DAD after a multicast RA. Unfortunately, the
original wording paraphrasing these conditions encompasses the condition
of a handover, which is unintentional because handovers usually don't
cause contention.
The goal with RFCs 246[12]bis seems to be a relaxation for the handover
condition. But this goal has yet to be met: If one removes D1 for MNs,
namely D1, that doesn't help unless one either removes D2 and D3 as
well, or has a particular approach in mind with which a MN could get
away with only one or two delays (which, or each of which, would have to
be eliminated then).
I know the intent is to make RFCs 246[12]bis as conservative as
possible, and to move any optimization to separate documents. In fact,
I do like that idea. But as things stand, either would RFCs 246[12]bis
prevent certain optimizations like frequent RAs a la RFC 3775, or such
optimizations would have to explicitly revoke delays defined in RFC
246[12]bis. However, if RFCs 246[12]bis had the kind of relaxation for
D2 and D3 as it already has for D1, then optimizations could just refer
to this relaxation, and there would be no conflict.
The challenge would therefore be to paraphrase the condition in which
the relaxation could be applied, i.e., a wording that describes a
handover, but does not include any other condition.
Having said the things above, I hope I could strengthen the case for
relaxing both D2 and D3 for MNs---similar to how it's already done for D1.
So, I'm negative about removing D3 from rfc2462bis. Is this decision
okay for you?
Well, see above... ;)
Let's put it this way: I would like to see the documents handle both D2
and D3 in the way they do with D1. But that's just my personal opinion...
Assuming the answer is yes for now, do we still want to remove D2? As
you pointed out, just removing D2 may not necessarily help mobile
nodes, so the change would still be incomplete.
Right.
Considering the current status of the document (already passed an
IESG last call, and now waiting for IESG approval), I'm personally
reluctant to introduce the change at this stage. But if many others
also want the change (and no one objects to that), I'll try to revise
the draft once again.
Yes, sorry for raising this so late.
And thanks for your detailed response!
Regards to all,
- Christian
--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/
JINMEI Tatuya wrote:
On Fri, 27 May 2005 19:20:51 +0200, Christian Vogt
<[EMAIL PROTECTED]> said:
one comment concerning RFCs 2461bis and 2462bis. The documents
define that a node must delay...
I'd like to begin with a general note...
To make this story short: Even at the risk of suggesting something
that has been discussed on the IPv6 mailing list before, I propose
to remove delays (D2) and (D3) in RFC 2462bis for mobile nodes. I
know there is an issue with contention when a multicast RA triggers
multiple MLD Reports. The question is how likely that is, and how
much more often delays (D2) and (D3) would be disruptive to mobile
nodes.
Yes, we've already discussed this sort of thing, probably several
times. The basic consensus was we would not introduce any changes
that can affect non-mobile nodes just for helping mobile nodes, at
least within the scope of 2461bis/2462bis, due to the "conservative"
nature of the recycling process. See, for example, discussions at
58th IETF at: http://www.ietf.org/proceedings/03nov/137.htm
In this sense, we'd not justify a logic like "disruption without
random delay should be very rare and eliminating the delay would help
mobile nodes very much. So let's introduce the optimization". What
we need to justify the change is a proof that the change never
affects existing (non mobile in this case) implementations, not a
doubt about the probability of disruption.
In fact, the change about "D1" in rfc2461bis was introduced with very
careful wording for not disrupting existing implementations. Also,
we should note that other "radical" changes like changing RA
frequency (to every 50ms) or removing random delay before sending RAs
were rejected, mainly based on the "conservative" principle.
Note that this policy is limited to 2461bis/2462bis. We can still
discuss, implement, or even standardize any new ideas *as a separate
work item*. And, indeed, the mobile IPv6 specification introduces a
new RA frequency, and optimistic DAD is now going to become a PS.
Someday, when we have enough operational experience on the new ideas,
those may be incorporated into the base specification. But clearly
it's not now.
I hope this explanation helps avoid having the "101th" discussion
about a new change proposal into 246[12]bis based on the "but isn't
it unlikely?" type of logic.
Now going to specific points...
- its initial Router Solicitation after interface (re-)
initialization (D1) [RFC 2461bis] - joining the solicited-nodes
multicast address after interface (re-) initialization (D2) [RFC
2462bis] - joining the solicited-nodes multicast address before
starting DAD triggered on a multicast RA (D3) [RFC 2462bis]
Hmm..., regarding D2, it seems we can apply the same approach as D1
in 2461bis.
Regarding D3, I'm not sure if we can make it for 2462bis, since this
event is not (necessarily) triggered by moving a link, and it may be
difficult to find a prudent condition like the one described in
2461bis for D1. Recall that our first priority in 2462bis is to
avoid disruption for existing implementations, not to provide mobile
nodes an easy way out.
Besides, even if we remove D3, the mobile node will still face a
delay in this case, because the responding router will impose a
random delay before sending an RA.
So, I'm negative about removing D3 from rfc2462bis. Is this decision
okay for you?
Assuming the answer is yes for now, do we still want to remove D2?
As you pointed out, just removing D2 may not necessarily help mobile
nodes, so the change would still be incomplete. Considering the
current status of the document (already passed an IESG last call, and
now waiting for IESG approval), I'm personally reluctant to
introduce the change at this stage. But if many others also want the
change (and no one objects to that), I'll try to revise the draft
once again.
JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center,
Toshiba Corp. [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
