RE: [DNA] Comments on draft-shim-dna-proactive-00.txt

[Zhigao Chen <zgchen@psl.com.sg>]

Hi Greg,

Thanks for the comments. Please find my further comment inline.

Regards,
Zhigao


<snip>
> > I get your point after realizing that you make a 
> distinction between 
> > trigger and hint in your draft. The gain of doing reachability test 
> > (with unicast RS/RA) in the case of weak hint could be less 
> signaling 
> > overhead, especially in the downlink, and less disruption to 
> > routers/hosts. Consider that RS/RA exchange between hosts 
> and routers 
> > is changed from one-multiple-multiple to one-one-one.
> 
> I agree that the issue of multiple response is one 
> which may be useful to check in the case 
> 
> Indeed, it may make sense for a router not to do
> any delay when sending an RA in response to unicast RS
> (if indeed it is suitable for a router to receive
> unicast RS (I need to read 2461 again)).
> 
I think it makes sense to send an RS in unicast in the case of
reachability test despite certain potential risk, e.g. router changes
its link-layer address (a rare event unlikely happening in such a short
HO interval, IMO). Mulitcast RS is more useful in router discovery. I
have a discussion on the RA random delay issue in the Section 7.1 of our
I-D (http://www.psl.com.sg/draft-chen-dnav6-apid-00.txt). The
Introduction section of the FastRA I-D
(http://www.join.uni-muenster.de/Dokumente/drafts/draft-mkhalil-ipv6-fas
tra-04.txt) also explains why the RA delay is used in RFC2461. I
strongly agree we should look into this issue in hopes to shorten the
DNA latency. 

> Depending on the network topology and technology, 
> the number of routers (which in many cases will be 
> small) may not matter, but the cost of multicast response
> may be large (uniform bandwidth consumption on all cells
> in the link).
> 
Good point. The impact is big on bandwidth-scarce wireless link.

> I'd like to think that the issue of whether a router responds 
> unicast is determined by the access network administrator. 
> This assumes that the admin knows best for their network. 
> Therefore, the host won't have control of whether the router 
> responds unicast or multicast.
> 
RFC 2461 neither precludes a host from sending a unicast RS nor a router
from receiving it. The unicast RS in fact passes the validity check in
the router. Section 6.2.6 of RFC2461 says "a router sends advertisements
in response to valid solicitations received on an advertising
interface". So it seems that an implementation should support unicast
RS/RA. As for administrative consideration, I would certainly like to
hear opinions from network admin/implementers on whether there will be
any reason of not processing a unicast RS. I think the feature should be
turned on once the operator realizes the benefit (provided we have
consensus) of doing so.

> Using RS/RA exchange in this case may not be one-one-one,
> but it may not matter.
> 
For reachability test, sending a multicast RS may be okay (RA delay will
be incurred though), but I am afraid multicast RA response will cause
confusion to other hosts. Suppose a host also sent an RS, which gets
dropped due to link failure, but it received the multicast RA triggered
by another host. In this case, the receipt of the RA after sending a RS
can not confirm the bi-directional reachability and the host could be
misled. Considering the NUD in NDv6 is done with unicast NS/NA, I think
it is difficult to perform reachability test of using multicast RA (with
R and S bits).

> Significantly, it may be worthwhile determining if there are 
> network topologies which make sense that don't have large 
> numbers of RA responders in short time frames (perhaps on the 
> slow responding router, a multicast RA can be scheduled at a 
> lower rate), and what happens to hosts when the advertisement 
> intervals for multiple routers on a link are skewed.
> 
Increasing the RA interval gives rise to the freshness issue of router
information. However, I agree that is interesting to look into.
 
> In this case, we could set up access networks where it is 
> always alright to send an RS to all-routers group, without 
> causing significant performance hits on wireless links.
> 
> Greg
> 
>