On Sat, 31 Jul 2010 07:54:27 +0200 Fred Baker <f...@cisco.com> wrote:
> 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. 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. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
