TSVDIR review of draft-ietf-mboned-addrarch-07
Joe Touch <touch@isi.edu> Mon, 28 March 2011 07:23 UTC
Return-Path: <touch@isi.edu>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13493A6874; Mon, 28 Mar 2011 00:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mxyt8AyncJmU; Mon, 28 Mar 2011 00:23:26 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id D8F393A681D; Mon, 28 Mar 2011 00:23:25 -0700 (PDT)
Received: from [130.129.68.126] (dhcp-447e.meeting.ietf.org [130.129.68.126]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p2S7OErD027580 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 28 Mar 2011 00:24:25 -0700 (PDT)
Message-ID: <4D90379C.6030506@isi.edu>
Date: Mon, 28 Mar 2011 00:24:12 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: TSV Dir <tsv-dir@ietf.org>
Subject: TSVDIR review of draft-ietf-mboned-addrarch-07
References: <4D48B4EA.20503@isi.edu>
In-Reply-To: <4D48B4EA.20503@isi.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tsv-ads@tools.ietf.org" <tsv-ads@tools.ietf.org>, IETF discussion list <ietf@ietf.org>, draft-ietf-mboned-addrarch@tools.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Mar 2011 07:23:28 -0000
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@ietf.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. ----
- TSVDIR review of draft-ietf-intarea-shared-addres… Joe Touch
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Fernando Gont
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Jari Arkko
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Joe Touch
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Masataka Ohta
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Joe Touch
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Joe Touch
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Fernando Gont
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Joe Touch
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Fernando Gont
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Fernando Gont
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Joe Touch
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Joe Touch
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Fernando Gont
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Masataka Ohta
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Joe Touch
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Masataka Ohta
- Re: TSVDIR review of draft-ietf-intarea-shared-ad… Masataka Ohta
- TSVDIR review of draft-ietf-mboned-addrarch-07 Joe Touch