Subject: Re: FW: I-D ACTION:draft-praba-l2vpn-vpls-mcast-emul-00.txt

From: [email-masked]
Date: Wed, 4 May 2005 20:41:36 +0530 (IST)

Hi Vipin,

Sorry for the delayed reply, some how I missed this mail in my Inbox, just
now found in the mailing-list and replying.  I have updated the draft into
draft-praba-l2vpn-vpls-mcast-emul-01.txt.

Please see my inlined reply <Prabakaran TS>.
Thanks for your comments.

Best regards,
Prabakaran T.S.

Two comments, based on my understanding of the draft so far:
- Why not allow register/deregister per multicast address. Without that, it
would be either all or none of the multicast traffic getting forwarded on PE
for a given VPLS instance. I mean, isn't that a severe limitation?

<Prabakaran T.S.> Please note that we are not using any multicasting
protocol to do the required filtering operation. The main aim of the draft
is to avoid flooding of multicast traffic in all the PWs and it is
independent/transparent of any multicast addresses. Our draft
implementation will be more useful in the switches where there is no need
of running multicast protocols to do the simple multicast data filtering
operation on the PWs which are all not interested in the mesh topology. 
As you said, this is not a limitation for the given VPLS instance, this is
a limitation for the particular PW in the VPLS instance which enabled this
filter, not to all PWs in the VPLS instance.  More over our assumption is
whenever the user wants to enable/disable our filter, they can very well
does through configurations, the corresponding LDP Notification messages
will be send to the peer and enables the required operation.

- VPLS keeps the layer2 transparency as much as possible. Introducing the
configuration you propose requires explicit knowledge of customer, whose data
is being subjected to this constraint. Do you agree? On other hand, I see
snooping mechanism independent of any such customer agreement/interaction.

<Prabakaran T.S.> I know that VPLS keeps the layer2 transparency(which may
be an advantage/disadvantage, I don't know how to comment) but this is a
kind of proposal came up because of this transparency to avoid multicast
flooding on all the PWs which are all not interested at a given point.

Our aim is to avoid the over head of Snooping mechanism in all the PE's
and to reduce the overhead of running any multicast protocols and to make
use of existing LDP signalling itself to perform the multicast data
filtering. Our proposal will be much helpful, easy to implement, no
complexity and a very simple implementation in the places where the
switches don't want to add multicast protocol running over heads.

thanks,
-- vipin

--- Prabakaran T Sampath <prabakarts at future.futsoft.com> wrote:

> Dear L2VPN-WG,
>
> This is Prabakaran T.S. and Musthafa A.S. from FutureSoft, a Flextronics
> company.
> We have come up with some concept and contributed it as a IETF
> draft in VPLS. Kindly go through this draft
> and give us your valuable comments and feedback either in
> IETF VPLS working group or directly to us by email.
>
> Thanks in advance,
>
> Best regards,
> Prabakaran T.S.
> Musthafa A.S.
> FutureSoft, a Flextronics company,
> 480-481 Anna salai,
> Nandanam,
> Chennai-600035. INDIA.
> Ph: +91-44-24330550, extn: 459
>
>
> -----Original Message-----
> From: i-d-announce-bounces at ietf.org
> [mailto:i-d-announce-bounces at ietf.org]On Behalf Of
> Internet-Drafts at ietf.org
> Sent: Friday, 11 February 2005 2:18 AM
> To: i-d-announce at ietf.org
> Subject: I-D ACTION:draft-praba-l2vpn-vpls-mcast-emul-00.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Multicast Emulation over VPLS
> 	Author(s)	: Prabakaran T.S, Musthafa A.S
> 	Filename	: draft-praba-l2vpn-vpls-mcast-emul-00.txt
> 	Pages		: 14
> 	Date		: 2005-2-10
>
> In Virtual Private LAN Service (VPLS), the PE devices provide a
>    logical interconnect such that CE devices belonging to a specific
>    VPLS instance appear to be connected by a single LAN.  A VPLS
>    solution performs replication for multicast traffic at the ingress
>    PE devices.  When replicated at the ingress PE, multicast traffic
>    wastes bandwidth when 1. Multicast traffic is sent to sites with no
>    members, and 2. Pseudo wires to different sites go through a shared
>    path. This document addresses the above cases by using LDP
>    signaling to emulate Multicast operation over VPLS with out using
>    IGMP and PIM snooping as described in [VPLS-MCAST].
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-praba-l2vpn-vpls-mcast-emul-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request at ietf.org with the word unsubscribe in the body
of the
> message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-praba-l2vpn-vpls-mcast-emul-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	mailserv at ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-praba-l2vpn-vpls-mcast-emul-00.txt".
>
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

> ATTACHMENT part 2 message/external-body name=ATT00108.dat

> ATTACHMENT part 3 message/external-body
name=draft-praba-l2vpn-vpls-mcast-emul-00.txt
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce at ietf.org
> https://www1.ietf.org/mailman/listinfo/i-d-announce

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************