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.

This kind of disparity between implementations and specs is the exact reason for revising specs. These must be fixed IMHO.

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

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


--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to