Subject: Multicast in MPLS/BGP IP VPNs

From: Chatschik Bisdikian <[email-masked]>
Date: Wed, 21 Sep 2005 14:03:17 -0400

Dear members of the l3vpn distribution list,

The draft-ietf-l3vpn-2547bis-mcast-00.txt (May 2005) presents a new 
framework and terminology to support multicasting over 
provider-provisioned BGP/MPLS VPNs. The framework encompasses under a 
common umbrella several options for MVPN control plane, data plane and 
other relevant functions (many of these choices have been considered on 
their own right in previous drafts).

This note  focuses on PE-PE transmission of multicast routing described in 
section 5 of the "2547bis-mcast" draft. We believe that to achieve 
productive progress and increase interoperability chances among products 
from different vendors that will support 2547bis-based MVPNs, the number 
of alternatives in section 5 need to:

a) Be reduced to a minimum number of possible alternatives, and
b) Clearly spell out required and optional alternatives.

Among the alternatives, we believe that BGP is the preferred approach. BGP 
has the advantage of:

- reliable transport;
- established inter-provider operations;
- a parallel operational model of the unicast 2547.

The above *non-exhaustive* list provides benefits both in technical terms 
(reliability) and in operational terms (exploiting/leveraging established 
operational familiarity with the unicast 2547 case).  Using the PIM 
alternatives in section 5, both multicast or unicast, does not provide any 
of these advantages -- section 5.1 (PIM peering) points out that the 
periodic refresh of PIM C-Join/Prune messages (which is done to provide a 
level of reliability for PIM) disadvantages the PE routers.

We therefore propose to elect BGP as the required way to carry multicast 
routing information between PEs as described in section 5.2 of the draft 
and, at a minimum, we propose the elimination of section 5.1.3 (Unicasting 
of PIM C-Join/Prune messages).

Regards,

Chatschik Bisdikian 
IBM T. J. Watson Research Center

John E. Drake
Boeing Satellite Systems

---

From: [email-masked]
Date: Wed, 28 Sep 2005 17:29:55 +0100

Chatschik, John,
 
In your email below you mention some of the advantages of using BGP instead of PIM for PE-PE multicast routing, but you do not provide any information regarding the advantages of using PIM instead of BGP, e.g.
 
- PIM is a relatively mature protocol designed specifically for multicast
- PIM based multicast VPN solutions are available today (and are being deployed)
- PIM supports P2P signalling between PEs for joins/leaves (whereas BGP advertisements are broadcast based, although ORF can be used)
 
I'm not saying that BGP isn't the way to go in the long term, in fact I agree that it probably is. However, at this stage I think we need a balanced understanding regarding the alternative approaches before we can decide whether or not to remove certain options from the draft.
 
At the last IETF meeting the PWE3 WG agreed that before deciding whether LDP or RSVP-TE should be used for MS-PW signalling, it was important to first determine exactly what changes would need to be made to each protocol and to estimate what the impact of those changes would be (i.e. major/minor). I think it would be worth performing a similar exercise for BGP in order to understand exactly what changes are required to support multicast and how significant those changes will be, i.e. what problems need to be solved to make BGP do everything (or a subset of what) PIM does and how easy/difficult are those problems to solve. It would also be worthwhile looking at what the issues are with PIM and how difficult those problems are to solve, e.g. refresh reduction to improve scaling.
 
If after looking at the tradeoffs it becomes obvious that BGP is the way to go in the medium/long term, then from an operators perspective, the two main things I would like to understand are:
 
1) Realistically, how long will it be before the draft will be in a state that will allow vendors to implement interoperable BGP based multicast VPN solutions?
2) What will the migration path to BGP be for providers that have already deployed PIM based multicast solutions, i.e. will it be a ships in the night only approach or should/could interworking be supported, particularly in the inter-provider case?
 
Regards,
Richard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Chatschik Bisdikian
Sent: 21 September 2005 19:03
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Multicast in MPLS/BGP IP VPNs

The draft-ietf-l3vpn-2547bis-mcast-00.txt (May 2005) presents a new framework and terminology to support multicasting over provider-provisioned BGP/MPLS VPNs. The framework encompasses under a common umbrella several options for MVPN control plane, data plane and other relevant functions (many of these choices have been considered on their own right in previous drafts).

This note  focuses on PE-PE transmission of multicast routing described in section 5 of the "2547bis-mcast" draft. We believe that to achieve productive progress and increase interoperability chances among products from different vendors that will support 2547bis-based MVPNs, the number of alternatives in section 5 need to:

Among the alternatives, we believe that BGP is the preferred approach. BGP has the advantage of: 

- reliable transport; 

The above *non-exhaustive* list provides benefits both in technical terms (reliability) and in operational terms (exploiting/leveraging established operational familiarity with the unicast 2547 case).  Using the PIM alternatives in section 5, both multicast or unicast, does not provide any of these advantages -- section 5.1 (PIM peering) points out that the periodic refresh of PIM C-Join/Prune messages (which is done to provide a level of reliability for PIM) disadvantages the PE routers. 

We therefore propose to elect BGP as the required way to carry multicast routing information between PEs as described in section 5.2 of the draft and, at a minimum, we propose the elimination of section 5.1.3 (Unicasting of PIM C-Join/Prune messages). 

Regards,

Chatschik Bisdikian 

John E. Drake 
Boeing Satellite Systems