Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 10 Feb 2005 12:37:59 -0500

Pekka, all, 

Sorry for the delay in resolving this but there were too many comments
and too little time! Seems like most of your comments were clearly addressed
by me or other people on the list and most are being put in the next rev (thanks). 
But I'm going to address the unresolved ones so far. Please let me know if I missed any.

First of all, we seem to agree that very detailed comments on implementation
are not the best way to go, so I'm leaving out your comment on changing
link layer addresses for routers and whether it is implemented.

I'm aiming to submit the next rev ASAP (less than a week).

Here are the rest:

 > > >                          AdvValidLifetime
 > > >                               The value to be placed in the Valid
 > > >                               Lifetime in the Prefix Information
 > > >                               option, in seconds.  The
 > > > designated value
 > > >                               of all 1's (0xffffffff) represents
 > > >                               infinity.  Implementations 
 > MUST allow
 > > >                               AdvValidLifetime to be 
 > specified in two
 > > >                               ways:
 > > >
 > > >                                 - a time that decrements in
 > > > real time,
 > > >                                   that is, one that will 
 > result in a
 > > >                                   Lifetime of zero at 
 > the specified
 > > >                                   time in the future, or
 > > >
 > > >                                 - a fixed time that 
 > stays the same in
 > > >                                   consecutive advertisements.
 > > >
 > > > ==> 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.

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

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

 > > >     A router MUST limit the rate at which Redirect messages
 > > > are sent, in
 > > >     order to limit the bandwidth and processing costs 
 > incurred by the
 > > >     Redirect messages when the source does not correctly
 > > > respond to the
 > > >     Redirects, or the source chooses to ignore
 > > > unauthenticated Redirect
 > > >     messages.  More details on the rate-limiting of ICMP
 > > > error messages
 > > >     can be found in [ICMPv6].
 > > >
 > > > ==> 'or the source chooses to ignore unauthenticated Redirect
 > > >     messages' smells quite a bit from a leftover of IPsec AH
 > > > times.  Reword?
 > >

=> I don't see this as a synonym for IPsec, let's not change it.

 >        Unlike in IPv4 Router Discovery the Router Advertisement messages
 >        do not contain a preference field.  The preference field is not
 >        needed to handle routers of different "stability"; the Neighbor
 >        Unreachability Detection will detect dead routers and switch to a
 >        working one.
 > 
 > ==> preference has been plugged back, though not for stability 
 > reasons. I'd suggest just removing this paragraph.

=> Again, we didn't get any agreeing comments and two people 
disagreed. I think we should leave this in.

The rest of your comments will make it to the next revision. 

thx,
Hesham

===========================================================
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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Tue, 15 Feb 2005 20:55:27 +0200 (EET)

On Thu, 10 Feb 2005, Soliman, Hesham wrote:
[lifetimes which decrement in real time]
> => 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.

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

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