Re: [Gen-art] Gen-ART Review of draft-ietf-l2vpn-vpls-mcast-reqts-05

Hi Christian,

I'm planning changes based on your Gen-ART Reviews (attached email). 
See my response in [YK] part written below and please tell me if it is OK.

Regarding your 3rd comment   (about section 5.10),  please
see  my clarification about it (see below).  And then I'd like to
hear your thoughts more.

Best regards,
Yuji

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

[YK]
OK.  Could I modify this 1st paragraph as follows?
I think this will cover the rationale:

  "Ethernet multicast is used for conveying Layer-3 multicast data.
   When IP multicast is encapsulated by an Ethernet frame, the IP
   multicast group address is mapped to the Ethernet destination MAC
   address.  In IPv4, the mapping uses the lower 23 bits of the (32bit)
   IPv4 multicast address and places them as the lower 23 bits of a destination
   MAC address with the fixed header of 01-00-5E in hex. 
   Since this mapping is ambiguous (i.e., there is a multiplicity of 1 Ethernet
   address to 32 IPv4 addresses), MAC-based forwarding is not ideal for IP multicast
   because some hosts might possibly receive packets they are not interested in, which
   is inefficient in traffic delivery and has an impact on security.
   On the other hand, if the solution tracks IP addresses rather than MAC addresses,
   this concern can be prevented.  The drawback of this approach is, however,
   that the network administration becomes slightly more complicated."
[/YK]

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

[YK] Agreed.  I'll change it in the following:

     ".......... 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 optimization (both forwarding and receiving) is achieved
     between the compliant PEs."
[/YK]

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

[YK] 
Please let me clarify the reason why this rquirement is raised:

 A solution may adopt MD Tunnels (multicast distribution tree tunnels)
 in the SP's backbone to solve issue (B) of section 3.2.
 This tunnel is dedicated to convey multicast traffic
 for bandwidth optimization in the core.  Customer's unicast frames are
 still conveyed by the existing unicast tunnel.

 By the way, In native Ethernet, 802.1ag CFM Continuity Check (CC)
 message is forwarded as multicast frame (i.e., destination MAC is
 multicast address).

 In a multicast VPLS (solution)'s environement, suppose the CC message is
 conveyed by MD Tunnel in the SP's core.  If there happens a failure in
 a unicast tunnel in the backbone, but MD Tunnel is working fine, then
 customer cannnot detect the failure correctly because CC messages are still
 received by downstream CE through MD Tunnel.

 (This point also applies to other ethernet protocols that are used to
  detect failure (such as BPDU hello in spanning tree)).

 However, if you allow a solution to deliberately de-activate multicast
 when the unicast has a failure, customers can detect the failure soon.
 So this requirement aims at being free from complicated fault situation.  

 Some customers would like to detect failure soon rather than keeping poor
 and half reachability, if they have some countermeasures (e.g., backup line).
 Hence this section reaises such a requirement.

Does this make sense?  Or could you suggest points to be
modified more specifically?
[/YK] 

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

[YK]
 Agreed.  Will be simply splitted as follows:

" 5.6.  Access Connectivity

     First and foremost various physical connectivity types described in
     [RFC4665] MUST be supported.

  5.7. Multi-Homing

     A multicast VPLS MUST allow a situation in which a CE is dual-homed
     to two different SPs via diverse access networks -- one is supporting
     multicast VPLS but the other is not supporting it, (because it is an
     existing VPLS or 802.1Q/QinQ network).    "
[/YK]

>
>
>(5)  Editorial
>
>Section 1.1., 6th paragraph:  "VPLS PEs" is an unknown acronym at this point.

[YK]
OK.
 s/VPLS PEs/PEs (Provider Edges) in VPLS /

Additionally, in the same paragraph, I'll correct:
 s/ P / P (Provider Router) /

Also, In section 2.1, 
  "- PE/CE:  Provider/Customer edge Equipment"
 Let me correct these acronyms to conform it to RFC4026:
   "- CE: Customer Edge Device 
    - PE: Provider Edge
    - P:  Provider Router       "
[/YK]

>
>Section 2.1:  "- Multicast Channel:  (S,G) in the SSM model" -- So "multicast channel" is an SSM-specific term and is undefined for
ASM?

[YK]
  I'll replace it with:

   " - Multicast Channel:  
        In the multicast SSM model [RFC4607], a "multicast channel"
        designates traffic from a specific source S to a multicast group
        G.  Also denominated as "(S,G)".
   "
[/YK]

>
>Section 3.2, 1st paragraph:  "ingress PE" -- Is this the U-PE or the N-PE?

[YK]
  Correct as follows:

   "...In VPLS, replication occurs at an ingress PE (in H-VPLS case, at N-PE) 
   when a CE sends (1) Broadcast, (2) Multicast or (3) Unknown destination unicast. "
[/YK]

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

[YK]
 Agreed.  
[/YK]

>
>Section 3.3.1, "IP multicast service aspect":  s/Their main interest is how to provide/Their main interest is to provide/

[YK]
 Agreed.  
[/YK]

>
>Section 4.1.1.1:  "Issues A and B" appeared long before, so better add a page/section number in parentheses as a reference.
>

[YK]
 OK.

 s/ issues A and B / issues A and B (see section 3.2.) 
[/YK]
-------------------------------------------------------------------------------