Saturday, April 19, 2014


In legacy MVPN scenarios there will be a GRE encapsulated MDT tunnel is created among the PEs and the entire customer multicast traffic of a particular VPN will be encapsulated with the MDT group address and tunneled it. In MLDP scenario there won't be any PIM configured in the core and the multicast packets are MPLS encapsulated. This makes the core PIM free.

In MLDP cases there will be a VPN-ID used instead of MDT default multicast group address. The default MDT will be created using MP2MP LSP to support low bandwidth and control traffics between the VRFs. The data MDT will be created using P2MP LSP to support high bandwidth traffic from a particular source. There will be PIM neighbor relationships between the VRFs which are seen in LSP-VIF. At the edge towards the customer (CE) PIM multicast routing will be enabled for that VRF.

The Default MDT will be created using MP2MP LSP. Static root has to be defined for MP2MP LSP. Normally two roots will be configured for redundancy. MDT will use LSP-VIF to transmit VPN multicast packets, i.e., PIM will run over MP2MP LSP.

In below depicted figure there will be a MP2MP LSP created with the root at PE1. The opaque value for MVPN is in the format of (VPN-ID). Both MP2MP upstream and downstream LSP will be formed and the labels will be exchanged for the data transfer.

!To create LSP in IOS
ip multicast vrf A mpls source Loopback0
ip vrf A
rd 65001:1
vpn id 65001:1 --- For creating Opaque value
route-target export 65001:1
route-target import 65001:1
mdt default mpls mldp - Root node address

!To create LSP in IOS-XR
vrf ABC
mdt default mldp ipv4
mpls ldp
router-id x.x.y.y
vrf ABC
vpn id 65000:1
address-family ipv4 unicast
LDP capabilities are extended to support multicast over LSP. LDP capabilities are advertised through LDP message TLVs during LDP initialization. mLDP defines two new FEC elements:-
1. P2MP : TLV 0x0508
2. MP2MP : TLV 0x0509
In mLDP, egress LSR initiates the tree creating by looking into root address. The root address is derived from BGP. Each LSR in the path resolves the next-hop address of root and send the label info. mLDP Control Plane:-

mLDP Data Plane:-

Click Here To Read Rest Of The Post...

Friday, February 7, 2014

Control Plane Flow and Data Plane Flow - BGP RFC 3107

BGP 3107 Architecture for Large ISP-Telecoms covers how BGP RFC 3107 help service providers to share the VPN routes across the boundaries without sharing the PE routes. ABR(Area Border Router) plays a vital role, as it has to modified the BGP next hop attribute to self.

Once the iBGP next-hop is changed, there after we can see how the control and data flow will look like.

Control Flow

Next step is to see how the data flow will look like

Click Here To Read Rest Of The Post...

Tuesday, January 28, 2014

BGP 3107 Architecture for Large ISP-Telecoms

BGP Label Update: Carrier Support Carrier - RFC 3107 post was describing how BGP RFC 3107 help service provider to share the VPN routes across the boundaries without sharing the PE routes. BGP Label Update feature is mainly used during inter-AS communication so that the changes occurring in one network couldn't impact the other.

Now consider in case of LTE network, there are thousand of thousand of eNODEB with all IP connectivity. Telecom provider is using IGP+LDP within the single domain. In this case, all the routes of eNODEB will flood across the domain however which is not required. Even we can't perform the summarization on loopbacks to reduce the number of routes within single area. How the scalability of PE will work in this kind of network?

Probably, BGP-3107 based architecture can be utilized within single Service Provider domain also to carry PE reachability. BGP IPv4-label address-family sessions between PE and P routers. IGP+LDP still runs within areas but does not carry PE reachability across areas. Remote PE loopback is a BGP ipv4 labeled route in RIB and next-hop for BGP service prefix is a BGP 3107 route.

Click Here To Read Rest Of The Post...