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