Re: [MBONED] TSVDIR review of draft-ietf-mboned-addrarch-07

[Pekka Savola <[e-mail]>]

(Note: There seems to be convergence. Nonetheless, I'll defer text 
edits until I get a "go-ahead" from the document shepherd or the 
responsible AD).

On Mon, 28 Mar 2011, Joe Touch wrote:
>>  It is also possible to share a group address between multiple
>>  applications. The tradeoffs and considerations of that are beyond
>>  the scope of this memo.
>
> Your proposed text jumps into assuming use of both port numbers and 
> addresses, which seems useful for the future directions section, but not sec 
> 3.
>
> For sec 3, my primary concern is that multicast addresses are sometimes used 
> *instead* of port numbers, and that either doing that or using them together 
> has implications.
>
> E.g.:
>
> Multicast addresses are often used in a similar way as transport identifiers, 
> such as port numbers or service names, so that a single application service 
> uses a single multicast address. This allows that application to use a 
> dedicated multicast tree, but also consumes a value from a much smaller space 
> (256 values in the Internetwork block).

I think I understand what you mean, but I don't see the relevance of 
this relatively detailed text in the context of a document describing 
address assignment & allocations even though the document briefly 
touches upon application usage.  If some text is added, I'd prefer to 
keep it as simple as possible (e.g. no mention of 'transport 
identifiers' as that's a hard-to-grasp term in this context). E.g.:

   Typically the group address for an application is chosen such that
   it is not used with other applications.  This is not strictly
   required but the tradeoffs and considerations of that are beyond the
   scope of this memo.

>>  I.e. group
>>  address assignments are exclusive while port numbers are not (e.g.:
>>  host's port number selection strategy need not exclude those ports that
>>  are listed in /etc/services).
>
> A port that isn't in use can be used by any other app. The same is true for a 
> mcast address. In both cases, this interferes with the assignee's use of that 
> value. Again, I don't see a diffence.

Indeed, it's the same from "nothing can stop a person from doing that" 
perspective. It's different from "if IANA assigns it, you're not 
supposed to use it" perspective: with port numbers, you're (or the 
host) still free to use them;  with IANA-assigned multicast addresses, 
you should not use them.

>>  - I do not see the conflict between 3.4.1 and 3.5 #2.
>
> It seems inconsistent to me that the "last resort" path is the most popular. 
> First, 3.4.1 should use the term "last resort" and explain the other 
> preferred mechanisms, and it might be useful to note that this remains the 
> most popular mechanism (and possibly even hint at why). AFAICT, it's less a 
> 'land grab' as it is a way to ensure the app assumes as little as possible 
> about the mcast installation.

"Last resort" refers to "it should not be used if there are viable 
alternatives" (actually you need to go through a form justifying the 
use if you want them: http://www.iana.org/cgi-bin/multicast.pl) 
Unfortunately, it is as you say that this "last resort" -path appears 
to be the most often used path, probably because it's the easiest for 
an app developer.

>>  - I agree that application/group sharing issue could be added to 4.3.
>>  Any text suggestion for a bullet point?
>
> Sure - working from your text above:
>
> It is also possible to share a group address between multiple applications. 
> Such sharing can reduce network state when applications have similar 
> multicast trees and reduces use of limited values in the Internetwork block 
> (of 256 values), but also requires those applications also have distinct 
> transport identifiers that can be used to differentiate their traffic. Use of 
> addresses in the Administratively Scoped range would relieve part of this 
> problem.

OK. I suppose I could craft new text based on that.

Pekka