Subject: Re: Changes since draft 15

From: Peter Johansson <[email-masked]>
Date: Mon, 13 Sep 1999 16:19:06 EDT

I'll set aside (for the moment) the question of whether or not the draft is
clear. First, let's see if we're all on the same page, technically.

In a message dated 99-09-13 15:39:05 EDT, [email-masked] writes:

<<Based on the above, my concern would appear to be that "transfer" is a
misleading term. I had assumed "transfer" means, node X owns channel x, but
wants to give it up, and one wants some other node, Y to become owner for x
with no apparent disruption in service (i.e., the channel mapping for IP
multicast group Z to channel x does not change).>>

That's my understanding of the intent of "transfer"---seamless, smoot, not
disruptive of IP multicast traffic.

<<What I read the above as saying is that "transfer" really means the owner
deallocates it, then someone else (all nodes simutaneiously?? yikes!!)
allocate a new channel, then there is conflict resolution. Meanwhile, IP
multicast service would appear to be severerly effected until the dust
settles.  Is how transfer is intended to work? (This would seem rather
inconsistent with the text, but the above explanation seems to suggest
that.)>>

"Yikes!" is right. In a transfer, one hopes that the channel is NOT
DEALLOCATED; hence the reason for the advance warning (expiration time
countdown to zero) provided by the curent owner who wishes to retire.

I think what Myron is pointing out is that MORE THAN ONE IP multicast sender
might conclude that it is the "best", the "natural", the "most fitting"
candidate to assume the new responsibilities of channel ownership and MCAP
advertisement. So, no channel allocation or deallocation has taken place but
two or more devices are sending MCAP advertisements for the same multicast
group and channel number. Here is where the contention rules come into play:
the guy with the largest physical ID wins.

Subject to the same caveat offered by Myron (that when one has worked closely
with the text it is hard to determine whether or not it is clear to a new
reader), I'll venture the opinion that Draft-IETF-IP1394-IPv4-18 DOES says
all of this clearly.

By the by, while we're sorting out these final editorial niceties, has the
most recent Internet-Draft been put before the IESG for advancement to RFC?
In my opinion, it's ready for this next step.

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Tue, 14 Sep 1999 07:51:47 -0400

> disruptive of IP multicast traffic.

Ack.

> reader), I'll venture the opinion that Draft-IETF-IP1394-IPv4-18 DOES says

I'm going entirely by the text, and am trying very hard NOT to read
between the lines.

> In my opinion, it's ready for this next step.

The sentence that was added says:

    MCAP advertisements whose expiration field has a value less than 60
    SHALL be ignored for the purpose of overlapped channel detection.

However, the text seems to define "overlapped channel detection" as
meaning two nodes allocating a different channel for the same
multicast group. In the transfer case, however, channels are NOT
overlapped. So the added text has no effect. Thus, I still do not see
how transfer actually takes place smoothly.

The text that deals with transfer specifically says:

> If other multicast source(s) are using the same channel mapping and
> observe an expiration time less than or equal to 30 seconds, they SHALL
> commence transmitting MCAP advertisements for the channel mapping with
> refreshed expiration times greater than or equal to 30 seconds that
> maintain the channel mapping. Any contention that occurs between
> multiple sources that attempt to claim ownership of the channel mapping
> SHALL be resolved as described in 9.6. If the original owner observes an
> MCAP advertisement for the channel to be relinquished before its own
> timer has expired, it SHALL NOT deallocate the channel number.

However, my reading is that section 9.6 does not apply to the case at
hand (which is NOT an overlapped channel), so in fact arbitration will
result in the owning node continuing to retain ownership, because it
(presumably) is the larger physical ID.

If you disagree with this assessment, it would help if you quoted text
from the draft showing why this isn't the case.

It seems to me that one fix might be to make it more clear that the
algorithm in 9.6 applies not just to the overlapped channel case, but
to all cases.

> most recent Internet-Draft been put before the IESG for advancement to RFC?

Not yet. We need to understand the scope of changes that are
needed. The IESG wants a final document, not one that is still being
iterated on by the WG.

Thomas