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

From: "Yuji KAMITE" <[email-masked]>
Date: Tue, 22 Jul 2008 17:12:52 +0900

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

Subject: Gen-ART Review of draft-ietf-l2vpn-vpls-mcast-reqts-05
From: "Christian Vogt" <[email-masked]>
To: "Gen-ART Mailing List" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Jari Arkko" <[email-masked]>, "Mark Townsley" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Fri, 16 Nov 2007 00:14:15 +0900

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document..........:  draft-ietf-l2vpn-vpls-mcast-reqts-05
Reviewer..........:  Christian Vogt
Review date.......:  Nov 15, 2007
IESG Telechat date:  --

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.

Hope this helps.
- Christian

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

---

From: "Yuji KAMITE" <[email-masked]>
Date: Sun, 27 Jul 2008 18:12:23 +0900

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:[email-masked]] 
> Sent: Tuesday, July 22, 2008 5:13 PM
> To: 'Christian Vogt'; 'Gen-ART Mailing List'
> Cc: 'Jari Arkko'; 'Mark Townsley'; 
> [email-masked]; 
> [email-masked]; 'yuichiro wada'
> Subject: RE: Gen-ART Review of draft-ietf-l2vpn-vpls-mcast-reqts-05
> 
> 
> Hi Christian,
> 
> see  my clarification about it (see below).  And then I'd 
> like to hear your thoughts more.
> 
> Best regards,
> Yuji
> 
> >                                             Since the 
> mapping between
> >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]
>    that the network administration becomes slightly more 
> complicated." [/YK]
> 
> 
> >
> >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.
> >
> 
> >I don't see a reason for this section's claim that unicast and 
> >multicast should always be either both up or both down.
> >
> >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] 
>  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.
> 
>  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.
> 
> modified more specifically? [/YK] 
> 
> 
> >
> >"Access Connectivity" section comprising the currently first
>    when a CE sends (1) Broadcast, (2) Multicast or (3) 
> Unknown destination unicast. " [/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.
>