BGP MVPN RFC6513, Section 10

Wed Mar 2 19:50:07 UTC 2016

Thanks for responding.  What's interesting is that even though no
listener joins to RP, one must be configured for PIM Sparse Mode ASM
to function.  I suppose this is a result of MVPN outsmarting PIM.

In my testing so far, generating a working flow with rpt-spt is much
faster than spt-only.  I suspect this has to do with the conditional
nature of the Type 7 Join which waits for receipt of a Type 5 SA
before signaling interest upstream.  spt-only mode seems objectively
superior to rpt-spt in every other way.

Jason

On Fri, Feb 26, 2016 at 2:33 AM, Yann Lejeune <yann.lejeune at gmail.com> wrote:
> 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
>
>