ietf
[Top] [All Lists]

TSVDIR review of draft-ietf-mboned-addrarch-07

2011-03-28 02:25:23

Hi, all,

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
tsv-dir(_at_)ietf(_dot_)org 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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • TSVDIR review of draft-ietf-mboned-addrarch-07, Joe Touch <=