Re: [DNA] Comments on DNA Solution: Link Identifier based approach

[Subba Reddy <subbareddy@samsung.com>]

Hi JinHyeock Choi,

Please find my comments in-line.

> 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.


I think it is useful to look into the RA sent by the unmodified router,
to see if it is advertising the linkid prefix (obviously no I bit is
available)
so that host can make a decision that it is still on the same link.

>
> > 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.
>

Take a case where more than one router boots up, if the routers are not
replying
for RSs (not sending RAs) during initial 12 seconds, then they will
configure different
linkids and it may take some more time to converge.

If the link is coming up, routers chosing the linkid based on the prefixes
it is advertising
is same as waiting for 12 seconds other than the delay in the later case
(because routers
will not come to know each others prefixes)

> > 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.
>


> > 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.


Even though one more decision is required, if we select linkid
based on life time, then linkids may not change frequently
because of life time expiry.

Thanks & Regards,
Subba Reddy