[147990] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: IPTV and ASM

daemon@ATHENA.MIT.EDU (Mark Tinka)
Thu Dec 29 05:02:20 2011

From: Mark Tinka <mtinka@globaltransit.net>
To: nanog@nanog.org
Date: Thu, 29 Dec 2011 18:00:21 +0800
In-Reply-To: <CAPLq3UNOJDsmTs5tvMY-E6EUObJi5nNdNGDH1pyFLqMGmnBr9Q@mail.gmail.com>
Reply-To: mtinka@globaltransit.net
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

--nextPart662584119.rQfnx4txIr
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On Thursday, December 29, 2011 07:58:53 AM Glen Kent wrote:

> SSM is also used since we *know* the IP addresses of the
> content servers that are the sources - You dont need
> ASM. I dont think maintaining RP infrastructure is
> trivial. Who wants to deal with register packets, etc.
> Small routers punt all registers to CPU and them forward
> them in SW.

Our Sender PE routers double as our RP's. These are Juniper=20
M320's and T320's today.=20

Yes, a Tunnel PIC is required on the Juniper's (although you=20
might find it interesting that if you're running PIM-SM for=20
IPv6 on Sender PE routers, you don't need a Tunnel PIC;=20
however, if you have an IPv6-based RP, you need a Tunnel=20
PIC).

Juniper MX routers don't require a Tunnel PIC, as those are=20
integrated into their DPC and MPC line cards.

Our customer is using Cisco ASR1000 routers as Sender CE=20
routers, and PIM Registers are encapsulated/decapsulated in=20
hardware on those platforms.=20

But I do agree that it does add overhead.

> In fact there was a draft which proposed using MPLS
> encapsulation in networks that support MPLS to replace
> the existing RP mechanism.
>=20
> http://tools.ietf.org/html/draft-bhatia-pim-mpls-register
> -packets-00

This quite interesting, I hadn't heard of this one before,=20
although I'd always wondered why something like this wasn't=20
already implemented.

My main issue with this proposal is that if the Sender CE=20
router is not part of your network, i.e., your customer, a=20
partner network, e.t.c., it requires that your MPLS domain=20
be extended toward them. It's not impossible, but not=20
typically common.

Also, it would be good to support both LDP and RSVP, and not=20
RSVP only.

Maybe I should contact the author to see if the project can=20
be revived.

Cheers,

Mark.

--nextPart662584119.rQfnx4txIr
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iQIcBAABAgAGBQJO/Do5AAoJEGcZuYTeKm+G/yQP/idvm4qeJTHaC9u4q5YKDwUJ
7vAXhcRTUyYKC4diyB/K4NHbfKe6gNQRAulqjjTCRFQpfKRO+ha6MuwIbc7LWMgi
WrmIhM8mLCdh8xLCQKFcHC3ESHRThbi8AzXb4VK7Evni5V8nHlH6UvTg7UH7g/JD
fvN2NYAvEbsJ+ft4AyVH6UN9pkKFh/KrEPfJcS3IwxKIurbOVfyOyQKO6fRzTfc1
a0Kis7aC+bSihhMt97W1lX4ar/iAJPbikPC7sIPWdu/b6dSJwQ6xK3gk0TdfRRJ2
jLNjiIm8W9jNP5u5wdPQAjB/j25Oy0XJfp56iu3XXRYnsADnVOKp7aRDBKjW0f1j
O4X9vO2LA78Y2nXmRAy4+NqwpSDI2HxjdWbp2oqVYh38oXJOr4+XDAJ+7epV5G0b
bckidY4/qWMaTj7/BBBoffbS6sVnhE8620zTdtdjwev6n5UANJANuu8iiNqpOdF+
M+VaLDmtLJV1OwDyX9il0T0BPAahy5kKe05fTXHgX1kIdMILPl6510VxmoP8CeKl
EsSlnk+AVhSdp22oNyGdYHtSo9XOCw3dBnyHGW7ndrHWYx3fXjaD0V7dB0uQXGaj
3xP51MdO2K8eNEX6JKQ2qWpv2gErKSbySymK9k3CJMyJXmkZaBlA9rKFqbGK2jEK
AO+EhCweeyKLYGLYW1pQ
=4Jtl
-----END PGP SIGNATURE-----

--nextPart662584119.rQfnx4txIr--


home help back first fref pref prev next nref lref last post