[187776] in North American Network Operators' Group
Re: BGP MVPN RFC6513, Section 10
daemon@ATHENA.MIT.EDU (Yann Lejeune)
Fri Feb 26 08:31:03 2016
X-Original-To: nanog@nanog.org
In-Reply-To: <CAGL1wDSPWr35_Uw0PaeCeFCQDeU2mzU_Sxn+VvGz_ifkT6Mg=g@mail.gmail.com>
Date: Fri, 26 Feb 2016 10:33:27 +0100
From: Yann Lejeune <yann.lejeune@gmail.com>
To: Jason Iannone <jason.iannone@gmail.com>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Hi
To support the section =C2=A710 in your conf you have two choices:
a. (=C2=A710.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. (=C2=A710.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
>
