Re: [DNA] Re: Flash renumbering

[Sathya Narayanan <sathya@research.panasonic.com>]

Based on Thomas's comments, I am looking at the sections 5.1.10, 5.1.11 
in -04 and section 12 (RENUMBERING CONSIDERATIONS) in RFC 2461. This is 
related to flash renumbering which we discussed within the DT and on the 
mailing list long time ago.

Section 12 in RFC 2461 doesn't have any explicit statements on what is 
allowed and what is not - the discussion is about deprecating a prefix 
by advertising it with shorter and shorter lifetime and advertising the 
prefix with zero lifetime until its original valid lifetime expires.

Now, I am quoting from Erik's email below:
"I guess we need to first agree what goals we are trying to satisfy. I 
see three possible levels:
1. do nothing special for flash renumbering and immediate reassignment 
(other than telling network admin to not immediately reassign prefixes)
2. do something so that a host can recover, but it might take a while 
(e.g., 90 minutes)
3. handle it without any delay "

The text in 5.1.10 itself can be improved - but I want to make sure that 
our goal is to do 3, i.e., even though it is recommended that network 
adminstrators NOT do flash renumbering, we still recommend behavior for 
the routers to "handle it without any delay".

Please comment.

- Sathya

Erik Nordmark wrote:

> Sathya Narayanan wrote:
>
>>> Based on the comment above, we would also have to forbid the routers
>>> from using learned prefixes as part of the DNA solution.
>>
>>
>>
>> ... why? The problems becomes worse with wrong state for upto 7 days
>> only with reassignment. The above comment is only about flash
>> renumbering which will be corrected within 90 minutes and is not that
>> bad (A)
>
>
> I guess we need to first agree what goals we are trying to satisfy. I 
> see three possible levels:
> 1. do nothing special for flash renumbering and immediate reassignment 
> (other than telling network admin to not immediately reassign prefixes)
> 2. do something so that a host can recover, but it might take a while 
> (e.g., 90 minutes)
> 3. handle it without any delay
>
> Which goal are you attempting for? (And we should ask the same of the 
> whole WG.)
>
> I was assuming you were trying for #3, since in some cases you'd 
> recover in zero time. But in order to accomplish #3  we'd also have to 
> remove any notion of using learned prefixes in the routers.
>
> And if we want to reach #2 then I don't think we need to affect the 
> efficiency of the normal DNA operations, but instead have some slower 
> sanity check which can recover.
>
>> By suggesting that this is suspicious, we are suggesting that the
>> prefix-lifetime being greater than 90 minutes is not necessarily right -
>> in effect putting an upper limit on the prefix-lifetime and overruling
>> 2461. Right? Is it OK to do that?
>
>
> Good question. I wish I had a firm answer. We have an inherent 
> conflict between RFC 2461, which was designed we long default 
> lifetimes just so that a host wouldn't throw away its addresses and 
> prefixes just because a router died for a short time.
>
> But our need to quickly and reliably detect movement, if we combine it 
> with the renumbering and reassignment issue, is in conflict. We can't 
> solve both.
>
> Hence the best I think we can do is to use the absence of a 'link up' 
> as a way to tell the host to stay in the RFC 2461/62 "stability is 
> important" mode.
>
> Note that your suggestion to use a RS to reverify each prefix has the 
> same issue as triggering a sanity check after 90 minutes, since it 
> would also remove a prefix from aggressively than 2461 if the 
> advertising router is temporarily down.
>
>> In support of my argument above marked (A), this solution doesn't
>> address the flash renumbering problem - only flash renumbering with
>> early reassignment. But, I do agree that this simpler defensive 
>> scheme can handle the low-probability occurance of flash-renumbering 
>> with early
>> reassignment.
>
>
> Flash renumbering without any reassignment wouldn't cause any 
> additional problems for DNA, would it? I think it is only an 
> issue/feature of RFC 2461/62.
>
>   Erik
>