Mark Tinka mtinka at globaltransit.net
Thu Dec 29 10:00:21 UTC 2011

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 
M320's and T320's today. 

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

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

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

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.
> http://tools.ietf.org/html/draft-bhatia-pim-mpls-register
> -packets-00

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

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

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

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


-------------- 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: <http://mailman.nanog.org/pipermail/nanog/attachments/20111229/b5f83823/attachment.sig>

More information about the NANOG mailing list