Subject: RE: [mpls] FW: I-D ACTION:draft-praba-l2vpn-vpls-mcast-emul-01.txt

From: "Vijayanand C - CTD, Chennai." <[email-masked]>
Date: Thu, 31 Mar 2005 13:38:01 +0530

One more query inline

> -----Original Message-----
> From: Prabakaran T Sampath [mailto:[email-masked]]
> Sent: Thursday, March 31, 2005 1:30 PM
> To: 'Vijayanand C - CTD, Chennai.'; [email-masked]
> Subject: RE: [mpls] FW: I-D
> ACTION:draft-praba-l2vpn-vpls-mcast-emul-01.txt
> 
> 
> Hi Vijay,
> 
> Please see my in-lined reply <Prabakaran TS>.
> 
> Thanks and regards,
> Prabakaran T.S.
> FutureSoft, a Flextronics company,
> 480-481 Anna salai,
> Nandanam,
> Chennai-600035. INDIA.
> Ph: +91-44-24330550
> 
> -----Original Message-----
> From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
> Sent: Thursday, 31 March 2005 12:29 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [mpls] FW: I-D
> ACTION:draft-praba-l2vpn-vpls-mcast-emul-01.txt
> 
> 
> I have a few questions on this draft.
> 
> You seem to be sending multicast unregister information 
> through a status TLV
> in the notification message.
> 
> <Prabakaran TS> You are correct we can send the multicast un-register
> information through status TLV in the notification message or in the
> initial label mapping messages itself.
> 
> if the peer PE does nt support this feature
> this might be silently ignored and unwanted multicast traffic 
> may still be
> sent to the peer whos not interested in it.
> 
> <Prabakaran TS> Yes, you are correct, if the peer doesn't support this
> feature then the status TLV 'll be silently ignored and the peer 'll
> act with the existing default VPLS behavior(flooding all 
> Multicast traffic
> onto the PWs).
> 
> Is there any provision for a PE
> to notify this and/or withdraw labels it has sent or any 
> other measure to
> stop receiving such unwanted traffic.
> 
> <Prabakaran TS> Our draft proposes one solution to stop receiving such
> unwanted traffic by sending MF flow unregister information in
> notification/initial
> label mapping messages. So, we strongly RECOMMENDED that the 
> PW MF status
> TLV
> signaling procedures said in our draft be fully implemented 
> in the VPLS
> domain
> to stop flooding unwanted multicast traffic onto the PWs.
> 
>><vijayc>  I understand that if all routers implement this then what you
are saying is possible.
BUt this may not happen most of the time.In that case, do you have provision
on your own PE( the one which implements your feature), to either withdraw
labels to peer or to terminate sessions etc. Receiving and processing
unwanted multicast traffic  could increase load on the forwarding instance
and reduce its performance for desired traffic. I think it would be better
to withdraw labels or do some such thing, this would really satisfy the
intention of your proposal. Or, would it be better to signal this capability
at the time of seesion establishment and decide based on local policy
whether or not to establish session with peers who dotn supprot this feature
?

> It is not clear how multiple instances handled in the signalling.
> <Prabakaran TS> Multiple instances are inherently taken care during
> signalling.
> 
> Vijay
> 
> > -----Original Message-----
> > From: Prabakaran T Sampath [mailto:[email-masked]]
> > Sent: Thursday, March 31, 2005 12:16 PM
> > To: [email-masked]
> > Subject: [mpls] FW: I-D
> > ACTION:draft-praba-l2vpn-vpls-mcast-emul-01.txt
> >
> >
> > Dear MPLS-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. This draft basically deals with LDP signalling
> > so sending it to MPLS-WG. Kindly go through this draft
> > and give us your valuable comments and feedback either in
> > 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
> >
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of
> > [email-masked]
> > Sent: Thursday, 31 March 2005 2:08 AM
> > To: [email-masked]
> > Subject: I-D ACTION:draft-praba-l2vpn-vpls-mcast-emul-01.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> > 	Title		: Multicast Emulation over VPLS
> > 	Author(s)	: Prabakaran. Ts, Musthafa. As
> > 	Filename	: draft-praba-l2vpn-vpls-mcast-emul-01.txt
> > 	Pages		: 14
> > 	Date		: 2005-3-30
> >
> > 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-mca
> > st-emul-01.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-01.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-01.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.
> > **************************************************************
> > *************
> >
> >
> DISCLAIMER
> This message and any attachment(s) contained here are 
> information that is
> confidential, proprietary to HCL Technologies
> and its customers. Contents may be privileged or otherwise 
> protected by law.
> The information is solely intended for the
> individual or the entity it is addressed to. If you are not 
> the intended
> recipient of this message, you are not authorized to
> read, forward, print, retain, copy or disseminate this 
> message or any part
> of it. If you have received this e-mail in error,
> please notify the sender immediately by return e-mail and 
> delete it from
> your computer
> 
> 
> 
> 
> **************************************************************
> *************
> 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.
> **************************************************************
> *************
> 

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Prabakaran T Sampath" <[email-masked]>
Date: Thu, 31 Mar 2005 18:41:18 +0530

Hi Vijay,

Please see my in-lined reply >><Prabakaran TS>.

Thanks and regards,
Prabakaran T.S.

-----Original Message-----
From: Vijayanand C - CTD, Chennai. [mailto:[email-masked]]
Sent: Thursday, 31 March 2005 1:38 PM
To: [email-masked]; 'Vijayanand C - CTD, Chennai.';
[email-masked]

One more query inline

are saying is possible.
BUt this may not happen most of the time.In that case, do you have provision
on your own PE( the one which implements your feature), to either withdraw
labels to peer or to terminate sessions etc.

>><Prabakaran TS> As off now we do not have any such provisions to withdraw
labels to peer or to terminate sessions. Because our intention is not to
disturb the existing VPLS implementation and PW LDP signaling.  This feature
is proposed keeping the transparency and it should go into the system
without disturbing the existing VPLS behaviour so that the interoperation
or any existing functional behaviour should not get affected.

Receiving and processing
unwanted multicast traffic  could increase load on the forwarding instance
and reduce its performance for desired traffic.
>><Prabakaran TS> Yes, you are correct, to reduce this overhead only we
proposed this solution.

I think it would be better
to withdraw labels or do some such thing, this would really satisfy the
intention of your proposal.
>><Prabakaran TS> We can not withdraw the labels, because the labels are
tied with PWs, the same PW can be used for normal unicast traffic too.
So, we can should not withdraw the labels.  Our intention is not to disturb
the existing implementation of VPLS and its default behaviour.

Or, would it be better to signal this capability
at the time of seesion establishment and decide based on local policy
whether or not to establish session with peers who dotn supprot this feature
?
>><Prabakaran TS> Actually, we are signaling this capability
in the Label mapping message and it is specific to particular PW,
we don't want to disturb the session, as this violates the existing
VPLS default behaviour!?  If one wants to have local policy,
they can very well have as per their specific requirement which
is outside of the scope of this feature draft.

> please notify the sender immediately by return e-mail and

***************************************************************************

***************************************************************************