Inter-AS multicastVPN

[devang_etcom]

Does pim Sparse-mode support the inter-as multicast VPN?

i guess only PIM SSM supports the multicast vpn in inter-as configuration... just to cross check...

regards

Devang Patel

[Harold Ritter]

Chintan,

RPF Vector and the connector attribute are not required for option 10c.

Regards

[Harold Ritter]

Chintan,

Let me explain why the connector attribute and the RPF vector are generally not required in an option 10c scenario.

The connector attribute is used instead of the VPNv4 NH to perform the RPF check for C-Domain multicast streams received on the default or data MDT. This is required in an option 10b scenario as the VPNv4 NH will be changed by the ASBR, which would normally cause the RPF check to fail. In the case of option 10c, the VPNv4 session is from PE to PE or from RR to RR and the VPNv4 NH is not changed in either cases.

The RPF vector is used to forward PIM control messages towards the source and perform the RPF check in an option 10b scenario. Since the PIM routers in one AS have no routing information for PEs Loopback addresses (sources) in the other AS, the RPF vector (generally the BGP NH for the MDT SAFI updates) is used instead of the source address. Again, This is not required in an option 10c context, as PE's loopback addresses are available between the two ASes.

Regards

[chintan-shah]

Hi Hritter,

Thanks for good explanation. I understand that Option C doesn't not change BGP NH so that PE in one AS has routing info avialable of PE in second AS, which is not a case in Option B.

But still in option C, P router ( I.e PIM router) still need to have knowledge of remtoe AS PE loopack ( source), and if AS is BGP-free core, how will that know ? in that case, i guess , still RPF vector will require but not connector attribute.

The reason i asked because we have plan to hae BGP less free core or it might be the case for our partner AS.

please correct me if i am wrong.

Thanks

Chintan

[Harold Ritter]

Chintan,

That is correct. BGP free core is a case in which you would need to use the RPF vector. Otherwise, it is not required in option 10c.

Regards

[chintan-shah]

Hi Hritter,

Thanks for clarification and clearing my understanding.

so if i have BGP free core and need to use RPF vector , It doesn't mean i still have to have BGP MDT SAFI right ? I can still use Option C without BGP MDT SAFI.

May be one of AS has BGP free core and other still have BGP running :-).

Regards,

Chintan

[Harold Ritter]

Chintan,

I don't think you need the MDT SAFI updates to use the RPF vector but the issue is that the RPF vector needs to be supported by the edge devices (initiating the joins towards the source) and by the core routers (in the BGP free core). Since this RPF Vector is not currently supported by Juniper, this will be a problem in a mix network.

Regards

[Harold Ritter]

Chintan,

Here is the draft defining the RPF Vector.

http://tools.ietf.org/html/draft-ietf-pim-rpf-vector-08

Regards

[chintan-shah]

Ah, One more pity in mix network, It is really become frustrating for service provider.

The problem is Juniper is drving more towards NG MVPN so it is almost impossible that now Juniper support BGP MDT SAFI.

We will have to wait till NG MVPN beccome standard and both Cisco and Juniper agree to support.

Another problem I have is, we already have Option B as Inter-As option with our partner for unicast MPLS VPN and they are planning PIM-SSM in Corr (draft-rosen) as they have single vendor ( Cisco).

In that case option i see, use PIM-SSM in core and don't terminate mVPN customer on Juniper ( still they are Very very less comapre to Cisco as PE).

Or use PIM-SM lowest one for both juniper and Cisco and work with partner to see alternative solution , looks difficult although.

But I must heartly thank you on your continued quick response and sharing good info and very good discussion among all of us. This is one of my best discusison on Netpro till now :-)

I keep you disturb you guys in case i have further doubt, i am intial stage of design and want to go to right direction from begining...

[Harold Ritter]

Chintan,

> Ah, One more pity in mix network, It is really become frustrating for service provider.

I can understand the frustration. Drafts and RFCs are written in IETF but are not necessarily followed by all vendors.

> The problem is Juniper is drving more towards NG MVPN so it is almost impossible that now Juniper support BGP MDT SAFI.

I heard rumors from one customer of mine, that they would soon support the MDT SAFI. Probably because of customer pressure.

> We will have to wait till NG MVPN beccome standard and both Cisco and Juniper agree to support.

This might happen but it might take a while. I would recommend to use what has been proven and deployed rather then what might be. Again I know it is difficult to find the right mixture.

> In that case option i see, use PIM-SSM in core and don't terminate mVPN customer on Juniper ( still they are Very very less comapre to Cisco as PE).

This would be one of the few options I guess.

> Or use PIM-SM lowest one for both juniper and Cisco and work with partner to see alternative solution , looks difficult although.

This would be another. The only issue is making sure you avoid using any of the features not supported by both vendors.

> But I must heartly thank you on your continued quick response and sharing good info and very good discussion among all of us. This is one of my best discusison on Netpro till now :-)

It is always a pleasure for me to have that kind of discussions.

> I keep you disturb you guys in case i have further doubt, i am intial stage of design and want to go to right direction from begining...

You are certainly not disturbing, on the contrary. I am sure that many people who find themselves in that same situation will find this thread very interesting.

Regards

[chintan-shah]

> The problem is Juniper is drving more towards NG MVPN so it is almost impossible that now Juniper support BGP MDT SAFI.

I heard rumors from one customer of mine, that they would soon support the MDT SAFI. Probably because of customer pressure.

==>> Hope this is not rumors and it is true. I will also try to pressure Juniper through my managment for this :-).

I should also thank Shivlu for his contribution and help on sharing some info.

Shivlu- I already joined your blog of MPLSVPN and see good mails every day morning :-).

last but not least , thanks to Devang opening this thread that give us opprtunity :-).

Cheers,

[chintan-shah]

Hi Hritter,

I think you were right , it is not rumours but true that Juniper is going to support MDT SAFI. In fact, they have now support avialable in JunOs 9.4 onwards.

- Chapter -17 - on Draft-rosen

(http://www.juniper.net/techpubs/software/junos/junos94/swconfig-multicast/swconfig-multicast.pdf)

BTW, I also go to know this was only done to pressure from some big customer but goingforward Multicast VPN will be based on P2MP LSP , this is way Juniper is going ahead.

I see this year Networks Online session on Multicast and find taht Cisco is already working on mLDP and P2MP LSP for labelled based mVPN. This will interoperate with other vendor...

Not sure, if you can give some info on Cisco's apporach on this new technology for mVPN and it looks far better than PIM based to avoid scalability issue and having PIM Free Core :)..

Regards,

Chintan

[devang_etcom]

Hritter/Sivlu,

Good discussion is going on MVPN! Okay so if I will leak the loopback of PEs in each other AS then are there any chances of RFP failure; if yes then what will be requirement to avoid the RFP failure (I am talking about option B)?

I am not talking about of using Multicast family in BGP!

thanks,

Devang Patel

[chintan-shah]

Hi Devang,

What i learnt from Hritter and shivlu from this discussion that , if you want to go with optoin -B , you need BGP MDT address-family support and that don't need to leak loopback of PEs. so everythign will be fine. But as i have multivendor enviroment, it will be tough , as say juniper doesn't support BGP MDT SAFI.

But if we use PIM-SM (ASM) for default and PIM-SSM for DATA MDT as per draft rosen , we can't have Option -B and we have to use option A or C. For option C you any way exchange PE loopback between two AS throgh RR peering so RPF will not be problem.

But one thing i am still waitning from hritter that what if Core is BGP free whee i wil not have information on remote AS PE loopback and have to do RPF check.

REgards,

Chintan

[chintan-shah]

This is my understanding from this discusion.

Hritter , if you see i have wrong understanding, please correct me.

Regards,

[Harold Ritter]

Chintan,

Your understanding is correct.

Regards