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

["Yuji KAMITE" <[e-mail]>]

Christian,

I haven't got your response yet, but
please let me point out just one thing more to complement the issue (3) you
raised.

> >(3)  Section 5.10, "Fate-Sharing...":

To address your comment, I propose to add a new  parragraph below in this
section (after 4st paragraph).
I think your question was if this requirement has benefit or not, so
I'm trying to clarify that.

"   This policy will benefit customers.
   Some customers would like to detect failure soon at CE side and restore
full
   connectivity by switching over to their backup line, 
   rather than to keep poor half connectivity (i.e., either unicast or
multicast being in fail).
   Even if either unicast or multicast is kept alive, it is just
disadvantageous
   to the customer's application protocols which need both traffic.
   Fate-sharing policy contributes to preventing such a complicated
situation."


Regards,
-Yuji



> -----Original Message-----
> From: Yuji KAMITE [mailto:[e-mail]] 
> Sent: Tuesday, July 22, 2008 5:13 PM
> To: 'Christian Vogt'; 'Gen-ART Mailing List'
> Cc: 'Jari Arkko'; 'Mark Townsley'; 
> [e-mail]; 
> [e-mail]; 'yuichiro wada'
> Subject: RE: 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]
> --------------------------------------------------------------
> -----------------
> 

_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art