[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Multicast in MPLS/BGP IP VPNs
Chatschik,
I fully agree
with and support your reasoning and motivation to reduce the number of options
in the draft.
Regarding your proposal to select BGP as the
mandatory option for distributing multicast routing information, I agree
that this has a number of advantages. First of all, the ability to use the
same protocol for distributing customer unicast and multicast routing
information across the core supports functional convergence (which offers a
number of potential benefits, e.g. reduced complexity, reductions in operating
costs, etc.). Looking at the protocol itself, the ability to use
compartmentalised/dedicated MVPN RRs to minimise the number of protocol sessions
required and to scale the network incrementally as the number of MVPNs
increases is attractive. Also, as you mention below, BGP has extensive policy
controls and therefore is an ideal protocol for supporting inter-provider
MVPNs.
However, the
questions that I would like to understand better are:
(1) Is it easier to solve the scaling issues associated
with PIM and to add things like inter-provider policy controls, or is it easier
to add multicast support to BGP?
(2) If PIM scaling wasn't an issue, would we
still be discussing using BGP anyway?
Regarding (1),
I'm not a PIM or BGP expert so am unable to comment on this myself. However,
based on your email and talking to some of the various MVPN draft authors, there
are a number of people in the group that think BGP is the best solution,
particularly in the medium/long term. In contrast, I haven't heard anyone say
that they think we shouldn't use BGP and that we should stick with PIM.
Regarding (2), in my opinion the answer is 'yes' due to
the advantages mentioned such as functional convergence, RR scaling and
interprovider policy support.
Therefore, if
there is agreement at this stage within the group that the advantages of using
BGP outweigh those of using PIM, then I support your proposal to make BGP the
mandatory option.
If this is the case, then as I said
in my last email, looking at things from an operators
perspective, what would the migration path be for providers that have
already deployed MVPNs based on PIM/GRE? Would it be a ships in the night only
approach with incremental MVPN service switchover, or could/should BGP-PIM
interworking be supported?
Regards,
Richard
Dear Richard,
Thank you very much for your comments. First of all, we are in
agreement regarding your assessment of the maturity of the PIM protocols. At
the same time, we cannot argue against the collective experience of protocol
designers and implementers pointing towards issues emanating from the “soft
stateness/reliability” of these protocols. While acknowledging the benefits of
the latter design choice (soft state), with increasing network sizes, the load
that the refresh of PIM state information creates the potential for severe
burdening of the compute and communication resources in the network. This can
be further exacerbated when join suppression cannot be “activated” as is the
case outlined in section 5.1.3 (unicast PIM c-join/c-prune messages).
Our aim is to reach as early as possible
a simple baseline standard design for the class of MPLS/BGP IP VPNs that
contains as few non-interoperable alternatives as possible and, hence, hasten
the creation of standards-based interoperable designs. The fact that
implementations of certain particular design choices may exist does not
necessarily establish a design precedence not deserving reconsideration (and
it is our understanding that you share a similar view as well). Our note
serves as a point of departure for one such reconsideration.
Our note proposes downplaying (and in the
case of section 5.1.3 even eliminating) those alternatives in the proposed
draft that will be dependent upon the standardization of additional
solutions/procedures. By selecting BGP as the baseline design choice, we
leverage the fundamental operational characteristics of the 2547 (unicast)
VPNs, operational characteristics that have been standardized long time ago
and fine-tuned ever since (e.g., using ORF to support P2P signaling, as you
suggest).
Instead of waiting for
the development (by which group(s)?) of standardized solutions to issues like
refresh reduction (an issue that has remained unsolved in some time), this
group could simply focus its efforts in standardizing the format and meaning
of the additional information to be carried during the BGP control information
exchanges to support multicast VPNs; the draft already provides the collection
of the kind of information to be exchanged. We need to underscore here that
BGP will already be used for other operations in the multicast VPNs, e.g., the
autodiscovery process described in Section 4 of the draft. So, it will make
sense for the baseline design to leverage further BGP, which will be an
integral part of the final solution any way.
In summary, our proposal aims in reducing the number of
operational options in the final standard (and increase interoperability
chances) by leveraging those options for which standardized/parallel solutions
already exists (e.g., in the unicast BGP VPNs) and they will be present in the
final solution anyway (e.g., BGP for autodiscovery purposes). I hope that this
provides you with the motivational context behind our proposal and answers
your our points regarding BGP (our preference) vs. PIM signalling within the P
(core) network.
Best
Regards,
Dr. Chatschik Bisdikian
IBM T. J. Watson Research Center
19 Skyline Drive, M/S
3S-B34
Hawthorne, NY 10532, USA
tel#: +1 914 784 7439
fax#: +1 914
784 6205
e-mail: bisdik at us.ibm.com
| <richard.spencer at bt.com>
09/28/2005 12:29 PM
|
|
To
| Chatschik
Bisdikian/Watson/IBM at IBMUS, <l3vpn at ietf.org>
|
|
cc
| <erosen at cisco.com>, <John.E.Drake2 at boeing.com>,
<rahul at juniper.net>
|
|
Subject
| 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
-----Original
Message-----
From: l3vpn-bounces at ietf.org
[mailto:l3vpn-bounces at ietf.org]On Behalf Of Chatschik
Bisdikian
Sent: 21 September 2005 19:03
To:
l3vpn at ietf.org
Cc: erosen at cisco.com; John.E.Drake2 at boeing.com;
rahul at juniper.net
Subject: Multicast in MPLS/BGP IP
VPNs
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