I have reviewed draft-gundavelli-v6ops-l2-unicast on behalf of the Transport
Directorate.
Transport directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on documents requiring their attention
and spend less time on the trouble-free ones.
Improving the documents is important, but clearly a secondary purpose.
A third purpose is to broaden the TSV-DIR reviewers' exposure to work going
on in other parts of the IETF.
Reviews from TSV-Dir members do not in and of themselves cause the IESG to
raise issue with a document. The reviews may, however, convince individual
IESG members to raise concern over a particular document requiring further
discussion. The reviews, particularly those conducted in last call and
earlier, may also help the document editors improve their documents.
Review Summary:
This document, while making a valid point, needs additional refinement so as
to ensure that IP multicast packets are sent to all potential subscribers on
a LAN. In its current form, this document provides too much wiggle room for
implementers and is could potentially result in
Interoperability problems.
Intended status: Proposed Standard
When transmitting an IPv6 packet to a multicast group, the
destination address in the link-layer header is typically set
to a multicast address. However, the fundamental requirement
for the link layer is that it deliver the frame to all of the
hosts that could be subscribed to the multicast group. In a
number of situations, this can be achieved by sending the frame
to one (or more) unicast link layer addresses. The main goal
of this draft is to clarify this point.
Is the document readable? Yes
Does it contain nits? No. idnits 2.12.05 comes up clean.
Is the document class appropriate? Yes
Is the problem well stated? Yes
Is the problem really a problem? Yes
Could the solution create more problems? Yes
In the abstract, the draft correctly states that it is not mandatory that
the link layer destination of an IP multicast packet be a link layer
multicast address. However, the document does not state what the functional
requirement is, namely that the IP multicast packet be delivered to all
potential subscribers. In some situations (such as a point-to-point link),
this requirement can be met by sending the frame to a unicast destination
link-layer address. In other situations (such as a WLAN), to meet that
requirement it would be necessary to either send the frame to a multicast
link-layer destination address *or* to send the frame to multiple unicast
link-layer destination addresses.
The draft does not state the fundamental requirement, and is not
sufficiently precise about the circumstances in which a unicast link-layer
address can be used. For example, Section 3 states:
o An IPv6 sender node in some special cases and specifically when
the link-layer address of the target node is known, MAY choose to
transmit an IPv6 multicast message as a link-layer unicast message
to that node. In this case, the destination address in the IPv6
header will be a multicast group address, but the destination
address in the link-layer header will be an unicast address.
The problem is that the above paragraph does not adequately define the
meaning of the term "sender" or the special cases in which the MAY applies.
Certainly if we are talking about a point-to-point link then a sender can
know that there is only one potential subscriber on the other end.
Also, if the sender is a device such as a switch or AP, then it will have
knowledge of the potential endpoints that are potential targets.
However, if the sender is a host, then the question is how a sender can know
the link-layer address of all the target nodes. Hosts don't normally keep
track of multicast subscriptions. In some situations, that may not even be
possible -- if we are talking about a multicast group that is not
link-scope, and the target node is known but is not on the link, the host
won't be able to obtain this knowledge and in any case, sending the frame to
the target's link layer address doesn't make sense, since it could result in
the frame not being delivered.
So I think that the term "sender" needs to be defined and this paragraph
needs to be re-written to make it very clear when a unicast link-layer
address can be used by the sender, and in what circumstances this is not
safe.
o An IPv6 receiver node SHOULD NOT drop a received IPv6 multicast
message only for the one specific reason that the received IPv6
message has a multicast destination address in the IPv6 header
while the link-layer header has a unicast address. Such a
validity check comparing the address types in the IP header and
the link-layer header is considered a layer violation.
Given the fundamental point that is being made (that IP and link-layer
addressing are independent), I am not clear about the circumstances in
which it would be valid to drop an IPv6 multicast packet because of its
link-layer destination address. I would like to see this spelled out, so
that it is clear why this is a MUST NOT.
-----Original Message-----
From: David Harrington [mailto:ietfdbh(_at_)comcast(_dot_)net]
Sent: Wednesday, September 22, 2010 9:35 AM
To: Bernard Aboba; Bernard Aboba
Subject: request: tsvdir for draft-gundavelli-v6ops-l2-unicast
Hi Bernard,
Can you do a tsvdir review for draft-gundavelli-v6ops-l2-unicast Last
Call ends 9/27
Thanks,
David Harrington
Director, IETF Transport Area
ietfdbh(_at_)comcast(_dot_)net (preferred for ietf)
dbharrington(_at_)huaweisymantec(_dot_)com
+1 603 828 1401 (cell)
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf