[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix
Erik
> 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.
I use flapping in more general case as below.
When the set of prefixes on a link changes,
there is the possibility of temporary lack of synchronization, i.e.
the nodes on the link (such as routers and hosts)
may have different set of prefixes (on the link) for the time being.
For example, if the prefix set is {P1, P2} and P3 is added, one would
ideally have all the nodes on the link have the prefix set {P1, P2, P3}
instantly. But due to packet loss, it is possible that one router has the
prefix set {P1, P2} and the other router has {P1, P2, P3} for some time.
If hosts check for link change with prefix information, such a lack of
(temporary) synchronization may cause a false link identity detection.
> 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.
Exactly. I found it extremely difficult to abolishing flapping completely.
So I took the approach to make hosts to make the right decision under
mild flapping.
> > 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.)
ok. Allow me to clarify this
In Landmark/ CompleteRA,
when a host receives a solicited RA,
the host check for link change with both
1) Landmark option with YES/NO bit and
2) prefixes in the RA.
If the (solicited) RA carries 1) NO answer and 2) a known prefix,
the host would not assume a link change.
(So in effect, "known prefix" would overrule "NO".)
Is this right?
> > 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.
Routers don't pay attention what other routers advertise as a linkid.
They generate the complete prefix set and pick the linkid prefix for
themselves. You recommended this approach.
> > 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. :-)
ok and agree. :-)
Best Regards
JinHyeock