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