Re: Flash renumbering (was:Re: [DNA] DNA proposal issue 19 -was[IssueX]LinkID v.s. LandmarkPrefix)

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

Erik Nordmark wrote:

> Sathya Narayanan wrote:
>
>> It can be argued that the semantics of landmark exchange is not to
>> imply all those prefixes are on the link - if the host did a landmark
>> question using 'P2', then a 'yes' answer just means P2 is on the link
>> (link3 in this case). Does that make sense?
>
>
> I'm not sure it helps.
> If P2 was retracted from link1 either silently (e.g., a single router
> was advertising P2, and that router was moved or decommissioned as
> part of the flash renumbering), or a few RAs were sent with valid
> lifetime=0, and, due to packet loss, some routers on link1 did not
> hear those RAs, then we'd still have an inconsistent state; a landmark
> query for P2 would return "yes" even though the prefix isn't assigned
> to link1 any more. This will persist for the maximum time the learned
> prefixes are retained by a router on link1 (90 minutes).
>
Agreed !!! But ...

>> The negative side is that when a host is on a link with P4, P5, P6,
>> sends a landmark question with P6 and gets a 'yes' answer, the host
>> cannot say anything about the availability of P4 or P5. The host will
>> have to do separate landmark questions for each of them or hope for a
>> complete RA to be received.
>
>
> 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)

> That sounds like fairly severe restrictions, especially given the low
> probability of
>  - flash renumbering
>  - immediate reassignment of the prefix to a different link, and
>  - a host moving from the old link to the new link at the same time as
>    the flash renumbering and reassignment

Even without agreeing to the severe restriction, I agree with the
low-probability of this event and that it may not make sense to design
solution that avoids this possibility. My aim was just to start thinking
about a mechanism to address this ...

> Thus I'm more favorable to an approach which tries to recover from the
> problem in a reasonable way once it has occurred, but without
> impacting the performance of the main DNA operation.
>
> A possible way to do this is exemplified by this sequence:
>  - the host sees P1 and P2 on the link
>  - the host gets a link up notification; sends a RS with a landmark
> question for P2
>  - receives a landmark response with P2=yes
>  - later receives a periodic RA with some prefixes (P2, P3 in the
> example)
>  - 90 minutes after the link up it observes that it has not yet heard
> any RA with a subset of the prefixes it heard before the link up (P1
> in the example); this is suspicious.

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?

> In this case it could
>     - drop those prefixes; basically assume that it has moves to a
> link with (P2, P3)
>     - try to reverify whether P1 is on the link by sending a RS with
> P1 as the landmark.
>
> The last thing would not need to be performed for each prefix; only
> one prefix which was heard before the link up but has not been heard
> after the link up should be sufficient.

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.

-Sathya