[c-nsp] pros and cons for IPTV multicast in rosen-mvpn vs GRT

[Mark Tinka]

On Monday, February 18, 2013 10:19:17 PM Sigurbjörn Birkir 
Lárusson wrote:

> The implementation of draft-rosen on the 7600 is very
> quirky and it has been our experience that there are
> more bugs and problems with it than can reasonably be
> expected.  In particular in regards to protected sources
> (particularly problems with duplicate streams) and
> punting of traffic to the IBC, neither of which are easy
> to troubleshoot and can cause mayhem.
> 
> If you intend to do a new implementation on the 7600 at
> this point and have your mind set on using MVPN, I'd
> recommend going with MLDP

When I ran an NG-MVPN network, we took advantage of the MPLS 
data plane and implemented FRR within the p2mp RSVP-TE 
tunnels. So failure within the core resulted in ultra-quick 
switchovers to the backup links. Most times, there was no 
visible effect on picture quality; sometimes, it was very 
minor pixelation which could have been mistaken for a cloud 
passing over a Ku-band dish :-).

Things were a little more challenging between the Sender and 
Receiver PE routers, where we ran PIM. Those links fed into 
BGP (which signaled PIM in the core), so the network could 
easily converge to backup PE-CE links (we had three) using 
LOCAL_PREF. This took care of where PIM Joins were going to, 
and in effect, where downstream traffic was coming from.

The slowest part of convergence was when the primary link 
returned, and BGP immediately re-installed the path toward 
that link (since it had the highest LOCAL_PREF), and it took 
as many as 30 seconds for video to resume across the new 
path. This was even after setting the BGP timers to their 
lowest (about 6.6 seconds in Junos). This also varied 
depending how the link was recovered, whether it was brought 
up with the "no shutdown" command or by plugging the fibre 
in, e.t.c. So 30 seconds was the worst average we concluded 
on, for simplicity.

There was some work going on with "draft-morin-l3vpn-mvpn-
fast-failover-05", but I haven't followed progress or 
implementation of this since I stopped managing that 
network. Hopefull, I soon will with the new one :-). That 
said, I think this draft focused mostly on p2mp RSVP-TE, I'm 
not sure how applicable it could be to mLDP (and certainly 
wouldn't be to regular IP/GRE Multicast).

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20130701/0974f940/attachment.sig>