Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix

[Erik Nordmark <erik.nordmark@sun.com>]

JinHyeock Choi wrote:

> We can't avoid a temporary flapping for the related set, the set of
> all prefixes
> on a link. 

Just to make it sure we are all talking about the same thing, by 
"flapping" I assume we mean the following:

When the set of prefixes on a link changes, e.g., a prefix is being 
added or a prefix is being removed, there is the possibility that a host 
see more than one change (see things flapping back and forth) until the 
routers have been synchronized.
For instance, if the prefix set is {P1, P2} and P3 is added, one would 
ideally have the host see {P1, P2} and then see {P1, P2, P3}, but when 
RAs come from different routers, there might be a small window when the 
host sees RAs vary in a sequence like {P1, P2}, {P1, P2, P3}, {P1, P2}, 
{P1, P2, P3}. This is due to the third RA (with {P1, P2}) coming from a 
router which hadn't seen P3 yet.

If there is no packet loss, the window during which this can happen is 
very small (basically the propagation delay of the RA which carries the 
new prefix from one router to another). With packet loss, the worst case 
window is the time it takes to successfully retransmit the RA so that 
the other routers see it.

> In linkid scheme, one item (linkid prefix) of the set matters for DNA
> performance.
> So we designed a few special schemes for the linkid prefix so that
> linkid prefix(es)
> won't give incorrect information about a link change, even under
> temporary flapping.

Yes, but linkid still has flapping issues; you just have a technique to 
avoid this resulting in an incorrect result. (In the case of linkid the 
flapping effects the linkID which each routers picks. Thus if P3 was the 
numerically smallest prefix then the flapping in the prefix set would 
result in flapping in the linkID prefix the host sees.) Handling this 
requires some additional logic in linkID.

> But for Complete RA or Landmark, IMO, we need to adopt similar schemes such 
> as "Linkid Prefix List" or "Old linkid advertising rule" to all
> prefixes because we
> don't know which prefix will affect DNA decision. 

I don't think so. CompleteRA is basically the same as CPL in this 
respect, in that the prefix sets are compared to see whether they are 
disjoint. In the above example, there is overlap between {P1, P2} and 
{P1, P2, P3} hence the host would correctly conclude that it didn't move.

Landmark is basically an optimization of completeRA, with a fallback to 
completeRA/CPL prefix comparisons when there was no landmark response, 
or no DNA capable router, respectively. Thus the completeRA/CPL 
observation holds. This even takes care of the case when a host picks up 
{P1, P2, P3}, selects P3 as its landmark, gets a new link up 
notification, sends a RS, and get a response with "landmark P3 = NO, 
PIO={P1, P2}, from a router which hasn't yet seen P3, since the host 
would compare the prefix sets in that case as well. (I'm not sure that 
is in the I-D, but I think it needs to be in the I-D to handle the 
analogous case of moving to a link with no DNA routers.)

> If all routers agree on the selection algorithm, it's almost automatical
> to select the prefix among the set of prefixes. That's why I chose the
> simplest selection scheme, picking the smallest prefix. 

Sure. But my point is that a router needs to be prepared to receive a RA 
where some other router, due to not having seen an RA, or being broken, 
is claiming that some other prefix is the linkID. That's some added 
complexity.

> I thought it simpler to make routers agree on the same selection
> scheme but would like to hear your scheme when developed. 

I think it would be isomorphic to linkid; just a different way of
thinking about the problem. (BTW: "simple" and "distributed agreement"
don't belong together in the same sentence. :-)

    Erik