[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Multicast in BGP/MPLS IP VPNs

Yetik,

At 01:51 PM 8/18/2004 -0500, Serbest, Yetik wrote: 
Ali,

I would think the following were clear from my previous mails:

1. Improve VPLS to support IP multicast efficiently (not necessarily
optimum)
        1a. do not send traffic to sites with no members
        1b. keep P routers stateless
2. Avoid the complexity of mVPN

Thanks for the clarification. So you don't mind the packet replication at the edge of the core by the n-PE. You had me confused since you mentioned my mvpls draft and that draft talks about PIM and multicast tree in the core.

BTW, what about video or TV multicast applications, you don't mind the replication at the edge.


To me, IGMP/PIM snooping is pretty promising (though not optimum, as there
can still be bw waste). What drawbacks do you see? That is my question I am
waiting an answer for.

We can break the multicast problem into two parts: a) CE-PE relationship and b) forwarding/replication through the network. With respect to (a), I can see that you don't want a peering relationship between CEs and PEs for L2 services and thus snooping can be applied here. But with respect to (b), the drawbacks is that besides inefficiency, it might not be practical. Since you do all the replications at the edge, for large number of n-PEs in a multicast group of a VPLS instance and a number of these instances, you can exhaust n-PE trunk BW or forced to use very high BW interface card (additional cost) where you wouldn't use otherwise.


What I am trying to understand is that why you try to present mVPN as the
only viable solution. It is not magic. You have a default MDT (which sends
traffic to every PE even if they don't have sites connected to them), if
traffic warrants (for instance you have to measure traffic per multicast
group) etc...

I was suggesting the use of mVPN for part (b) of the above - forwarding/replication through the core. With respect to not sending the traffic to all the PEs of a given VPN, a given customer multicast group can have its own tree in the core as the draft suggests for those intensive applications.

-Ali


As for the number of multicast groups per VPLS instance, it can range from 1
to ~350 (let's say 500).

Thanks,
yetik

-----Original Message-----
From: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org] On Behalf Of
Ali Sajassi
Sent: Tuesday, August 17, 2004 5:30 PM
To: Serbest, Yetik; 'Ali Sajassi'; Serbest, Yetik; Yakov Rekhter
Cc: l2vpn at ietf.org; Yakov Rekhter; erosen at cisco.com; l3vpn at ietf.org;
Serbest, Yetik
Subject: RE: Multicast in BGP/MPLS IP VPNs

Yetik,

 From your previous emails, I cannot tell what optimization you would like
to have. So can you list your requirements for your multicast application
with VPLS in terms of:

- optimization in the access network (in case of H-VPLS)
- optimization in the core network (MPLS/IP network)
- optimization at the u-PE & n-PE
- if core optimization needed, then requirement for share-tree versus
source-tree
- number of multicast groups/domains per VPLS instance
- and other requirements that you have in mind

Thanks,
Ali


At 03:59 PM 8/17/2004 -0500, Serbest, Yetik wrote:
>Ali,
>
>I am still looking for an answer to my question. I am trying to weigh the
>alternatives for some specific applications that we consider.
>VPLS and mVPN have their own applicability. For VPLS, we are expecting
>relatively small number of sites per instance. Hence, I am not sure if the
>complexity of mVPN outweighs its benefits.
>
>As for your commonality analysis, they are correct (though you omitted that
>P routers keep states), but that is not what I am asking. An analogy: I am
>asking for a peach pie, you are telling me that you have an apple pie and
>since both varieties mostly have the same ingredients (flour, butter, sugar
>etc...), you are offering me apple pie with peaches added on top.
>
>Thanks,
>yetik
>
>-----Original Message-----
>From: Ali Sajassi [mailto:sajassi at cisco.com]
>Sent: Tuesday, August 17, 2004 1:49 PM
>To: Serbest, Yetik; 'Ali Sajassi'; Yakov Rekhter
>Cc: Serbest, Yetik; Yakov Rekhter; erosen at cisco.com; l3vpn at ietf.org;
>l2vpn at ietf.org
>Subject: RE: Multicast in BGP/MPLS IP VPNs
>
>Yetik,
>
>At 07:44 AM 8/17/2004 -0500, Serbest, Yetik wrote:
> >Ali,
> >
> >I think rosen-mVPN and VPLS have their places in the solution spectrum
>(....
> >Layer-2, Layer-3 ...). I am interested in why we can not use IGMP and/or
>PIM
> >snooping for VPLS to increase the bw and replication efficiency. Is it
> >because they result in state explosion? Is it because they degrade
> >performance? Do they make operations and maintenance troublesome?
>
>If we look at different components needed in the provider network to
>support customer IP multicast efficiently, we can list them as follow:
>
>- auto-discovery for provider multicast tunnel (either PIM or BGP depending
>on PIM mode)
>- signaling to setup provider multicast tunnel (PIM)
>- encapsulation of customer data (either GRE or IP)
>- one MDT per VPN versus one MDT per customer multicast domain per VPN
>
>- forwarding table per VPN (MAC table v.s. routing table)
>- signaling OR snooping of customer's PIM/IGMP
>
>It seems besides the last two items, the rest are in common between L2 and
>L3 implementation. Furthermore, it seems the only major differentiation
>between L2 and L3 is whether PE peers with customer's PIM/IGMP or whether
>it snoops it. So there is lot of commonality for providing multicast
>service in L2 and L3 domain and I was pointing out in my previous email,
>instead of starting from scratch for VPLS, we can leverage the existing
>mVPN and try to see how we can adopt it for VPLS with minimum changes -
>e.g., maybe mVPN draft can be expanded to talk about PIM/IGMP snooping if
>needed.
>
>-Ali
>
>
> >If IGMP and/or PIM snooping is a viable solution, I see well-known
benefits
> >of layer-2 solution: no PIM adjacency with the customer, P routers are
>still
> >dumb etc...
> >
> >Thanks,
> >yetik
> >
> >-----Original Message-----
> >From: Ali Sajassi [mailto:sajassi at cisco.com]
> >Sent: Monday, August 16, 2004 4:36 PM
> >To: Yakov Rekhter; Ali Sajassi
> >Cc: Serbest, Yetik; Yakov Rekhter; erosen at cisco.com; l3vpn at ietf.org;
> >l2vpn at ietf.org
> >Subject: Re: Multicast in BGP/MPLS IP VPNs
> >
> >At 02:00 PM 8/16/2004 -0700, Yakov Rekhter wrote:
> > >Ali,
> > >
> > > > >I think we should optimize VPLS for support of IP multicast. For
> >instance,
> > > > >what am I going to do for the regional networks where I don't sell
> > > 2547? Do
> > > > >I have to backhaul everybody to National backbone to provide
>multicast
> > > > >support?
> > > >
> > > >
> > > > I was implying in my previous message that the multicast service can
>be
> > > > considered as an independent service and it doesn't need to be tied
up
> >to
> > > > other services such as VPLS or L3VPN (unicast). So a customer can
>order
> >it
> > > > in conjunction with its VPLS or L3VPN service or separately. Now if
>the
> > > > question is: what the best way is to implement it, then that depends
>on
> > > the
> > > > requirements and if the requirements is for IP multicast
applications
> >with
> > > > optimum routing & replication through the core, then the
>rosen-vpn-mcast
> > > > discusses several options and pros/cons for these different options
> >which
> > > > addresses adjacency between CEs & PEs (c-address/group) as well as
>among
> > > > PEs (p-address/group). And a VPLS capable PE (or at least an n-PE)
>that
> > > > needs to support multicast service in conjunction with VPLS, can do
it
> > > > using vpn-mcast (and that doesn't mean it has to provide
l3vpn-unicast
> > > > service to the customer).
> > > >
> > > > However, if there are different set of requirements that are not met
>by
> > > > vpn-mcast, then we can go over them and see what to do to meet them.
> > >
> > >Why would requirements to support IP multicast with 2547 be any
different
> > >than the requirements to support IP multicast with VPLS ?
> >
> >  From IP multicast user/application perspective, I cannot see why there
> >should be any difference and that is why I am suggesting vpn-mcast
> >mechanism to be leveraged here. However, I was raising a more general
> >question that if some providers have special requirements that are not
> >already addressed by vpn-mcast and are specific to VPLS applications,
then
> >they can bring them up and we can collectively evaluate them.
> >
> >-Ali
> >
> >
> > >Yakov.