Subject: RE: Extension to LDP-VPLS for Ethernet Broadcast and Multicast

From: [email-masked]
Date: Tue, 14 Sep 2010 20:02:51 +0800

Hi Simon, Nicolai,
I don't think the first point of motivation in section 2.2 is very 
convicing. Can you give an traffic example of "no L3 data to snoop" in 
VPLS?
What's more, for the third point, does that mean the proposed solution can 
only support the case that multicast topology will not change with a 
customer's multicast routing? And the multicast topology MUST be 
preconfigured by the operator?

BR
Lizhong Jin

> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 13 Sep 2010 11:00:41 +0200
> From: <[email-masked]>
> Subject: RE: Extension to LDP-VPLS for Ethernet Broadcast and
>    Multicast
> To: <[email-masked]>,   <[email-masked]>,   <[email-masked]>
> Message-ID:
>    <[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi,
> 
> I do have some comments on the draft. 
> 
> - L2 vs. L3 issue and Motivation 
>   I think this depends on the use case. In order to optimize the 
> network (especially
>   with large flows in a typical IPTV deployment) its necessary to do
> L3 snooping 
>   (see above) but I know that there are some use cases, where the 
> use of L3 information
>   is critical. The need for increeasing ressources for state 
> information is the typical
>   tradeof compared to increasing bandwidth.
> 
>   From our point of view it is highly preferable (required) that a 
> scalable solution 
>   is able to work based on L3 information (at least to create the 
forwarding 
>   states/trees and to map the IP Multicast traffic based on (S,G) to
> the trees).
>   This behaviour should be flexible (we have also a requirement that
> we want the 
>   typical broadcast model for a subset of multicast groups in order to
>   be able to optimize join latencies for those groups).
>   In addition, Source Specific Multicast only works well with L3 
> based information. 
> 
> - Control Plane Traffic
>   Depending on the deployment scenario it might be necessary to send
> Control Plane
>   packets (e.g. IGMP Messages) only from the source(s) towards the 
> leaves and only
>   from leaves towards source(s) (but not no other leaves).
> 
> Please let me know what you think.
> 
> 
> Kind regards
> Nicolai Leymann
> 
> 
> 
> 
> 
> Deutsche Telekom Netzproduktion GmbH
> Fixed Mobile Engineering Germany
> Nicolai Leymann
> Winterfeldtstra?e 21-27, 10781 Berlin, Germany
> +49 30 8353-92761 (Phone)
> +49 30 8353-92759 (Fax)
> +49 170 2275345 (Mobile)
> E-Mail: [email-masked]
> www.telekom.de
> 
> Life is for sharing.
> 
> Deutsche Telekom Netzproduktion GmbH
> Supervisory Board: Dr. Steffen Roehn (Chairman)
> Board of Management: Dr. Bruno Jacobfeuerborn (Chairman), Albert 
> Matheis, Klaus Peren
> Commercial register: Amtsgericht Bonn HRB 14190
> Registered office: Bonn
> VAT identification no. DE 814645262
> 
> 
> 
> Big changes start small - conserve resources by not printing every 
e-mail.
> 
> 
> 
> 
>   _____ 
> 
> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von Simon Delord
> Gesendet: Mittwoch, 8. September 2010 12:14
> An: [email-masked]
> Betreff: I-D: Extension to LDP-VPLS for Ethernet Broadcast and Multicast
> 
> 
> Hi L2VPN working group,
> 
> We have just updated "Extension to LDP-VPLS for Ethernet Broadcast 
> and Multicast"
> 
http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-02
> 
> This draft takes a pragmatic approach to the broadcast/multicast 
bandwidth
> efficiency problem in LDP-VPLS and proposes a simple solution for 
certain
> common deployment scenarios. Section 2.2. Motivation talks about the
> rationale.
> 
> We believe this simple solution will be applicable to a majority of 
LDP-VPLS
> network, and can be complementary to the BGP-based solution in
> draft-ietf-l2vpn-vpls-mcast-07.
> 
> Grateful if you could review and collaborate on the mailing list, 
ordirect to
> the authors. In particular, we are keen to have feedback on the 
following,
> - From an operator perspective, whether the Section 2.2. Motivation 
makes
>   sense or not, applicable to your real environment or not
> - From a vendor perspective, whether the proposed solution is feasible 
or
>   not, any difficult hurdle in developing such a solution
> 
> Many thanks
> 
> Simon
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/l2vpn/attachments/20100913/9520a4e8/attachment.htm>
> 
> ------------------------------
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: <[email-masked]>
Date: Tue, 14 Sep 2010 14:58:55 +0200

Hi,
 
I think there are some scenarios (e.g. in Japan) were it is not allowed
to snoop IGMP messages 
(even if the information is there). This should ensure that nobody knows
who is receiving a certain 
channel - therefore receivers are anonymous (in addition to scenarios
where no control plane is
available and traffic is simply broadcasted to all receivers).
 
There is no need that the topology MUST be preconfigured.
 
   regards
 
      Nic

  _____  

Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Dienstag, 14. September 2010 14:03
An: [email-masked]
Cc: Leymann, Nicolai; [email-masked]; [email-masked]
Betreff: RE: Extension to LDP-VPLS for Ethernet Broadcast and Multicast

Hi Simon, Nicolai, 
I don't think the first point of motivation in section 2.2 is very
convicing. Can you give an traffic example of "no L3 data to snoop" in
VPLS? 
What's more, for the third point, does that mean the proposed solution
can only support the case that multicast topology will not change with a
customer's multicast routing? And the multicast topology MUST be
preconfigured by the operator? 

BR 
Lizhong Jin 

forwarding 
e-mail.
> We have just updated "Extension to LDP-VPLS for Ethernet Broadcast 
http://tools.ietf.org/html/draft-delord-l2vpn-ldp-vpls-broadcast-exten-0
2
bandwidth
certain
LDP-VPLS
ordirect to
following,
makes
or

ZTE Information Security Notice: The information contained in this mail
is solely property of the sender's organization. This mail communication
is confidential. Recipients named above are obligated to maintain
secrecy and are not permitted to disclose the contents of this
communication to others.

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
originator of the message. Any views expressed in this message are those
of the individual sender.

This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.

---

From: [email-masked]
Date: Wed, 15 Sep 2010 08:52:32 +0800

Hi Nic and all,
Thank you for the information. And maybe more precisely saying, the leaf 
of P2MP PW within VPLS should be manually configured by operator in this 
proposal, right?

BR
Lizhong

<[email-masked]> wrote on 2010-09-14 20:58:55:

> Hi,
> 
> I think there are some scenarios (e.g. in Japan) were it is not 
> allowed to snoop IGMP messages 
> (even if the information is there). This should ensure that nobody 
> knows who is receiving a certain 
> channel - therefore receivers are anonymous (in addition to 
> scenarios where no control plane is

VPLS? 
> What's more, for the third point, does that mean the proposed 
> solution can only support the case that multicast topology will not 
> change with a customer's multicast routing? And the multicast 
> topology MUST be preconfigured by the operator? 
> 
> BR 
> Lizhong Jin 
> 
> 
e-mail.
bandwidth
certain
LDP-VPLS
following,
makes
or

> ZTE Information Security Notice: The information contained in this 
> mail is solely property of the sender's organization. This mail 
> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 
> notify the originator of the message. Any views expressed in this 
> message are those of the individual sender.
system.

---

From: [email-masked]
Date: Tue, 21 Sep 2010 23:05:50 +0800

Hi, all
One more comment for the following text:
   For the flooding of an Ethernet broadcast/multicast frame over PWs to
   remote PEs participating in the VPLS:

        - If there is P2MP PW towards a remote PE, the P2P PW
          associated with this remote PE will not be used. One copy
          of the frame will be forwarded on the P2MP PW for all the
          remote PEs associated with it.
        - If there is no P2MP PW towards a remote PE, the P2P PW
          associated with this remote PE is used.

If the P2MP PW only connects part of PE members who are the multicast 
frame receivers, then the second forwarding rule should not be applied to 
these multicast frame, right? And the first forwarding rule is also not 
very correct, it should be simply that these kind of multicast frame 
should be forwarded to corresponding P2MP PW.

BR
Lizhong

<[email-masked]> 
2010-09-14 20:58

To
<[email-masked]>, <[email-masked]>
cc
<[email-masked]>, <[email-masked]>
Subject
AW: Extension to LDP-VPLS for Ethernet Broadcast and Multicast

Hi,
 
I think there are some scenarios (e.g. in Japan) were it is not allowed to 
snoop IGMP messages 

   regards
 
      Nic

Hi Simon, Nicolai, 

BR 
Lizhong Jin 

forwarding 
e-mail.
bandwidth
certain
LDP-VPLS
ordirect to
following,
makes
or

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.