Profile 7
Load basic.startup.config.with.cpim.cfg
The PE-CE links are now placed in the global table. All VRF config has been removed.
PIM adjacencies are not setup in the core. Use mLDP to transport multicast traffic in the core without the use of P-PIM.
Answer
Explanation
Profile 7 is just profile 6 (mLDP with in-band signaling) but in the global table instead of in a VRF. The configuration is the same, except you do not reference a VRF on the PEs.
Remember that using mLDP with in-band signaling requires that SSM is used. This is because there is no default MDT, so RP information cannot be propagated to all participating PEs via BSR. For this reason, ASM (*, G) entries are not translated into a P2MP tree. Instead, only (S, G) PIM joins are translated into an mLDP opaque value.
Let’s verify by joining a group on one of the hosts.
As expected, a PIM Join makes its way to PE3. The IIF is the auto-generated Imdtdefault interface. The RPF neighbor is found by doing a route lookup on the source. The BGP nexthop is used to determine the RPF neighbor in the core. Note that this requires the rpf topology fixup that uses mLDP instead of the default PIM for the RPF check on IOS-XR.
PE3 creates a mLDP P2MP FEC rooted at 1.1.1.1. The opaque ID value simply contains the (S, G) and the IPv4 address-family. This is not VPNv4 as we saw in profile 6, so an RD is not required.
The tree is built hop by hop to the root, PE1.
PE1 extracts the customer (S, G) from the opaque value and converts this to a PIM Join, which is sent to CE1.
If we ping this group from C1, we see that C3 reponds:
Summary
Profile 7 is said to be used for a service provider’s IPTV “walled garden” deployment. “Walled garden” is another term for closed platform, meaning the IPTV exists only within the service provider’s AS and for its own customers. The service provider runs multicast in the global table, but does not want to run simple IP multicast in the core. Instead, mLDP is used, and in-band signaling is used within mLDP to signal SSM state. The advantage to using mLDP over PIM in the provider core is that you can use FRR mechanisms to protect against link failures. Additionally, if the provider is already running LDP anyways, it is simply to enable mLDP instead of turning on an additional protocol (PIM) in the core.
In-band mLDP profile 7 is useful for a service provider’s own IPTV deployment, because the amount of mLDP trees is predictable. The amount of IPTV channels is fixed. There is a tree per (S, G) flow, but the SP is in control of this. Profile 6 for mVPNs is not very popular (using in-band signaling for mVPNs for VRFs), because you cannot predict how much mLDP state will be created from your customers. (Each customer (S, G) flow creates an mLDP tree). Instead, profile 6 would be used if you are running the IPTV in a VRF, not usually to provide a multicast VPN service to customers.
Last updated
