Opposed.
I am opposed to this approach as I feel it does nothing to move MVPN technology forward. I see this approach as clearly favoring a lateral shift (PIM to BGP for join/prunes) and also not addressing key multicast capabilities used by our customers such as BSR, which would still need to be handled solely by PIM. Major carriers such as ourselves who have 4+ years of significant experience with MVPN, large global deployments and tens of thousands of customer connections cannot support a new standard which is not backed up by any meaningful production network experience.
In addition, the draft-morin-l3vpn-mvpn-considerations-03 does not address Pim BiDir while support of this protocol is critical and must be included out of the gate in any MVPN consideration draft. Secondly, as Chris Chase, an AT&T Fellow and one of the industry's leading MPLS and BGP experts has stated we are concerned about the significant investment in additional Route Reflector infrastructure that would be needed to process all the additional messaging that would occur when carrying PIM join/prune information in BGP - and the additional BGP processing on the edge of the network.
I would hope that any new approach to MVPN would have the following key attributes:
1) Does the approach support all current multicast features and capabilities in use by MVPN customers as well as address new features and capabilities that are driving customers - and carriers - to deploy multicast across their different networks. Having supported large global multicast customers in the financial, manufacturing, media, and government areas since the mid to late 90s over L2 networks and also having worked with at least 90% of our large global customers using MVPN over MPLS networks, I am seeing vastly increased demand for many-to-many multicast applications which is driving the need for Pim BiDir support.
2) Does the approach increase the efficiency and scalability of the carrier's MPLS and MVPN infrastructure to allow the most cost-efficient deployments in support of our customer base. The draft being discussed here would appear to increase the cost and complexity of our MVPN network by requiring a significant increase in our Route Reflector infrastructure as well as increased processing due to BGP/PIM translations on the edge of the network.
Ken DuBose
Distinguished Technology Consultant
AT&T Network Design & Consulting
-----------------------------------------------------------------------------------------------------------------------------------
This email starts a 3 week call for input, to expire October 23, 2008,
for the following steps:
1.) To accept draft-morin-l3vpn-mvpn-considerations-03 as a working
group document; and
2.) To turn this document into a requirements draft, with mandatory to
implement features for an interoperable implementation. The authors
have indicated that they are willing to do this.
Our intention is, if this approach is accepted, to then begin WG last
call to submit to the IESG for publication:
draft-ietf-l3vpn-2547bis-mcast
draft-ietf-l3vpn-2547bis-mcast-bgp
We expect that these two documents will be submitted more or less as is
(i.e., certainly with any new bug fixes or other necessary corrections
and
improvements, but without specific mandatory to implement feature
description in those drafts).
Please respond to the list with your recommendations for these two
courses of action.
Regards
Marshall & Danny