Subject: [dhcwg] Re: meta thoughts on m/o bits

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 21 May 2005 03:50:02 +0900

(cc'ing the dhcwg list)

>>>>> On Fri, 20 May 2005 13:24:26 -0400, 
>>>>> Thomas Narten <[email-masked]> said:

> Stepping up a level (and this also reflects my thinking after a
> private exchange with Ralph/Bernie - but not necessarily their
> thinking!)...

> I think the M/O bits (in retrospect) have turned out to be more
> trouble than they are worth. Indeed, they seem to be mostly just
> confusing. Thus, maybe we should work towards removing them
> completely.

As a meta thought, I cannot agree more.  In fact, the points you
showed are (almost) exactly what I wanted to make when we first
discussed the M/O flags issue in the rfc2462bis work (but you seem to
express the points much better than I did).

We actually once considered this option, whereas we didn't see some of
the relevant points we now know.  See, for example, a very long
thread a year ago:

http://www1.ietf.org/mail-archive/web/ipv6/current/msg02285.html

As you can see in the thread archive, there was a strong push-back
against the idea of removing these flags (while some others supported
the idea).  Then we finally decided to not remove the flags after a
heated discussion.  So, I'm wondering whether we can now really
convince those who opposed to the idea.

One additional meta note: even if we now decide to remove the flags,
it wouldn't affect rfc2462bis, since it does not mention the flags at
all.  However, the decision would require a non-trivial (while not so
big) change to rfc2461bis, which contains these flags in the RA
message format and a brief description of these flags.

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

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Soohong Daniel [email-masked]" <[email-masked]>
Date: Tue, 24 May 2005 10:28:22 +0900

(Sorry for being too late response)

I am really not sure why this thread is moved to *meta thought*.
When I wrote this document, I originally thought this task was 
our explicit consensus to be a seperated document from 2462bis.
Am I missing anything ? I don't think so.

See below link (October 2004)
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03799.html

It would have been nice if you said your comment at that time.

As you mentiond, simplicity is also good aspect and we (all author)
was trying to make this document as simple as we can. If we feel it 
so heavy, we will make it more concise than now.

---------------------------------------------
Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thomas Narten
> Sent: Saturday, May 21, 2005 2:24 AM
> To: [email-masked]
> Subject: meta thoughts on m/o bits
> 
> 
> In an ideal world, there would be exactly one way for a client to
> invoke DHC. That is, it would use the same message exchange to get
> "addresses" as it did for "non-address configuration". In such a
> world, there would be no need for the M/O bits, since the client would
> do the same thing if either one of them were set.
> 
> Unfortunately, we are not quite there, since DHC actually has HCB &
> ICB message exchanges (using Ralph's terminology). Thus, there are
> scenarios where invoking ICB is preferable over HCB. (Aside note: here
> is another example where having two ways to do similar things, results
> in undesirable complexity). Currently, we sort of need the M/O bits so
> a client can know which variant of DHC to invoke. But, we now also
> allow for the possibility of "silly states", i.e., states that aren't
> supposed to happen, but can, e.g., through misconfiguration. Having
> the M bit set but no addresses available is one such example.
> 
> Ralph has already indicated that with some small changes to the DHC
> spec, we might be able to fix the DHC issue so that there is one way
> to invoke DHC that does the right thing in all combinations of
> addresses and/or other configuration information being available via
> DHC.
> 
> If we had that, we wouldn't need two RA bits anymore. At most, a
> single "there is stuff to obtain via DHC" bit would suffice.
> 
> Indeed, one could go further and say "just always invoke DHC", and
> don't even bother with an RA bit saying DHC is available. That has the
> nice property of being simple to implement and you don't have silly
> states where the RA bit(s) are configured incorrectly, etc.
> 
> The only advantage I can see right off to having at least 1 RA bit is
> to tell the client "there is no DHC server running, so don't even
> bother". This would be a performance optimization to allow one to
> avoid needing to invoke DHC and have it timeout -- before concluding
> that there are no DHC servers. Is this a significant optimization?
> Hard to say.
> 
> What I would like to suggest: followup on the above proposed DHC
> changes and see if we can actually "fix" DHC to simplify what the
> client has to do to invoke it. And if that works, do away with one or
> both of the RA bits.
> 
> Remember, simplicity is Good!
> 
> Thomas
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
>