[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] Comments on DNA Solution: Link Identifier based approach
Dear Syam
Thanks for your kind and detailed feedback. Kindly find my in-line
comments.
> 1. The draft does not talk about the scenario where there exists a mix of
> modified and unmodified routers.
This is a very good point.
Though that case is not explicitly mentioned, I had that in mind
while design the protocol. That's why hosts make no decision
when receiving an RA having no linkid prefix. It will work even
in such an environment.
> 2. Section 3.1.
>
> ........
> A router, when it boots or is configured to act as a router (Sec
> 6.2.2 in RFC 2461 [1]), first sends an RS and waits for RAs to
> gather prefixes.
>
> ........
>
> Once that process is complete, the router will send RAs and
> respond to RSs, but not before that.
>
> These two statements are conflicting. Is the RS from routers is
> different from Hosts?
>
> According to one of your statements the routers do not respond to
> RSs unless the process of LinkID establishment is completed. So how
> Does initial RS/RA exchange happen between routers? Or am I missing
> some thing here.
My writing may not be clear. When a router is booted, after sending
3 RSs, i.e. waiting 12 secs, the router starts advertising its RAs, even if
no RA arrives.
> 3. Section 3.2
> ........
> In case the new prefix smaller than the current linkid prefix is
> advertised in LPIO, the router doesn't change the linkid prefix.
>
> Are you saying if a router receives a new smaller prefix in LPIO, then
> the router will not change the linkid? In other words routers change
> linkid
> if and only of they receive a new smaller prefix in PIO.
Yes.
> If this is true, then I think there will be some inconsistency in linkids
> being advertised by different routers on the link for some time
Yes.
> and slows
> down the linked establishment process.
Even it slows down the linkid convergence, it will not affect
DNA performance.
> Also, is there any reason for not to count LPIOs?
We thought it's more reliable to rely only on PIO information.
> 4. What if the life time of all the prefixes that are available falls
> below 3 hours? May be a rare case, but I am wondering if it is worth
> mentioning about this scenario.
Then this will not work and hosts need to fall back on CPL. But I
guess we can safely sweep this under the carpet. :-)
> 5. The host receives RA with different linkid prefix than the host
> is having, the host need to check for the complete prefix list against
> the host linkidprefix list. This is similar to CPL except that the host
> is
> not trying to learn about complete prefix list and now the host does this
> comparison only when it sees a different linkid.
Yes. Christian's comment on CPL showed me how similar linkid scheme is
to CPL.
There is one more difference as below.
In CPL, a host compares
the set of prefixes in the receiving RA with
its Completer Prefix List.
In linkid, a host compares
the set of prefixes in the receiving RA with
its LinkidPrefixList.
> 6. I am wondering what could be the disadvantage if we keep the
> Linkid prefix even if we see the new prefix that is smaller.
> I think it is better to keep the same linkid as far as possible.
> If the current Linkid prefix life time does not allow us to keep
> it as linkid prefix, then we can switch to next available smaller
> prefix.
> In this approach the new router that comes up, does not apply the
> algorithm to select a new linked, if it sees a linked (PIO/LPIO with
> 'I' flag set). The new router simply takes the received linked as
> the linked for the link.
>
> I think this way we avoid lot of processing and we will have smaller
> linkidprefix list on the host side.
In DT, we had a discussion w.r.t. the linkid convergence. We decided
that it would be much reliable if routers select their linkid prefix by
themselves without consulting what other routers advertise as a linkid
prefix.
We were afraid of ping-pong effect. Router 1 advertise a linkid prefix 1
and Router 2 a linkid prefix 2, then they keep changing their prefixes.
The above is a kind of "Phantom Menace" (:-)) without showing the
definite problem.
But a menace anyway and we try to avoid not only tangible problems
but also even the possibility of a problem.
So in the proposed scheme, routers would not take into consideration
the linkid prefix in the RA it receives from the other routers.
> 7. Section 3.4.3
>
> ........
>
> For example, assume a router R advertise the linkid prefix P1 and
> the
> second smallest prefix is P2.
>
> When the valid lifetime of P1 is 7 days, R wants to remove P1 from
> the link.
> If R immediately advertises an RA with 1) P1 with zero lifetime and
> 2) P2 with I-bit set, hosts may treat this as a link change, because
> they would discard P1 entirely when seeing it with zero lifetime.
>
> In this example, is the prefix P2 is also being advertised when P1
> is the linkid prefix? If yes, then a host receives a P1 with zero life
> time,
> it can easily find out that it is still on the same link but the prefix
> P1
> is not valid any more.
In the linkid scheme, to check for link change hosts use only the
prefixes in LinkidPrefixList.
> I can see one problem: If Host receives another RA from another router
> with P1 as the linkid, then host think that it has moved, as the host
> discarded the P1 completely because of the earlier RA.
Right.
> 8. And also I am wondering, why we cannot use the longest valid prefix time
> as
> the selector for the linkid prefix. I think this is better because, this
> way
> linkid will be valid for more time.
In fact, we can use any algorithm which will give a definite prefix from
the set of prefixes on the link.
The problem with 'the longest valid prefix time' is that there may be
multiple prefixes having the same valid prefix time. Then we need
an additional decision scheme.
Thanks in advance for your kind consideration.
Best Regards
JinHyeock