Subject: [MBONED] draft-ietf-mboned-auto-multicast: General Query Source Address

From: Greg Bumgardner <[email-masked]>
Date: Fri, 26 Aug 2011 10:28:22 -0700

All,

To allow for IGMP or MLD to be used regardless of the IP protocol used 
to communicate with the relay, we agreed to add a flag to the AMT 
Request message to indicate to the relay which protocol to use for the 
General Query packet that will be carried by the AMT Membership Query 
message.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type=0x3  |   Reserved  |V|            Reserved           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Request Nonce                                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 AMT Request

Where V == 0 for IPv4/IGMP and V == 1 for IPv6/MLD.

I believe that we should also indicate in the draft that the 
relay/router may/must use 0.0.0.0 or :: as the source address in the 
general query packet. This is necessary in the case where the IP 
protocol used for the AMT messages does not match that of the general 
query carried in the Membership Query message, since the relay may not 
have a valid address to use as the source address. The 0.0.0.0 or :: is 
normally used to indicate that the query was sent by a non-querier, 
which would seem to make sense for AMT, as the relay/router is not 
really acting as a IGMP/MLD querier.

-g.b.

---

From: Kurt Windisch <[email-masked]>
Date: Wed, 31 Aug 2011 09:07:31 -0700

Hi Greg,

Sorry for the delayed response to your proposals.

Thanks a lot for the work on this spec!

The following are comments/questions on some of the proposals that you've

sent to the list since Quebec:

> - Modify the AMT Membership Query Message to word align the Gateway Address field.

Is there a reason that it's important to word-align by adding padding in the

middle of the packet? We have non-word aligned fields elsewhere, including in

PIM packets that use Encoded-Unicast-addresses. I don't see any problem with

this proposal (other than extra bits) but I also don't understand the necessity.

> TBD: Should the gateway address be treated as an optional field? I

> believe the spec should indicate that a relay MUST include this field

> in Membership Query messages (and set the flag), but existing gateway

> implementations should not expect to find it to provide compatibility

> with existing relay implementations.

I don't think we can make this a MUST and still claim backwards compatibility,

which everyone in the WG meeting appeared to agree was important.

Also, specifying it as a MUST but advising gateway implementations not to expect

it seems confusing and contradictory. In the current spec, SHOULD/RECOMMENDED

seems more appropriate since the discussion is acknowledging that this is *not*

an absolute requirement. It could become MUST in future versions of the AMT protocol.

>From RFC2119: "MUST This word, or the terms "REQUIRED" or "SHALL", mean that the

definition is an absolute requirement of the specification."

> General Query packet that will be carried by the AMT Membership Query message.

> <snip>

The addition the query version bit looks good.

> TBD: Should a gateway use different source ports for IGMP and MLD

> requests, or should we indicate that a relay must allow for both IGMP

> and MLD reports from a single source/port address pair?

If IPv4/IGMP and IPv6/MLD use different gateway source ports, that means

that the encapsulation strings for the tunnel on which the Relay sends data

will also differ for IPv4 and IPv6 traffic.

In terms of the language of the current spec, that would mean a single

dual-stack gateway would be viewed as two separate NBMA recipients.

(From Section 5: "... the AMT recipient-list is a list of "link layer"

addresses which are (IP address, UDP port) pairs.")

Are there any problems with using the same source? If not, that looks

preferable since it avoids doubling the number of NBMA recipients.

> have a valid address to use as the source address. The 0.0.0.0 or ::

> is normally used to indicate that the query was sent by a non-querier,

> which would seem to make sense for AMT, as the relay/router is not really

> acting as a IGMP/MLD querier.

In which scenarios would the AMT relay not have an address to use as the

source address? If the relay is capable of receiving native IP multicast

for an address family (a prerequisite for being a relay), then shouldn't

it also be addressable for that family?

Thanks again!

--Kurt

---

From: Greg Bumgardner <[email-masked]>
Date: Wed, 31 Aug 2011 12:37:11 -0700

Kurt,

Thanks for the feedback. Comments below...

-g.b.

> this proposal (other than extra bits) but I also don't understand the 
I agree that alignment is unnecessary - and have no problem with leaving 
it as is. I just think that word-aligning addresses (esp. IPv6) is a 
common convention.
> definition is an absolute requirement of the specification."
I got involved in a discussion about this off-line, and was already 
convinced this should be left as an option.
> preferable since it avoids doubling the number of NBMA recipients.
After giving it some thought, I don't think it matters one way or the 
other. Both approaches would work if a relay simply accepts either 
protocol from a single UDP source. There is nothing to prevent a gateway 
from creating separate sessions and no way and no reason for a relay to 
detect this.
> really
I don't doubt that his might be true, except for the case where the 
pseudo-interface exposed by the relay/router has not been assigned both 
an IPv4 and IPv6 address. I don't see this as being an issue since there 
seems to be no point in returning an address since the relay is not 
really acting as a true querier - if anything, it would be the gateway 
acting as a querier, especially in the case where the gateway is acting 
as an IGMP/MLD proxy.