Subject: RE: Multicast in MPLS/BGP IP VPNs

From: [email-masked]
Date: Thu, 6 Oct 2005 07:49:13 +0100

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

---

From: Chatschik Bisdikian <[email-masked]>
Date: Fri, 7 Oct 2005 11:46:33 -0400

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 

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

(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 

<[email-masked]> 
09/28/2005 12:29 PM 

To

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

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:

Among the alternatives, we believe that BGP is the preferred approach. BGP 
has the advantage of: 

- reliable transport; 

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 

John E. Drake 
Boeing Satellite Systems