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

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Mar 2011 15:39:06 +0300 (EEST)

Hello Joe,

Thanks for your review (FYI to mboned WG list).

Your main concern appears to be that the document (S 3.4.1) should 
additionally also describe how multiple applications could use the 
same multicast group address with certain caveats.  While this might 
be useful information, I'm not sure that this is the right forum to 
describe this issue.  But if folks feel strongly about this, maybe 
something like follows could be added as a second paragraph of S 3:

   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.

Wrt to other high-level comments:
  - Global multicast addresses are not comparable to port number IANA 
space.  Any port number can be used by a local node even though IANA 
has allocated it.  An IANA assigned multicast address cannot. 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).
  - I do not see the conflict between 3.4.1 and 3.5 #2.
  - I agree that application/group sharing issue could be added to 4.3. 
Any text suggestion for a bullet point?

On Mon, 28 Mar 2011, Joe Touch wrote:
> I've reviewed this document as part of the transport area directorate's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's authors for their information and to allow them to address
> any issues raised. The authors should consider this review together with
> any other last-call comments they receive. Please always CC
> [email-masked] if you reply to or forward this review.
>
> The document describes the various mechanisms for IP multicast address
> allocation (delegating a group of addresses for further assignment) and 
> assigment (assigning addresses for use). The document currently addresses no 
> transport issues.
>
> There is one notably missing transport issue that should be addressed prior 
> to publication. The document discusses the use of specific multicast 
> addresses by individual applications, but does not currently address the 
> relationship of multicast addresses to transport identifiers (e.g., port 
> numbers or service names).
>
> The note below includes the significant transport issues, as well as
> additional comments that are optional but I hope also useful.
>
> I hope this feedback will be useful to the authors, and will be glad to
> provide further assistance either on- or off-list as useful.
>
> Joe
>
> --------------------------------------------------------------
>
> Transport issues include:
>
> - sec 2.4 currently discusses use of multicast by applications
> Sec 3.4.1 especially should discuss the relationship between multicast 
> addresses and transport identifiers for per-application use, and when each 
> (or both) are useful. E.g., sharing a multicast address reduces network 
> state, but prevents optimizing distribution trees per service.
> Sharing a multicast address (e.g., if one were assigned to "all backups", as 
> one is currently assigned for "all routers") could reduce the need for 
> per-application multicast addresses, but requires coordinated transport 
> identifiers (e.g., assigned ports). Using multicast addresses as transport 
> identifiers could obviates the need for a globally-assigned port number.
>
> - the discussion in sec 3.4.1 needs revision
> The discussion should focus on facts, rather than stating the facts inside 
> judgements (e.g., remove 'lucrative', and 'land grab'). The facts appear to 
> be that they're global and limited, and that self-assignments can conflict 
> with IANA assignments; this is no different from the port numbers space. The 
> key issue is that the appropriate spaces are much smaller (8-bits in the 
> Internetwork block, but 24 bits in the admin scoped block)
>
> Sec 3.5 list item #2 is inconsistent with the discussion in sec 3.4.1
> If IANA global assignments are the most common static assignments, then that 
> should be indicated in sec 3.4.1. ]
>
> This section should explain "last resort" as used in the tables in sec 4, and 
> whether that is expected to persist if admin scoped addrs are statically 
> assigned
>
> - sec 4.3 should discuss potential future resolution of the relationship 
> between multicast addresses and transport identifiers in separating 
> application traffic
>
> -----------------------------------------------------------
>
> Some other comments (hopefully optionally useful):
>
> - the document moves RFC 2909 to historic
> RFC 2909 was experimental; it's not clear it's necessary to move it to 
> historic.
>
> - it would be useful for the intro to explain why addresses are assigned, and 
> what assignments are useful (e.g., in some cases, to speak to groups of 
> devices, in others, for a service or application)
>
> - the document should include some examples of current static assignments, 
> e.g., 'all routers'
>
> - sec 2.4 describes "*seriously* implemented"
> This should be clarified as 'widely', 'robustly', or some other term that 
> explains the deficiency.
>
> - sec 2.4 discussion of Norton Ghost seems misplaced
> It refers to an assignment issue, not an allocation one; it should be moved 
> to somewhere in sec 3
>
> - the tables in sec 4 use terms like "last resort" which are inconsistent 
> with the discussion in previous sections (notably 3.4.1 doesn't talk about 
> that).
>
> - the tables in sec 4 should indicate the size of the available space
> e.g., total bits available, and typical allocation or assignment size (if 
> known, or a range if appropriate). This would further assist those asking for 
> addresses in determining the appropriate approach.
>
> Further, these tables could be expanded to summarize info already presented 
> to further help those asking:
> 	 * replace "yes" with "self/dynamic/static" to differentiate
> 	   between (respectively) those internally calculated, those
> 	   obtained by a protocol exchange, and those obtained from IANA
> 	   or a registrar
> 	 * explaining whether collisions can occur (or at least are
> 	   prevented by assignment/protocol)
> 	 * indicate which multicast block is assigned/allocated using
> 	   the given mechanism
>
> - sec 5 first paragraph wording would benefit from revision
> E.g., starting with "This work was inspired and movtivated by ..."; the 
> current text doesn't parse as a complete sentence.
>
> ----
>
>
>
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 Mar 2011 07:53:30 +0300 (EEST)

(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:
> 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.

> 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.

> 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