[DNA] Re: Flash renumbering

[James Kempf <Kempf@docomolabs-usa.com>]

Erik,

I agree with using absence of link up to detect renumbering. Also, I prefer
#1, unless one of the other solutions can be done without introducing
additional complexity into the protocol.

            jak

----- Original Message -----
From: "Erik Nordmark" <erik.nordmark@sun.com>
To: "Sathya Narayanan" <sathya@research.panasonic.com>
Cc: "JinHyeock Choi" <jinchoe@gmail.com>; "Brett Pentland"
<brett.pentland@eng.monash.edu.au>; <greg.daley@eng.monash.edu.au>; "Syam
Madanapalli" <smadanapalli@gmail.com>; "James Kempf"
<Kempf@docomolabs-usa.com>; "Dna" <dna@eng.monash.edu.au>
Sent: Tuesday, July 26, 2005 6:31 AM
Subject: Re: Flash renumbering


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