[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNA] Re: LinkID v.s. Landmark Prefix
JinHyeock Choi wrote:
>>Given that we have this, then we have the choice to assume this
>>notification even for the DNA solution, as a way to optimize things.
>>Alternatively, we can try to make the DNA solution be more robust again
>>a missing 'link up' notification.
>
>
> I took the latter approach. (that may be the road less traveled. :-))
> Allow me to explain my reasoning too.
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.
> For example, with Link UP notification, Linkid scheme may work
> to detect link change from non-supporting link to supporting one
> as below.
>
> Assume a host is at a non-supporting link. Then it doesn't have
> a linkid prefix. When it moves to a supporting link, it will see a
> new linkid.
>
> The host may assume a link change upon receiving this new linkid.
> But the current draft mandates that the host doesn't make any
> decision becuase there is the other possibility that the host is at
> the same link but a router on the link becomes a DNA router and
> starts advertising the linkid.
>
> I contemplated the idea to distinguish the above two cases with
> Link UP indication but gave it up because I thought the simplicity
> and less assumption is better.
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?
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.
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.
Do you see a way around this?
Erik