RE: Comments on draft-yourtchenko-colitti-nd-reduce-multicast

[Andrew Yourtchenko <[e-mail]>]

On Fri, 21 Feb 2014, Hemant Singh (shemant) wrote:

> ErikN has commented on section 4.7.   I have additional comments.   ND 
>as defined in RFC 4861 has no means to specify a prefix as off-link. 
>Thus the L-bit equals zero is not a valid means to signal an off-link 
>prefix to SLAAC hosts.  ND can only specify an ipv6 destination as 
>off-link.   Here is the reason.  The RA sets the A-bit to have hosts use 
>SLAAC for ipv6 address assignment.  The router also sets the L-bit to 
>zero in the RA.   After address assignment the host has an incomplete 
>entry in the Neighbor Cache for a packet destination where the packet 
>destination matches the host address up to 64 bits.  Due to the A-bit

hmm I'd be really interested to see which host implementation behaves this 
way. I explicitly tested Linux, MacOS X, iOS - none of them do. I glanced 
over the shoulder at the behavior of the Windows box - and it was behaving 
in a similar fashion which does not match what you describe.


>set, all addresses within the /64 assigned to the host are on-link.  Does

RFC4861 says this:

    on-link     - an address that is assigned to an interface on a
                  specified link.  A node considers an address to be on-
                  link if:

                     - it is covered by one of the link's prefixes (e.g.,
                       as indicated by the on-link flag in the Prefix
                       Information option), or

                     - a neighboring router specifies the address as the
                       target of a Redirect message, or

                     - a Neighbor Advertisement message is received for
                       the (target) address, or

                     - any Neighbor Discovery message is received from
                       the address.

Note - that the "on-link" flag needs to be on as well, A-bit alone does 
not cut it.

The "off-link" shortcut of mine is unfortunate, since indeed it is not 
strictly speaking correct. But
"Not-on-link-but-because-ICMPv6-redirects-are-disabled-it-is-treated-as-off-link" 
is a bit too long to write. Probably a new term is due there.

>the host issue an address resolution NS because the packet destination is 
>on-link or due to the L-bit cleared in the received RA, the host sends 
>the packet to the default router(s)?

L-bit set to zero and no-redirects (Thanks Erik Nordmark for the 
correction of this important omission in the write-up!) worked fine to 
have the hosts send all the packets to the default router, thus avoiding 
performing the ND for this destination.

Of course, a better wording proposal is always welcome.

>
> The only means in ND to specify all destinations as off-link is to have 
>the RA include no PIO and have the A-bit cleared.   The hosts use DHCPv6 
>for address assignment.   This is the NBMA ND link model.  The router 
>also supports a DAD Proxy.
>
>> For multicast behavior in network switches, please see RFC 4541.

Interesting read, thanks.

>Additionally MLD snooping is old and a burden for consumer devices to 
>implement.   New protocol work is needed to mark packets for specific 
>multicast flows so that hosts don't have to snoop MLD.

The consumer switches can flood, it's not a problem there, really.

>
> Additionally, section 4.6 mentions the avalanche effect.  The ND 
>protocol randomizes and adds jitter when issuing messages to the link 
>precisely to alleviate any avalanche effect.  Thus I am not convinced of 
>the avalanche effect.    May I also know why the wifi nodes in a 100,000 
>clients link will have not of entries in the Neighbor Cache?  Each client 
>talks to one or two clients at a time.  So what traffic causes the number 
>of entries in a client to be large?  How large is large?

If you're not convinced, then you can skip this item for your 
deployment. I've seen it once, and there were multiple contributing 
factors, so I don't have a good data to convince you. Equally I don't have 
a spare lab with 9000 hosts of various operating systems, moving around. I 
left it because it does seem like a conservatively prudent thing to do.

--a

>
> Thanks,
>
> Hemant
>