Re: Advancing the Protocol and Morin Drafts

[Thomas Morin <[e-mail]>]

Hello, 

I'm slightly tired of hearing the same arguments in tens emails from the
same source, but I will still try to highlight a few misleading or wrong
statements (below).

Most importantly, I would like to highlight the fact that, AFAICT the
people opposing the path proposed by the chairs have not proposed an
alternative that would help the working group push to the IESG, a set of
documents describing a multicast VPN solution that vendors can implement
and that would inter-operate.


DUBOSE, KENNETH S (KEN), ATTOPS :
>
> 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) 

Misunderstanding: the draft says "MUST" for both PIM-based and BGP-based
C-multicast routing.


> and also not addressing key multicast capabilities used by our
> customers such as BSR, which would still need to be handled solely by
> PIM.  

First, the scope of our draft is not to introduce new procedures, but
sort out between the proposed ones when there are many alternatives
proposed for a function, it is not the case for BSR. 

Second, you are misleading in saying that BSR "would still need to be
handled solely by PIM", since BSR support is covered both for PIM-based
and BGP-based C-multicast routing (draft-ietf-2547bis-mcast).


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

Pardon me, but the IETF is not a marketing venue.


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

As already explained, we are ready to cover bidir PIM in a next revision
to sort out between the different alternatives proposed for Bidir-PIM in
draft-ietf-2547bis-mcast.


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

Again, nothing in the draft will force you to use BGP for C-multicast
routing.  If you have precise comments on the text in the draft about
BGP for C-multicast routing, they will be welcome.


> I would hope that any new approach to MVPN would have the  followin
> 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.

Again:
- if you have comments on how draft-ietf-2547bis-mcast provides bidir,
why didn't you comment on that draft on the list ?
- discerning between alternatives to support bidir PIM can be done in
the draft for which adoption was asked, you are free to contribute
- (obviously) our draft does not state anything that would inder
bidir-PI support
- (please spare us the marketing speech)


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

Again ... <sigh> ... the draft doesn't say anything that would force you
to use BGP for C-multicast routing if you have concerns about using it
(independently of any debate on the relevance of those concerns).

-Thomas


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