> On Thu, 10 Feb 2005, Soliman, Hesham wrote: > [lifetimes which decrement in real time] > > > > > ==> AFAIK, the first option has not been implemented; I've > > > > > at least not seen > > > > > in done. Therefore unless someone shows that there are two > > > > > implementations > > > > > of this, this must be removed. (The same for > > > > > AdvPreferredLifetime, and a bit > > > > > in section 6.2.7.) > > > > => We were told this is implemented in Solaris I believe. > > One implementation is not sufficient for DS. > > However, even if there was a second implementation (probably yes) > don't you think it's ridiculous that spec says MUST, while only one > implementation has heeded that advice? > > I suggest making it a SHOULD or MAY so it better reflects > the reality.
=> I thought I already agreed to making it a MAY. I'll make it a MAY. > > > > > A proxy MAY multicast Neighbor Advertisements when > > > its link-layer > > > > > address changes or when it is configured (by system > > > management or > > > > > other mechanisms) to proxy for an address. If there > > > are multiple > > > > > nodes that are providing proxy services for the same set > > > > > of addresses > > > > > the proxies SHOULD provide a mechanism that prevents > > > > > multiple proxies > > > > > from multicasting advertisements for any one > > > address, in order to > > > > > reduce the risk of excessive multicast traffic. > > > > > > > > > > ==> does anyone implement this SHOULD? Note that > this does not > > > > > give hints how to even go about doing that. If not, remove. > > > > > > > > => As mentioned earlier by Erik, this is a requirement on > other specs > > using proxy ND. MIPv6 is an example of such protocol. I > think this makes > > sense as a requirement. So let's keep it. > > Erik said, > > "As I said above, I think the MIPv6 RFC is the "implementation" in > this case. But it does make sense to clarify that the text > is about a > requirement on other protocols which use proxy ND." > > A clarification would be fine by me. This is not a requirement for > RFC2461 implementors, but rather those specs which use proxying. => Sure. > > > > > > Inbound load balancing - Nodes with replicated > > > > > interfaces may want > > > > > to load balance the reception of incoming > > > packets across > > > > > multiple network interfaces on the same > > > link. Such nodes > > > > > have multiple link-layer addresses assigned > > > to the same > > > > > interface. For example, a single network > > > driver could > > > > > represent multiple network interface cards > > > as a single > > > > > logical interface having multiple link-layer > > > addresses. > > > > > > > > > > Load balancing is handled by allowing > > > routers to omit the > > > > > source link-layer address from Router > > > > > Advertisement packets, > > > > > [...] > > > > > > > > > > ==> this is conflicting. The first para discusses > > > generic inbound > > > > > load balancing, the second load balancing that > applies only to > > > > > routers w/ RAs. How do hosts perform inbound load balancing? > > > > > Needs text tweaking.. > > > > > > > > => Erik responded: > > > > Leaving the first paragraph as is, since it is > basically explaining the term, > > and adding something before the second paragraph that > "Neighbor Discovery > > allows a router to load balance traffic towards itself > if the router has > > multiple MAC addresses by ..." > > > > => I think this is fine so I'll add it to the doc. > > This does not solve my wording issue. The paragraph just describes > how _routers_ perform inbound load balancing. How about hosts which > don't send RAs? => What do you suggest? Hesham > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
