nanog mailing list archives

Re: BGP MVPN RFC6513, Section 10


From: Jason Iannone <jason.iannone () gmail com>
Date: Wed, 2 Mar 2016 12:50:07 -0700

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 () 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 () 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




Current thread: