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

[Pekka Savola <[e-mail]>]

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
> [e-mail] 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
> [e-mail]
> 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