[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DNA] High-level overview of DNA, take 2



>DNAv4 uses ARP. Shouldn't we think about using an NS?

Personally, I think it makes sense.  In fact, I believe that DNAv4 
implementers are already considering this, if they haven't implemented it 
already.

>One issue that seems to be carrying a lot of weight on the DNAv6 side
>is that with RS/RAs, one (only) learns the router's link-local and
>link-layer addresses. But these two together are insufficient to
>uniquely identify a link, since both can be used on different links at
>the same time.

Right.   DNAv4 does not use link-local addresses, so this problem does not 
arise.

>Why not allow inclusion of a landmark option in an NS/NA? One benefit
>of an NS is that we presumably don't have to delay sending one, and
>the responder doesn't delay in responding. So this can be very fast.

Right.  Not only can the packets be sent without delay, but sending them via 
unicast also reduces delays due to frame loss on links such as 802.11 which 
do not retransmit multicast packets (from STA to AP) at the link layer.

>However, this has the disadvantage that routers have to listen to
>other RAs and (effectively) do a proxy advertisement for prefixes it
>itself is not advertising. I have some fairly strong qualms about that
>approach...

Yes, I also have reservations about it.

>On the other hand, a lower overhead mechanism would be to be able to
>ask "are you the same router on link Foo that I was talking to
>previously?" If the answer is yes, one can conclude that one is on the
>same link as earlier.

Yup.

>I'm also a bit worried that one time DNA will get used a lot is at,
>say, IETFs where the network is barely functioning. That seems like
>the wrong time to have a bunch of nodes invoke DNA at the same time
>and all send out multicast RSs...

Yes.  As part of the DNAv4 work, we did an analysis and discovered that 
sending multicast packets was *much* more likely to result in a network 
meltdown than using unicast.  This was not only because of the multicasting, 
but also because of the link layer interactions, such as much lower rates, 
lack of link layer retransmission, etc.

In fact, the effects are so strong that sending multiple unicast frames in 
parallel is more efficient than a single multicast.