TWiki > DNA > DNASolution1 > DNASoln1Issue012	TWiki webs: Main | TWiki | Know | Sandbox
	DNA . { History of Changes | DNA Documents | Search | Go }

Network renumbering - guidelines for deployment?

What does the draft need to say about network renumbering?

Recommendations about not flash renumbering?
Explanation of effects of flash renumbering? 

Discussion

Jim

I agree with Eric's recommendation that we ought to discuss the possible
negative impact.

We might also talk to Greg about putting something in the BCP.

            jak

Erik

Brett Pentland wrote:

> What does the draft need to say about network renumbering?
>
> Recommendations about not flash renumbering?
> Explanation of effects of flash renumbering?


How about saying that
The protocol works well when a there is graceful renumbering (i.e., lifetimes are allowed to decrement down to zero), or when there is flash renumbering but the prefix isn't reassigned to a different link until the expiry of its original valid timer has passed. Handling flash renumbering and reassignment to a different link sooner is TBD.

Then we can also say

Should a prefix be withdrawn from link A and reassigned to link B before its original valid lifetime on link A has passed, then if a host moves from link A to link B at the same time, the host might incorrectly assume that is it still on the same link. This means that if there were additional prefixes assigned to link A, the host would continue to use them until their expiration (based on the preferred/valid lifetimes that was last heard.)

It is possible to define rules for the host to track the last time a prefix was heard before some L2 movement, and forcefully remove it in less than the valid lifetime (which is 30 days by default in RFC 2461), but this is TBD.

   Erik 

Brett

There wasn't much discussion on this one, but I think it's
more or less resolved, pending production of some suitable text:

Brett Pentland wrote:

> What does the draft need to say about network renumbering?
>
> Recommendations about not flash renumbering?
> Explanation of effects of flash renumbering?


No recommendations about flash renumbering, but there should be
some advice about the consequences.  Erik provided a good basis
for the text to go in:

<quote>
How about saying that

The protocol works well when a there is graceful renumbering (i.e., lifetimes are allowed to decrement down to zero), or when there is flash renumbering but the prefix isn't reassigned to a different link until the expiry of its original valid timer has passed. Handling flash renumbering and reassignment to a different link sooner is TBD.

Then we can also say

Should a prefix be withdrawn from link A and reassigned to link B before its original valid lifetime on link A has passed, then if a host moves from link A to link B at the same time, the host might incorrectly assume that is it still on the same link. This means that if there were additional prefixes assigned to link A, the host would continue to use them until their expiration (based on the preferred/valid lifetimes that was last heard.)

It is possible to define rules for the host to track the last time a prefix was heard before some L2 movement, and forcefully remove it in less than the valid lifetime (which is 30 days by default in RFC 2461), but this is TBD.
</quote>

JinHyeock Choi

Dear Brett


>>> > Correct me wrong, but in ComplteRA or Landmark, there is no
>>> > mechanism which ensures that always such a linking (or overlapping)
>>> > prefix exists.
>
>> 
>> That's almost the definition of Complete RA.  All routers should be
>> advertising the same set of prefixes so that pretty much ensures
>> overlap.  The only way for there not to be is for a router which has
>> no learned prefixes (ie. all of the prefixes it is advertising are
>> explicitly configured on it) to instantly stop advertising those
>> prefixes and start advertising a new set.  It's trivial to add a rule
>> to say don't do that.


ok. Kindly add that rule and then we may resume this discussion. 


>>> > Assume a host having two prefix A and B, and making one address with
>>> > A and the other with B. Assume prefix A goes through prefix renumbering
>>> > and early reassignment and the host follows it. Then it will not perceive
>>> > that it can't no longer use the address with prefix B:.
>
>> 
>> True, but LinkID doesn't prevent that either.  Both methods need to
>> manage that through the imposition of rules for renumbering, and the
>> setting of timeouts on DNA information.


No, Linkid has a rule to prevent "Renumbering and Early reassignment." 


>>> > Linkid draft sets the rule to prevent such a case. So I may say that
>>> > Linkid is safe from flash renumbering and early reassignment, unless
>>> > there is a human error, (from which no scheme can be safe 100 %.)  .
>
>> 
>> And those same rules apply equally well to Landmark/CompleteRA.


Maybe. Then kindly also write down those rules in the draft. I will be 
happy if you also adopt the similar rule for Landmark/ CompleteRA. 

Best Regards

JinHyeock

Brett Pentland

JinHyeock Choi wrote:

> Dear Brett
>
>
>>> Correct me wrong, but in ComplteRA or Landmark, there is no
>>> mechanism which ensures that always such a linking (or overlapping)
>>> prefix exists.
>>
>>
>> That's almost the definition of Complete RA.  All routers should be
>> advertising the same set of prefixes so that pretty much ensures
>> overlap.  The only way for there not to be is for a router which has
>> no learned prefixes (ie. all of the prefixes it is advertising are
>> explicitly configured on it) to instantly stop advertising those
>> prefixes and start advertising a new set.  It's trivial to add a rule
>> to say don't do that.
>
>
>
> ok. Kindly add that rule and then we may resume this discussion. 


I'll add this to the discussion on issue 12 which was about this point.
We had more or less decided to just describe the consequences of
flash reassignment.  It's trivial to say "don't reassign a prefix to
a new link before it's old lifetime has expired" and that solves this
problem, but maybe that's too strict a requirement (or maybe it's not).
I'm not sure how this fits in with DHCPv6 prefix delegation, for
example.  It sounds like this needs further investigation.

Brett. 

-- Main.BrettPentland - 18 Apr 2005

Back to DNA Solution1 Issue Tracker