Re: OT: NG Multicast VPN

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

Blogs and organic groups at http://www.ccie.net
Received on Wed Nov 02 2011 - 22:33:11 ART