[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Multicast in MPLS/BGP IP VPNs
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
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