Re: Multicast in BGP/MPLS IP VPNs

[Yiqun Cai <ycai at cisco.com>]

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

Yetik,

If what you refer to as MVPN is what is specified by draft-rosen, then
MVPN and VPLS address different problem spaces.  In MVPN, PE and CE
maintain L3 adjacency.  In VPLS, they don't.  If you want to use VPLS
to solve problems where PE and CE maintain L3 adjacency, you will
likely run into more problems (e.g., non-congruent topologies).  It
might be easier if one just builds CE-CE GRE tunnels...

In terms of extending VPLS to support IP multicast traffic, I think it
is a pretty good, but non-trivial idea.  In terms of achieving the
goal of "stateless P routers", I think we first need to define what it
is, and then I will repeat my rant in an earlier email ;)

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


-- 
Yiqun