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

From: "Prabakaran T Sampath" <[email-masked]>
Date: Fri, 11 Feb 2005 16:34:17 +0530

Hi Venkat,

Thanks for your wishes.

Please see my inlined<Prabakaran T.S.> reply.

Best regards,
Prabakaran T.S.
FutureSoft, a Flextronics company,
480-481 Anna salai,
Nandanam,
Chennai-600035. INDIA.
Ph: +91-44-24330550, extn: 459

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, 11 February 2005 3:54 PM
To: [email-masked]; [email-masked]
Subject: RE: I-D ACTION:draft-praba-l2vpn-vpls-mcast-emul-00.txt

Hai ,

First of all...congratulations for doing a wonderful work....

I have a few doubts. If i understand correct...

1. This draft is a substitute for draft-serbest-l2vpn-vpls-mcast-01.txt
where same issue is addressed using
     multicast protocols (IGMP and PIM). Is that right ?
<Prabakaran T.S.> This draft is not a substitute for the
draft-serbest-l2vpn-vpls-mcast-01.txt.
The IGMP and PIM snooping protocol require examining each packet to
perform the snooping function and this approach avoids that.

2. In you draft, how do you support dynamic join/leave of multicast group.
What i mean is, suppose a node is not interested in multicast traffic
anymore and wants to leave the group. How will it be taken care ? If i
understand correct this will result in a LDP notification message with "MF
emulation enable bit and MF un-register bit fields set " to the originator
peer. Is that right?

<Prabakaran T.S.> Yes, you are correct.  Here we are controlling the
multicast data
flooding on the PWs using the MF emulation enable bit and MF un-register
bit fields set/reset.  Thus we are emulating the multicast group
join/leave per vpls instance.

3. And in what way is your proposal superior to the one proposed in
draft-serbest-l2vpn-vpls-mcast-01.txt  ?
    Nothing to offend your idea. But just wanted to know the positives since
i have two options available now.

<Prabakaran T.S.>  Our proposal will be very much useful in a place where
the L2 switches were not interested in running IGMP and PIM
or any other multicast protocol stacks.  Basically, we are
reducing the over head of multicast protocol stack operations to
perform the basic filtering of multicast flooding onto the PWs.
Also, both drafts can be implemented without any harm,
but our aim is the IGMP and PIM snooping protocol require
examining each packet to perform the snooping function
and this approach avoids that.

thanks
Venkat

________________________________

From: [email-masked] on behalf of Prabakaran T Sampath
Sent: Fri 2/11/2005 12:52 PM
To: [email-masked]
Subject: FW: I-D ACTION:draft-praba-l2vpn-vpls-mcast-emul-00.txt

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: [email-masked]
[mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Friday, 11 February 2005 2:18 AM
To: [email-masked]
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
[email-masked] 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:
        [email-masked].
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.

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

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