Subject: RE: Multicast in MPLS/BGP IP VPNs

From: Chatschik Bisdikian <[email-masked]>
Date: Wed, 5 Oct 2005 13:51:30 -0400

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

---

From: "Rajiv Asati \(rajiva\)" <[email-masked]>
Date: Thu, 20 Oct 2005 01:16:53 -0400

>     People say that CE-based VPNs are too hard to manage by a 
> service provider.
>     I don't believe it for one minute. If cable and DSL 

I agree. Providers, in fact, are driving towards "Managed CE" or
"managed VPN" service in which the CE routers are managed by the SPs.
This model has already been big in EMEA and marching towards mainstream
in NA. 

Solutions such as "Carrier Supporting Carrier" & "DMVPN" are bound to
take us towards "CE based VPNs".

Cheers,
Rajiv

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Dino Farinacci (dino)
> Sent: Wednesday, October 19, 2005 3:13 PM
> To: [email-masked]
> Cc: [email-masked]; Beau Williamson (bwilliam); Nidhi Bhaskar 
> (nbhaskar); John Meylor (jmeylor); [email-masked]
> Subject: Re: [pim] Fwd: Multicast in MPLS/BGP IP VPNs
> 
>     Cc'ing l3vpn working group.
> 
> >> The L3-VPN problem is a subset of the more general PIM multicast
> >> routing problem. But they have fore knowledge that they can use to
> >> their advantage that PIM alone doesn't have. For instance, they
> >> already know their PIM neighbors and they know the best 
> egress point
> >> to reach sources.
> 
>     There are scaling problems with basic PE-based VPNs. How 
> do you expect
>     anything that overlays on top of it to work well?
> 
>     PE-based VPNs will not scale, it is the wrong place to 
> put the technology.
>     Putting VPN support at the edges (CE-based VPNs) allows 
> them to scale in a
>     distributed manner and is more cost-effective because you 
> can avoid the 
>     huge honkin PE box cost with all sorts of additional 
> issues like lack of 
>     privacy, single point of failure, etc...
> 
>     People say that CE-based VPNs are too hard to manage by a 
> service provider.
>     I don't believe it for one minute. If cable and DSL 
> providers can put
>     boxes in our homes, we can have script-based or 
> auto-configuring CE-based
>     devices in remote offices. And if and only if you want 
> network based
>     encryption, then you get encrypted packets starting out 
> on the CE-PE link.
> 
>     So let's fix the fundamental problem and not finger point 
> to PIM or any
>     other protocol. BTW, we could get BGP to scale better too 
> if it didn't 
>     have to support VPNs.
> 
> Dino
> 
> P.S. Tom, I am not picking on you. It was just your email 
> that invoked my
>      response. There is nothing you said that I necessarily 
> disgree with.
> 
> --------------------------------------------------------------
> -----------------
> 
> X-IronPort-AV: i="3.97,231,1125903600"; 
>    d="scan'208"; a="354136005:sNHT32177262482"
> X-BrightmailFiltered: true
> X-Brightmail-Tracker: AAAAAA==
> X-IronPort-AV: i="3.97,231,1125903600"; 
>    d="scan'208"; a="110455279:sNHT17497804"
> To: Beau Williamson <[email-masked]>
> Subject: Re: [pim] Fwd: Multicast in MPLS/BGP IP VPNs 
> In-Reply-To: Message from Beau Williamson 
> <[email-masked]> of "Wed,
> 	19 Oct 2005 10:14:26 CDT."
> 	<[email-masked]> 
> Content-Type: text/plain; charset="us-ascii"
> Content-ID: <[email-masked]>
> Date: Wed, 19 Oct 2005 11:51:27 -0400
> From: Tom Pusateri <[email-masked]>
> X-Spam-Score: 0.0 (/)
> X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
> Cc: Nidhi Bhaskar <[email-masked]>, [email-masked], 
> [email-masked],
>         [email-masked]
> X-BeenThere: [email-masked]
> X-Mailman-Version: 2.1.5
> Precedence: list
> List-Id: Protocol Independent Multicast <pim.ietf.org>
> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pim>,
> 	<mailto:[email-masked]?subject=unsubscribe>
> List-Post: <mailto:[email-masked]>
> List-Help: <mailto:[email-masked]?subject=help>
> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pim>,
> 	<mailto:[email-masked]?subject=subscribe>
> Sender: [email-masked]
> X-PMX-Version: 4.7.1.128075
> X-from-outside-Cisco: 128.107.234.205
> X-OriginalArrivalTime: 19 Oct 2005 15:54:50.0541 (UTC) 
> FILETIME=[702A8DD0:01C5D4C5]
> 
> The L3-VPN problem is a subset of the more general PIM multicast
> routing problem. But they have fore knowledge that they can use to
> their advantage that PIM alone doesn't have. For instance, they
> already know their PIM neighbors and they know the best egress point
> to reach sources.
> 
> They are having scaling problems with the current PIM soft-state
> design.  These scaling problems are actually a general PIM problem
> and so we thought we would try to solve them in a general way and
> they could benefit from this. However, we are on two different time
> scales. They have deployment problems today and the general PIM
> deployment outside of L3-VPNs does not.
> 
> We have started the pim state refresh reduction work which could
> help them but there isn't consensus on how this should be done and
> forward progress has been slow. This also doesn't solve their problem
> of hello traffic.
> 
> Therefore, it makes perfect sense for them to solve their problems
> now instead of waiting for us. They don't need hellos, they already
> are talking to the routers they want to and have established BGP/MPLS
> state.
> 
> I think this will be a great discussion topic in Vancouver. I'll
> put it on the agenda and be sure to invite those from L3-VPN.
> 
> If we don't want them to do everything with BGP, then we need to
> provide them an alternative. But that means getting something
> finished and getting it implemented.
> 
> Thanks,
> Tom
> 
> In message 
> <[email-masked]> you write:
> >At 10/19/2005 08:40 AM, Rurick Kellermann wrote:
> >>I follow both WG emails - there's perception in the L3-VPN WG that
> >>there are a lot of shortcomings on PIM-SM.
> >
> >Got any pointers to specifics about these perceived shortcomings?
> >
> >I suspect they are most concerned with the fact that it uses 
> soft-state 
> >which has to be refreshed but I'm just guessing.
> >
> >Beau 
> >
> >_______________________________________________
> >pim mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/pim
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pim
> 
> --------------------------------------------------------------
> -----------------
>

---

From: [email-masked]
Date: Thu, 20 Oct 2005 08:41:05 +0100

Rajiv,

> "managed VPN" service in which the CE routers are managed by the SPs.

CE management is orthogonal to whether a CE or PE based VPN approach is used, providers offer managed and unmanaged CE solutions based on PE-based VPNs.

> take us towards "CE based VPNs".

Really? Please can you explain what the requirements/challenges are for "Carrier Supporting Carrier" and "DMVPN" solutions that are bound to take us towards a CE based VPN approach?

Regards,
Richard

---

From: "Jim Guichard \(jguichar\)" <[email-masked]>
Date: Mon, 24 Oct 2005 14:01:36 -0400

> What happens when the number of routes from each site out of 
> the sudden changes ? Massive SP wide re-provisioning to 
> accommodate RR partition or massive RR repartitioning ???? 
> Pick your poison :)))).

Presumably one would keep a certain amount of headroom at each RR
cluster based on specific engineering rules.

Jim

> R.