Document..........: draft-ietf-l2vpn-vpls-mcast-reqts-05 Reviewer..........: Christian Vogt Review date.......: Nov 15, 2007 IETF LC date : Nov 09, 2007 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: (1) Section 4.1.2, "Multicast Packet Types", says: Since the mapping between IPv4 multicast addresses and Ethernet layer multicast addresses is ambiguous (i.e., multiplicity of 1 Ethernet address to 32 IP addresses), MAC-based multicast forwarding is not ideal for IP multicast. Would be good to provide some rationale here. It seems that the non-injective mapping from IP addresses to MAC addresses does not limit scalability, provided the solution tracks IP addresses rather than MAC addresses. It also does not seem to have an impact on security. The worst that could happen would be that some hosts receive packets they are not interested in. Another undesired feature might be that network administration becomes slightly more complicated. But the reader is left out in the rain here. Giving some rationale would certainly help. (2) Section 4.3, "Backward Compatibility", says: A solution SHOULD be backward compatible with the existing VPLS solution. It SHOULD allow a case where a common VPLS instance is composed of both PEs supporting the solution and PEs not supporting it, and the multicast forwarding enhancement is partially achieved by the compliant PEs. The last sentence here should be "achieved *between* the compliant PEs" because coordination will probably be required between the forwarding side and the receiving side, thus requiring upgrades on both sides. The current text talks about the forwarding side only and so makes the requirement more (IMO too much) ambitious. (3) Section 5.10, "Fate-Sharing...": I don't see a reason for this section's claim that unicast and multicast should always be either both up or both down. The section currently calls for deliberate de-activation of one transmission method in case the other transmission method fails. Is there any reason why a customer or a provider might benefit from such policy? -- I think section 5.10 be removed from the draft. (4) Section 5.6, "Access Connectivity", should IMO be split into an "Access Connectivity" section comprising the currently first paragraph, and a "Multi-Homing" section comprising the rest. (5) Editorial Section 1.1., 6th paragraph: "VPLS PEs" is an unknown acronym at this point. Section 2.1: "- Multicast Channel: (S,G) in the SSM model" -- So "multicast channel" is an SSM-specific term and is undefined for ASM? Section 3.2, 1st paragraph: "ingress PE" -- Is this the U-PE or the N-PE? Section 3.3.1, "Native Ethernet service aspect": s/Their main interest is how to deal with the issue/Their main interest is solve the issue/ Section 3.3.1, "IP multicast service aspect": s/Their main interest is how to provide/Their main interest is to provide/ Section 4.1.1.1: "Issues A and B" appeared long before, so better add a page/section number in parentheses as a reference.