Subject: draft-gundavelli-v6ops-l2-unicast WGLC

From: Fred Baker <[email-masked]>
Date: Sat, 31 Jul 2010 07:54:27 +0200

This is to initiate a two week working group last call of draft-gundavelli-v6ops-l2-unicast. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the combined lists.

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.

---

From: Mark Smith <[email-masked]>
Date: Sun, 1 Aug 2010 10:40:25 +0930

On Sat, 31 Jul 2010 07:54:27 +0200

> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an importa…

I think the Introduction is too long, as it also seems to be covering
some of the use cases in a bit more detail than an Introduction
normally would. I think the Introduction could probably just be the
first paragraph with a bit of rewording.

Conversely, I think the use cases detail is a bit lacking, possibly
because they've been put in the Introduction. For example, I don't
really understand this use case (part of the second paragraph of the
Introduction)

   For example, an 802.11 wireless access point may be hosting
   multiple IPv6 subnets/VLAN's and it would need the ability to
   selectively advertise hosted IPv6 prefixes on a per-node basis.  Such
   segregation can only be possible by ensuring the Router
   Advertisements received by any IPv6 node includes only those prefixes
   that are associated with their respective layer-3 subnet.  This
   essentially requires the ability to transmit IPv6 multicast messages
   as unicast messages on the link-layer. 

It sounds to me that what is being attempted here is to, instead of
dividing up nodes into groups via VLANs at layer 2, selective
layer 2 unicast of multicast layer 3 is used instead. Is this the case?
If it is the case, does this impact things like IPv6 redirect
operation or neighbor discovery? Would an NBMA model of link layer
operation be a more way of solving this problem? Is it somehow related
to SAVI? Or maybe an attempt to achieve the goals of SeND without
implementing cryto etc.? 

I'm also a bit confused by the ISATAP example,

"Another such example where
   this semantic is needed is in ISATAP [RFC5214] for sending a unicast
   Router Advertisement message on ISTAP interfaces. "

As RAs are allowed to have layer 3 unicast destination address, I'd have
assumed that a corresponding layer 2 unicast destination address is
also valid. The above text, in the context of this draft, seems to
suggest to me that this isn't the case.

As this draft is changing what has been a fundamental and fixed
assumption for a very long time (i.e. layer 3 multicast always equals
layer 2 multicast), I think it's important that use cases supporting it
are very clear in what they're trying to achieve and why allowing
multicast layer 3 addresses maps to layer 2 unicast is the best way to
solve those problems. A bit more detail in these use cases would help.

Regards,
Mark.