Subject: [pim] Fwd: Multicast in MPLS/BGP IP VPNs

From: Marshall Eubanks <[email-masked]>
Date: Fri, 7 Oct 2005 22:14:37 -0400

Hello PIM-WG;

I am forwarding this (fairly long) mail thread from the I3VPN list as
I think it is relevant to PIM. Here are the issues as I understand
them :

- Bisdikian et al. want to deny the use of PIM in multicast VPN's,
even though there are
deployed solutions with this technology

Specifically, the proposal is to remove PIM as an option in Section 5 of

draft-ietf-l3vpn-2547bis-mcast-00.txt .

- The mandated solution will be to use BGP as the multicast routing
protocol  even though (AFAIK) there are not any any multicast BGP VPN
implementations as yet.

- One worry is the requirement of propagating soft state keep-alive
packets. I know that there are people working on fixing this in a VPN
context,
but I don't know what the status of these implementations are.

This seems very ill-advised to me, but I would appreciate some other 
viewpoints before I start making a fuss  in L3VPN WG. I worry about
bifurcating the multicast world, about L3VPN reinventing the multicast
wheel (possibly re-making a bunch of mistakes), and also about how
multicast routing information will get propagated from PIM domains to
and from BGP L3VPN's. I don't want L3VPN to create something that can
only be used for walled gardens. (I may be wrong about this, but I
have seen nothing on how to do this.)

Regards
Marshall Eubanks

---------- Forwarded message ----------
From: Chatschik Bisdikian <[email-masked]>
Date: Oct 7, 2005 11:46 AM
Subject: RE: Multicast in MPLS/BGP IP VPNs
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked],
[email-masked]

Dear Richard,

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: [email-masked]

<[email-masked]>

10/06/2005 02:49 AM

To Chatschik Bisdikian/Watson/IBM@IBMUS
cc <[email-masked]>, <[email-masked]>, <[email-masked]>,
<[email-masked]>

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: [email-masked] [mailto:[email-masked]]On Behalf
Of Chatschik Bisdikian
 Sent: 05 October 2005 18:52
 To: Spencer,R,Richard,XDE73 R
 Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
 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: [email-masked]

<[email-masked]>

09/28/2005 12:29 PM

To Chatschik Bisdikian/Watson/IBM@IBMUS, <[email-masked]>

cc <[email-masked]>, <[email-masked]>, <[email-masked]>

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: [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

 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

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim