Re: Review of draft-gundavelli-v6ops-l2-unicast

[Ole Troan <[e-mail]>]

Bernard,

thanks for a very thorough review.

[I didn't see this before the IESG raised a DISCUSS, it must be useful for the authors / wg to see these reviews too?]

[...]

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

we specifically didn't want to go into the use cases for this functionality. e.g. one use case being N:1 VLANs (which are point to point upstream and multi-access downstream), where one wants to send a different multicast message to each user. everyone listens to the same multicast address (e.g. IPv6 all routers), but the message sent to each is different, and that requires (in that deployment) unicast L2 addresses. basically making the link appear like a point to point link. 

what the functional requirement is, depends. so I'd very much like to keep that out of the document, which only purpose is to clarify that it is valid to map a L3 IPv6 multicast address into a L2 unicast address.

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

indeed. the same argument as above applies.
with regards to "sender", I've looked through a few multicast RFCs and none of them define the term "sender". to me, although a non-native English speaker, the term is not ambiguous. could you clarify what you mean?

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

indeed. I would imagine many of the use cases are for such deployments, point to point links, or where one try to make a multi-access link look like it is point to point, where this mapping is done for link-local multicast packets. e.g. ND RAs.

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

I haven't seen any use case where a host would use this. but, if there was one, it would have to know the L2 address by some other means.
again, we do not want to go into details on how this could be used. just state that the alternative mapping is valid.

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

this document is being referenced by BBF and also by some work in PMIP(?). in any case I'd like those documents to have the restrictions.
on the other hand I see your point. we don't want 'random' multicast senders to "optimize" and use this mapping.
the introduction states that this applies when there is _one_ receiver. if we also added that restriction to the above paragraph, would that make it clearer?

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

I can't think of one either. a SHOULD NOT is quite strong, but I would certainly not disagree with changing that to a MUST NOT either.

cheers,
Ole