Re: OT: NG Multicast VPN

Thanks a lot Petr.

Always Brilliant:)

On Thu, Nov 3, 2011 at 6:33 AM, Petr Lapukhov
<petr_at_internetworkexpert.com>wrote:

> Karim,
>
> First of all, the best read on the topic is
> draft-ietf-l3vpn-2547bis-mcast - it's not an easy to digest document,
> but that's the only definitive source. You may need to go over it a
> few times, but it might be worth reading if you are really into the
> subject :) Also, Juniper should have a bunch of white papers on the NG
> MVPN, as they were pushing the concept aggressively :)
>
> In short, NG MVPN was, and still is, an ongoing effort to "generalize"
> Multicast VPN service and get rid of "kludges" found in Draft-Rosen.
> Not to mention the political reasons that Juniper had on mind ;) In a
> few words, the main technical problems with Draft-rosen MVPNs were as
> following:
>
> 1) Data plane implementation is IP GRE, not "abstract" MPLS, which
> limits "general" application E.g. there is no way to support GMPLS,
> though who case about that today :). The whole late 90's early 2000's
> era was high on the MPLS drug, definitely much more than it should
> have been.
> 2) Control plane implementation for MVPN was one huge hack, just to
> get the work done quickly :)
> 2.1) Core tree and tunnel signaling was superimposed on P-PIM
> instances. There were some hacks for Inter-AS mVPNs and PIM-SSM but
> they looked weird (check out the RPF Proxy and Connector attribute for
> some fun :)
> 2.2) Client multicast tree signaling is effective superimposed on
> C-PIM process running over MTI. And the full-mesh of soft-state PIM
> adjacencies obviously has limited scalability.
> 2.3) RPF check was a hack based on VPNv4 next-hops matching against
> PIM neighbors over MTI. RPF checks were effectively performed on
> unicast only information. BGP Connector attribute did not help much
> with the problem, but added some confusion :)
> 2.4) Something else? Feel free to add!
>
> So while trying to solve the above "little problems", folks have
> bumped into the following major issues:
>
> Data Plane: MPLS abstraction worked fine for P2P (and MP2P to some
> extent) connections, but generalizing it to P2MP LSPs became a
> problem. Two LSP signaling protocols: LDP and RSVP-TE were picked up
> for extensions (lead by Cisco and Juniper respectively) and obviously,
> the results were very different. The RSVP-TE was first one to see
> production (and it fit into traffic-engineering framework!), and even
> though it works, anyone who looked at the signaling overhead for M-LSP
> establishment would agree it's far from being nice and pretty.
>
> M-LDP looks much cleaner, but it was probably late to the party, and
> it wasn't too good for "MPLS Traffic Engineering Snobs" ;)
> Nonetheless, it seems to be gaining some momentum, obviously on Cisco
> gear. BTW you can toy with it using 7200 Dynamips images, btw, as well
> as with RSVP-TE M-LSPs, as cisco has been supporting them for quite a
> while.
>
> Control Plane: PIM-SM protocol design sucks, plain and simple :) The
> amount of asymmetrical design choices and intertwining between control
> and data plane was bad enough to make it hard to implement it in
> hardware effectively. Now gracefully add the requirement to
> "interwork" this complex signaling with MP-BGP model to construct P
> and C trees (+other goodies such as inter-AS trees), and you'll
> quickly get an acronym explosion problem :)
>
> Next problem - you need to map the PIM constructed multicast trees to
> M-LSPs in the data plane. Needless to say it's not going to be as nice
> and easy as recursive next-hop resolution :) Look at the amount of
> extensions added to MP-BGP for NG MVPNs, and you'll probably be scared
> by as how complex the software implementation may be. Oh yes, and if
> you look at the draft document I mentioned in the beginning, you will
> see how far they went in generalization :)
>
> Is there a simpler solution? I would say "scrap all that multiprotocol
> stuff and start clean" but it's not possible. We have to live with
> MPLS, LDP, RSVP-TE and IP tunneling, etc and life is not getting
> easier. There were attempts to get a prettier design, such as M-LDP
> signaled M-LSPs + in-band PIM message translation as described in
> draft-ietf-mpls-mldp-in-band-signaling. Would industry converge on a
> single simple solution? Of course not ;)!
>
> --
> Petr Lapukhov, petr_at_INE.com
> CCIE #16379 (R&S/Security/SP/Voice)
> CCDE #20100007
>
> Internetwork Expert, Inc.
> http://www.INE.com
> Toll Free: 877-224-8987
> Outside US: 775-826-4344
>
>
>
> 2011/11/2 Karim Jamali <karim.jamali_at_gmail.com>:
> > Dear Experts,
> >
> > I have been trying to go through Multicast Enabled Applications book
> mainly
> > the Multicast VPNs where both the Draft Rosen & the Next Generation
> > Multicast VPN (BGP/MPLS) however wasn't able to fully digest those.
> >
> > Anyone can share a good reference document where both models are
> explained
> > in full detail.
> >
> > Thanks
> >
> > --
> > KJ
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
> >
>

-- 
KJ
Blogs and organic groups at http://www.ccie.net