Subject: RE: 2461bis update

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 25 May 2005 23:31:24 -0400

> The only comments I made for this section (except the very recent one
 > we are now discussing) were the latter part of the section.  More
 > specifically, I agreed with Pekka that the latter part contained a
 > redundant condition, and also suggested to clarify the complex
 > conditions in the latter part.  On the other hand, I didn't even
 > expect a change (from RFC2461) to the first part.  Actually, I didn't
 > understand the points of the changes to the first part from RFC2461
 > and asked the intent, rather than suggested any changes from RFC2461.
 > That said, I'm even happy with the original text of RFC2461 about the
 > first part of this section.  (I actually said that before, see
 > http://www1.ietf.org/mail-archive/web/ipv6/current/msg04818.html)
 > 
 > As a meta-level comment, if we cannot remember the specific 
 > reason for
 > revising the text, I don't think it's a good idea to revise that
 > (since it can even introduce a new bug that was not in the original
 > document).
 > 
 > At least I don't see any problem in the first part of this section in
 > original RFC2461, so I'd now rather suggest to leave it (the first
 > part of 7.2.5) as was in original RFC2461.
 > 
 > Finally, I also noticed that Pekka's comment was not really 
 > applied in
 > draft-ietf-ipv6-2461bis-03.txt.  Specifically, the current text is
 > different from what I proposed in the following message:
 >   http://www1.ietf.org/mail-archive/web/ipv6/current/msg04819.html
 > (you seemed to agree with the change:
 >  http://www1.ietf.org/mail-archive/web/ipv6/current/msg04822.html)
 > 
 > That is, I proposed the following text:
 > 
 >    II. If the Override flag is set, or the supplied 
 > link-layer address
 >    e  is the same as that in the cache, or no Target 
 > Link-layer address
 >      option was supplied, the received advertisement MUST update the
 >      Neighbor Cache entry as follows:
 > 
 > but rfc2461bis-03 actually reads:
 > 
 >    II. If the Override flag is set, or the supplied Override flag is
 >        Clear, or the supplied link-layer address is the same 
 > as that in
 >        the cache, or no Target Link-layer address option was 
 > supplied,
 >        the received advertisement MUST update the Neighbor 
 > Cache entry
 >        as follows:

=> Yes this is clearly wrong. I'll update this. As for the rest, you still don't say
what's wrong with it, you just ask for it to be changed back. I don't agree
with your suggestion because there is no basis for it, but to save cycles I'll
change it back...

Hesham

 > 
 > This is clearly incorrect (the condition is then always 
 > true, since it
 > says, "If A, or !A, or ..." (where A = the Override flag is set))
 > 
 > How I'd like to propose a complete suggestion.  The point is:
 > 
 >   - don't change the first of section 7.2.5 from RFC2461
 >   - address Pekka's point correctly
 > 
 > Then the entire section would then be as follows.  Is this okay for
 > you?
 > 
 > 7.2.5.  Receipt of Neighbor Advertisements
 > 
 >    When a valid Neighbor Advertisement is received (either 
 > solicited or
 >    unsolicited), the Neighbor Cache is searched for the 
 > target's entry.
 >    If no entry exists, the advertisement SHOULD be silently 
 > discarded.
 >    There is no need to create an entry if none exists, since the
 >    recipient has apparently not initiated any communication with the
 >    target.
 > 
 >    Once the appropriate Neighbor Cache entry has been located, the
 >    specific actions taken depend on the state of the Neighbor Cache
 >    entry, the flags in the advertisement and the actual link-layer
 >    address supplied.
 > 
 >    If the target's Neighbor Cache entry is in the INCOMPLETE 
 > state when
 >    the advertisement is received, one of two things happens.  If the
 >    link layer has addresses and no Target Link-Layer address 
 > option is
 >    included, the receiving node SHOULD silently discard the received
 >    advertisement.  Otherwise, the receiving node performs 
 > the following
 >    steps:
 > 
 >     - It records the link-layer address in the Neighbor Cache entry.
 > 
 >     - If the advertisement's Solicited flag is set, the state of the
 >       entry is set to REACHABLE, otherwise it is set to STALE.
 > 
 >     - It sets the IsRouter flag in the cache entry based on 
 > the Router
 >       flag in the received advertisement.
 > 
 >     - It sends any packets queued for the neighbor awaiting address
 >       resolution.
 > 
 >    Note that the Override flag is ignored if the entry is in the
 >    INCOMPLETE state.
 > 
 >    If the target's Neighbor Cache entry is in any state other than
 >    INCOMPLETE when the advertisement is received, the 
 > following actions
 >    take place:
 > 
 >    I. If the Override flag is clear and the supplied 
 > link-layer address
 >      differs from that in the cache, then one of two actions takes
 >      place:
 >      a. If the state of the entry is REACHABLE, set it to STALE, but
 >         do not update the entry in any other way.
 >      b. Otherwise, the received advertisement should be 
 > ignored and MUST
 >         NOT update the cache.
 >    II. If the Override flag is set, or the supplied 
 > link-layer address
 >      is the same as that in the cache, or no Target 
 > Link-layer address
 >      option was supplied, the received advertisement MUST update the
 >      Neighbor Cache entry as follows:
 > 
 >     - The link-layer address in the Target Link-Layer Address option
 >       MUST be inserted in the cache (if one is supplied and 
 > is different
 >       than the already recorded address).
 > 
 >     - If the Solicited flag is set, the state of the entry 
 > MUST be set
 >       to REACHABLE.  If the Solicited flag is zero and the link-layer
 >       address was updated with a different address the state 
 > MUST be set
 >       to STALE.  Otherwise, the entry's state remains unchanged.
 > 
 >       An advertisement's Solicited flag should only be set if the
 >       advertisement is a response to a Neighbor 
 > Solicitation.  Because
 >       Neighbor Unreachability Detection Solicitations are sent to the
 >       cached link-layer address, receipt of a solicited advertisement
 >       indicates that the forward path is working.  Receipt of an
 >       unsolicited advertisement, however, suggests that a 
 > neighbor has
 >       urgent information to announce (e.g., a changed link-layer
 >       address).  If the urgent information indicates a 
 > change from what
 >       a node is currently using, the node should verify the 
 > reachability
 >       of the (new) path when it sends the next packet.  
 > There is no need
 >       to update the state for unsolicited advertisements that do not
 >       change the contents of the cache.
 > 
 >     - The IsRouter flag in the cache entry MUST be set based on the
 >       Router flag in the received advertisement.  In those 
 > cases where
 >       the IsRouter flag changes from TRUE to FALSE as a 
 > result of this
 >       update, the node MUST remove that router from the 
 > Default Router
 >       List and update the Destination Cache entries for all 
 > destinations
 >       using that neighbor as a router as specified in Section 7.3.3.
 >       This is needed to detect when a node that is used as a router
 >       stops forwarding packets due to being configured as a host.
 > 
 >    The above rules ensure that the cache is updated either when the
 >    Neighbor Advertisement takes precedence (i.e., the 
 > Override flag is
 >    set) or when the Neighbor Advertisement refers to the 
 > same link-layer
 >    address that is currently recorded in the cache.  If none of the
 >    above apply, the advertisement prompts future Neighbor 
 > Unreachability
 >    Detection (if it is not already in progress) by changing 
 > the state in
 >    the cache entry.
 > 
 > --------------------------------------------------------------------
 > IETF IPv6 working group mailing list
 > [email-masked]
 > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
 > --------------------------------------------------------------------
 > 

===========================================================
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 26 May 2005 13:17:28 +0900

>>>>> On Wed, 25 May 2005 23:31:24 -0400, 
>>>>> "Soliman, Hesham" <[email-masked]> said:

> with your suggestion because there is no basis for it, but to save cycles I'll

Sorry if I've been keeping unclear, but regarding the "rest", my point
is that the current text (of the first part of Section 7.2.5) in
2461bis is more confusing than RFC2461, and I actually didn't see any
problem in the original text of RFC2461 (and, for that matter, no one
knows the rationale of the changes in 2461bis).  That's why I
suggested to change it back.  Assuming (the first part of) 2461bis is
more confusing than RFC2461, I believe this is a reasonable suggestion
(isn't it?).

Regarding whether (the first part of) 2461bis is more confusing than
RFC2461, I admit "confusing" is a subjective word and opinions may
vary.  However, as I pointed out in this thread, at least the
duplicate description in 2461bis is clearly confusing to me.  That is,

   If the target's Neighbor Cache entry is in the INCOMPLETE state when
   the advertisement is received, one of two things happen: If the
   advertisement were solicited, the state is changed to REACHABLE.
   Otherwise, the state is set to STALE. Note that the Override flag is
   ignored if the entry is in the
   INCOMPLETE state.

   If the Neighbor Cache entry is in INCOMPLETE state, the receiving
   node performs the following steps:

     (...)

(The bullet is actually already covered in the paragraph starting with
"If the target's...")

Is it so unclear to say it's confusing to have the duplicate
description?  Is it strange to wonder whether we can unify the
duplicate part, and, e.g., remove the redundant paragraph (with moving
the "Note" sentence into the bullet if necessary)?

I'm sorry if I just look behaving in a stubborn way, blocking the
document...but please believe me, I just want 2461bis to be clearer.

I hope this message expresses my point clearly.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]