[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] draft-ietf-dna-cpl-02.txt
Thomas Narten wrote:
> rereading section 4.5: Receiving valid Router Advertisements,
>
> I'm (generally) fine with the first part of this section. I.e., it
> says that when a host receives the first RA (after a link up event):
>
> 1) if it contains a prefix in the CCL, assume no link change.
>
> 2) if it contains a prefix in retained Candidate Link Object, assume
> host has moved back to that link.
>
> The interesting case is where one receives an RA containing only
> prefixes that one has not seen before. It is this case that makes use
> of the "complete" state. I.e., if the CCL is complete, one assumes
> that learning a new prefix means an immediate move. But if the CCL is
> not complete, one doesn't assume one has moved (yet). Specifically:
>
> [...]
>
> Could you clarify for me how the above relates to normal 2461/2462
> processing? I.e., I would assume that the new prefix should be
> configured on the link immediately. Is this the case?
We tried to make it clear that the host needs to separately track the
prefixes it received before the link up and those that were received
after, so that no matter what it does on the reception on the RA it can
do the right thing should it later determine that it indeed moved to a
different link.
Thus an implementation could immediately add the prefix to the current
set of prefixes. But then should it determine that it did move to a
different link it needs to remove that prefix from the old candidate
link object, and only use that prefix in the new candidate link object.
Alternatively, an implementation could defer doing anything with the new
prefix until DNA has completed. Then, if the host didn't move to a new
link, it would add the prefix to the current list of prefixes. And if it
did move to a different link it would know to only use the new prefix as
the initial prefix list for that link.
> Also, I'm not sure it's worth the complexity of waiting another 4
> seconds to gather additional RAs before declaring a move.
Yes, but this is an unfortunate side effect of the generality of how
prefixes can be advertised in RFC 2461/62. We know who to blame for that
generality ;-)
> Or maybe I don't understand what it means to "declare a move" and what
> impact that has on the addresses configured on the interface. This
> goes back to my message yesterday asking what processing we are
> assuming happens upon a "link down" event.
>
> Given that as far as we know, most RAs include complete information,
> why go to so much trouble to handle the case where this is not the
> case, and where the cached information is "incomplete" (which also is
> probably not the normal case), etc.
FWIW this observation was what lead to one of the early proposals by
JinHyeock for how to make DNA better - just including a "this RA is
complete" bit in the Router Advertisement.
> I agree that having a Complete Prefix List would be good, in the sense
> that upon receipt of an RA, one is more likely to make a correct
> determination about whether one has rejoined an existing link.
>
> However, the current document formalizes this too much, including
> algorithms that are used to (in some sense) "declare" when one has a
> complete list as opposed to maybe not having a complete list. I'm just
> not convinced (yet) that this complexity has sufficient benefit in
> practice.
The notion is really more probabilistic than "know for sure" vs. "don't
know yet". But in terms of the resulting behavior, there is a point
where the host behaves as if it knows all the prefixes for a link, hence
the "declare" aspect seemed to help when describing the behavior. If it
doesn't help, we can certainly revisit the description.
> So, it takes 4 seconds to complete DNA? I thought the whole point was
> for DNA to complete quickly. Recall, using normal 2461/2462 in _MOST_
> cases, a single RS will trigger the transmission of RAs from _all_
> routers, and this will complete within .5 seconds. Thus, having DNA
> operate for 4 seconds seems to miss the bigger picture.
If we want reasonably robust and fast DNA, we do need some changes in
the routers behavior.
If we had a time machine and could go back and mandate in RFC 2461/62
that the list of prefixes each router advertises on the link MUST be
identical, and that all prefixes for the link MUST fit in a single 1280
byte RA, then we could assume that every RA is complete.
But given that 2461/62 doesn't mandate that, we sort of have to deal
with what's might be out there.
Erik