I appreciate your comments and support.
It was my understanding all along that your initial note was about fact
finding rather than arguing against one solution or another. So my response
tried to give a more complete reasoning behind our proposal.
We're acknowledging the maturity level
of the PIM protocol implementations but at the same time we recognize that
the scalability issues of PIM is inherent to the protocol itself: The presence
of soft state results in the regular/persistent transmission of control
(refresh) messages of various sorts. This is a point of consideration for
the PIM-SM family of protocols independently of whether PIM is used within
multicast VPNs or not.
On the other hand BGP is a "solid
state" (!!!) protocol and, as such, has its own issues of concern
(say, resources have to be reserved and set-aside to maintain the various
BGP communications channels between the PE-routers, or the PE-routers and
the BGP route-reflector). However, BGP is an integral part of the “2547bis-mcast”
framework for VPNs no matter whether BGP is to be used to transfer PE-PE
multicast routing information or not -- and I have yet to hear arguments
against removing BGP altogether from 2547bis-mcast VPNs. Therefore, why
not focus our efforts in building the baseline instance of multicast VPN
based on the “2547bis-mcast” framework around BGP.
I understand that adoption of our proposal
does not necessarily mean that within a day or two we will have a fully
operational “2547bis-mcast” VPN. It will, nevertheless, reduce considerably
the number of parameters and operations that we have to tackle and this
will hasten the time it will take to develop an operational, standardized
instance of a multicast-supporting VPN.
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>
10/06/2005 02:49 AM
To
Chatschik Bisdikian/Watson/IBM at IBMUS
cc
<erosen at cisco.com>,
<John.E.Drake2 at boeing.com>, <l3vpn at ietf.org>, <rahul at juniper.net>
Subject
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
-----Original Message-----
From: l3vpn-bounces at ietf.org [mailto:l3vpn-bounces at ietf.org]On Behalf
Of Chatschik Bisdikian
Sent: 05 October 2005 18:52
To: Spencer,R,Richard,XDE73 R
Cc: erosen at cisco.com; John.E.Drake2 at boeing.com; l3vpn at ietf.org; rahul at juniper.net
Subject: RE: Multicast in MPLS/BGP IP VPNs
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