Subject: Re: [MBONED] general comments on draft-ietf-mboned-auto-multicast-12

From: Greg Bumgardner <[email-masked]>
Date: Wed, 04 Apr 2012 11:53:13 -0700

Gorry,

Thanks for the input! I thought I'd have a response ready a few days 
ago, but a cold virus I must have picked up immediately after arriving 
in Paris has knocked me out for several days.

I'll address items raised in your second e-mail in a separate response.

Comments below...

-g.b.

On 3/29/12 10:49 AM, Gorry Fairhurst wrote:
>
> Here is my quick review of draft-ietf-mboned-auto-multicast-12.
>
> I see this as a major textual change to the I-D, so I have tried to 
> read the whole of the document and provide general comments in this 
> message. General comments follow (a separate message will send 
> transport-related feedback).
>
> Gorry
>
> ####
> Section 1:
>    Unfortunately, many of these
>    applications must currently rely on unicast replication at or near
>    sources because most clients lack multicast connectivity to the
>    network containing the sources.
>
> - While this may be correct, it's easy to misread this as AMT defines 
> how to inject traffic sources into the multicast cloud. This may be 
> clearer if it says something more like "because most clients at 
> receivers do not have multicast connectivity to the network that carry 
> traffic from the sources."
Changed to:
"Unfortunately, many of these applications lack multicast connectivity 
to networks that carry traffic generated by multicast sources."
>
> ####
>    have native multicast access to a multicast source network to request
>                                                ^^^^^^
> - Is "source" helpful here?
>
I think the entire statement is a little suspect. The following 
statement, though rather convoluted, might provide a more accurate 
description:

"AMT enables sites, hosts or applications that do not have native 
multicast access to a network with multicast connectivity to a source, 
to request and receive SSM and ASM traffic from a network that does 
provide multicast connectivity to that source."

Unfortunately, this statement only holds true if there exists a 
discovery address (or method) that can be used to locate a relay with 
connectivity to the source. It would simplify things if we treated this 
issue as out-of-scope.

> ####
>    To allow fast deployment, the solution presented here only requires
>    small and concentrated changes to the network infrastructure, and no
>    changes at all to user applications or to the socket API of end-
>    nodes' operating systems.
> - The above para was in the intro, and I'd hoped to see something like 
> this in the applicability section of the new draft. That is, what 
> needs to eb change to deploy this?
>
The reason I removed the statement was largely because there was no 
accompanying explanation as to how or why. I also believe the 
declaration regarding applications is over broad, as this statement only 
holds true in cases where the AMT functionality is deployed at the 
virtual/pseudo device level and receiver applications provide the means 
for selectively binding to those interface(s). I anticipate that many 
applications will rely on internal AMT support to avoid a dependency on 
an AMT network interface component.
> ####
> Section 2.
>    multicast traffic from sources in a multicast enabled network to
>
> - remove "sources in". To clarify the next sentence.
Done.
>
> ####
>    The downstream side of a gateway services multicast receivers - the
>                                             ^
> - insert "one or more" to make this sentence more easily read.
Done.
>
> ####
> 4.1.4.1
>    does not yet allow this, as many relays will lack native multicast
>                             ^^
> - replace 'as" by "because"
Done.
>
> ####
>    access to sources even though they may be globally accessible via
> - consider replacing sources, since AMT doesn't directly access sources.
>
Reworded as follows:

"Ideally, the AMT protocol would provide a universal solution for 
connecting receivers to multicast sources - that any gateway could be 
used to access any globally advertised multicast source via 
publicly-accessible, widely-deployed relays."

> ####
> 4.2.1
>       in order to find a relay with which to communicate.
>       ^^^^^^^^^
> - To make it less confusing, suggest you omit the "order".
>
Reworded as follows:

"Sent by gateways to solicit a Relay Advertisement from any relay. Used 
to find a relay with which to communicate."
> ####
> 4.2.1.4
>         request is typically made through some form IGMP/MLD service
>                                           ^^^^^^^^^
> - does not parse missing word?
Changed to "...made using some...".
>
> ####
>    10.  Multicast datagrams transmitted by a source travel through the
> - say "from" instead of "transmitted by"?
Meet you half way; "transmitted from".
>
> ####
> 4.2.2.3
>    datagrams.  These IP datagrams are encapsulated in AMT messages which
> - /which/that/
>
Done. Need to bust out the Strunk & White.
> ####
> 5.1.4.5
>    A 1-bit flag set to 0 to indicate that the message does NOT carry the
> - RFC 2119 keyword "NOT" seems like it should be lower case.
>
> ####
> 5.2.3.4.2
>    message must be computed as described in Section 5.2.3.4.5.
> - /must?MUST/ ??
>
Done.
> ####
> 5.2.3.5.1
>       Unsolicited
>       state-change reports are typically retransmitted multiple times
>       while current-state reports are not.
> - Presumably advice, not a requirement.
Yes. Hence lack of requirements language. Do you think this section 
requires explicit indication that it is informative in nature?
>
> ####
>    The gateway must start a timer that will trigger the next iteration
> - /must?MUST/ ??
>
Done.
> ####
> 5.2.3.6.2
>    has not yet located a relay with which to communicate, it must first
> - /must?MUST/ ??
Done.
>
> ####
> 5.2.3.6.2
>    not yet received a Membership Query message, it must first execute
> - /must?MUST/ ??
Done.
>
> ####
> 5.2.3.7.2.
>    If the gateway sends the
>    Teardown message multiple times, it SHOULD insert a delay between
>    each transmission using the timing algorithm employed in IGMP/MLD for
>    transmitting unsolicited state-change reports.
> - Can you recommend a value? An arbitrary delay is clearly not what is 
> intended, so can we suggest a range or value please!
>
My intent was to defer to those specs, which call for a default value of 
1 second. I'll add the following:
"The RECOMMENDED default delay value is 1 second.".
> ####
> 5.3.3.2
>    address, it must respond just as it would if the message had been
> - /must?MUST/ ??
>
Done.
> ####
> 5.3.3.7
>    The RECOMMENDED endpoint timer duration MAY be computed from tunable
> - The second keyword /MAY/may/ - a recommended value can't be optional?
>
Removed "RECOMMENDED".
> ####
>    Property implemented gateways and relays will also filter
>    ^^^^^^^^
> - /property/Properly/
Done.
>
> ####
> The draft speaks about IP encapsulation of membership reports etc, 
> which would normally carry the IP Router Alert option. What is the 
> expectation here?
> - Is an IP packet with an RA option discarded?
> - IS an IP packet with a RA option accepted?
>
Though not explicitly mentioned, the assumption is that the IGMP/MLD 
protocol implementation will do what is necessary, as described by those 
specs (ignore message packet if RA is missing in IGMPv3 and 
MLDv1/MLDv2). The draft does indicate that the message packets generated 
must comply with the header requirements for IGMP/MLD as described in 
those specs.
> ####
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 05 Apr 2012 11:14:52 +0100

See comments in-line (thanks for the CC).

Gorry

On 04/04/2012 20:47, Greg Bumgardner wrote:
> E-mail fail - meant to send to you with CC to mboned. Just want to make
> sure you see it.
>
> -g.b.
>
> -------- Original Message --------
> Subject: 	Re: [MBONED] general comments on
> draft-ietf-mboned-auto-multicast-12
> Date: 	Wed, 04 Apr 2012 11:53:13 -0700
> From: 	Greg Bumgardner <[email-masked]>
> To: 	[email-masked]
>
>
>
> Gorry,
>
Works for me.

> provide multicast connectivity to that source."
May be better:
"AMT enables sites, hosts or applications that do not have
  access to native multicast connectivity
  to request and receive SSM and ASM traffic from a source
  network that provides multicast connectivity to a source."

> connectivity to the source. It would simplify things if we treated this
Fine.

>>  needs to be changed to deploy this?
>>
No comment

> publicly-accessible, widely-deployed relays."
Works for me,.

> to find a relay with which to communicate."
OK

> Done. Need to bust out the Strunk&  White.
>>  ####
>>  5.1.4.5
Seems good.

> must comply with the header requirements for IGMP/MLD as described in
If you think this is fine, then OK with me.

Gorry--
Prof Gorry Fairhurst, School of Engineering, University of Aberdeen.
The University of Aberdeen is a charity registered in Scotland,
No SC013683.--
Prof Gorry Fairhurst, School of Engineering, University of Aberdeen.
The University of Aberdeen is a charity registered in Scotland,
No SC013683.