[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNA] Re: LinkID v.s. Landmark Prefix
Erik
> ok
> But when taking that draft, what guarantees can you provide when you
> need to use a combination of linkID and CPL/completeRA?
> You end up with these combinations when
> 1. Some but not all routers on the link are new (i.e., are doing linkID)
> 2. The host moves to/from a link where not all routers on the link are new
> My gut feel is that there are many places where you have to defer to
> prefix comparisons, and if the prefix list you are comparing against is
> based on CPL, then you have the CPL problem of needing reliably 'link
> up' indications. But I haven't worked through all the cases to see if
> this is indeed the case, or whether we can do better.
If a host has 1) a linkid and 2) receives an RA with the prefix with I-bit set,
it can make a decision properly. So even in the above two cases, hosts
may satisfy these two conditions to properly check for link change without
resorting to prefix comparison.
But if either of two conditions is not satisfied, the host need to fall back
on CPL. In this case, we need reliable "Link UP" indication.
> So assume that linkA has R1 which uses linkID, and R2 which does not.
> linkB has R3 which does not implement linkID.
>
> A host H is on linkB and moves to linkA.
> Assume H receives the RA from R2 before the RA from R1. How can it tell
> whether it should assume that R2 is on the same link as R3, or not?
H should use CPL because it doesn't have any linkid prefix.
> When it receives the RA from R2, the only thing it can rely on is the
> link up notification (R3 and R3 do not advertise any common prefixes),
> since R2 and R3 could be two old routers that are on the same link and
> announce disjoint prefixes.
It's not clear to me. What can Link UP say to host H? It can't
say anything definite about whether link change happens or not.
> Thus link up is at least needed "temporarily"; once the RA from R1
> arrives (which includes all the prefixes for linkA I assume), then the
> host can tell that the prefixes it got from R3 are really not on the new
> link; but until that RA is receives the host needs to rely on the link up.
I still don't understand what kind of information can Link Up
can provide to H.
> Do you see a way around this?
Sorry, I still don't catch the problem clearly.
This is what I have in mind.
After H moves from LinkB to LinkA, it receives a hint for
a possible link change.
To make Link UP presence the smallest, I assume H used
the lack of RA from R3 as a hint. H missed 3 RAs from R3
and came to suspect a link change.
Because H doesn't have a linkid prefix, it needs to use CPL.
So H activates CPL module and sends an RS.
Because H relies on CPL in this case, it needs Link UP.
Best Regards
JinHyeock