>>>>> 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 --------------------------------------------------------------------
