BGP MVPN RFC6513, Section 10
mark.tinka at seacom.mu
Sun Feb 28 10:51:33 UTC 2016
On 26/Feb/16 11:33, Yann Lejeune wrote:
> It's up to you to choose what mode you want to use:
> - spt-only: is quite "simple". We only have (s,g) in the core. To validate
> an os, it's faster.
> - rpt-spt. We have both (*,g) and (s,g) in the core. the validation is more
> complex, the protocol is more dynamic...
I've ran both modes, and found SPT-only mode to be a fair compromise
between speed and scale.
When operating SPT-only modes, we did not witness a noticeable
difference in channel-changing times. In SPT-only mode, the (S,G) state
is already present on the Receiver PE router even though there is no
downstream interest for that state. So when an IGMP Join request comes
into the router, it does not have to travel the RPT tree like it would
if you ran RPT-SPT mode (which is traditional Multicast).
In our case, we had Multicast probes connected to every Receiver PE
router to track performance for each channel. So if you have that,
you're going to need all the channels present on the router anyway, even
though downstream interest is not present. In this case, avoiding the
extra steps associated with RPT-SPT mode is what compelled us to run
But as Yann has mentioned, even in SPT-only mode, the Type 6 routes will
exit in the router, but won't really be used. Type 5 routes are more
important when operating in SPT-only mode, and those are always present
in such a state.
My next NG-MVPN operation will be SSM-based, so this should be simpler
More information about the NANOG