BGP MVPN RFC6513, Section 10

Fri Feb 26 09:33:27 UTC 2016

Hi
To support the section §10 in your conf you have two choices:
a. (§10.1) implementing the RP on your PE (protocol pim rp local). It will
advertises the route type after pim register message (or msdp source active
from other RP is you have other rp in your network)
    + be sure to use spt-only mvpn mode (default one)

b. (§10.2) implementing an MSDP session between the RP and its PE
    each time the RP will learn a source (either because it receives a pim
register or a SA message from another RP (full meshing msdp between rp), it
will advertise route type 5 to the mVPN. This way receiver PE will learnt
source and if they received join (*,g), they will be able to advertise the
good route type 7 to the source PE. The required conf is:
        - msdp session between the pe and the rp
        - defining the rp address (protocols pim rp static....)
        - be sure to use spt-only mvpn mode (default one)

The route type 6 is used in another mode call rpt-spt, where you are closer
to the traditionnal multicast behavior (first we build the rp tree and
second we build the source tree). this mode must be enable explicitely per
routing-instance in the mvpn-mode knob. One thing: even in spt-only mode,
the junos will create a route type 6 when receiving a join (*,g) but will
not advertise it. It just wait to get a related route type 5

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...

Regards,
Yann.

On 23 February 2016 at 16:39, Jason Iannone <jason.iannone at gmail.com> wrote:

> Hi all,
>
> I'm having trouble interpreting under what circumstance section 10 of
> BGP MVPN comes into play.
>
> The way I read this section, upon the receipt of PIM/IGMP Join to
> (*,G) the Receiver Site PE does not signal Type 6 or Type 7 Joins
> until a Type 5 Source Active route is received from a Sender Site PE.
>
> If Section 10 assumes the use of ASM groups in the VPN, why develop a
> Type 6 Shared Tree Join A-D route for unknown sources?
>
> What are the practical minimum Juniper configurations to support
> Section 10 for ASM and (*,G) PIM Join when the PE doesn't know a
> source?
>
> CE1---PE1,C-RP-----P-----PE2---CE2
> Sender Site-------------------Receiver Site
>
> 1. CE1 has no active source
> 2. CE2 forwards PIM Join (*,G) to PE2 toward PE1,C-RP
> 3. PE2 eats PIM Join, maintains (*,G) state
> 4. CE1 generates Register messages to PE1
> 5. PE1 originates Type 5 (S,G)
> 6. PE2 receives Type 5 (S,G)
> 7. PE2 verifies existing (*,G) state
> 8. PE2 advertises Type 7 Join (S,G)
> 9. PE2 does PMSI and P-Tunnel attachment
> 10. PE1 receives (S,G) from PE2
> 11. PE1 adds PMSI to downstream interfaces
> 12. Multicast flow end to end
> 13. Achievement unlocked!
>
> I'm least sure about steps 2 & 3.
>
> Comprehension challenged,
>
> Jason
>