Subject: Advancing the Protocol and Morin Drafts

From: "DUBOSE, KENNETH S (KEN), ATTOPS" <[email-masked]>
Date: Wed, 22 Oct 2008 08:16:17 -0400

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

---

From: Thomas Morin <[email-masked]>
Date: Wed, 22 Oct 2008 15:02:02 +0200

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

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

> 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

> -----------------------------------------------------------------------------------------------------------------------------------
>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 22 Oct 2008 16:40:03 +0200

Thomas,

> and that would inter-operate.

That is not true, Cisco posted the draft-rosen-l3vpn-mvpn- 
profiles-01, which documents very precisely how the PIM based  
solutions work. And we are more then willing to add a BGP profile to  
it with help of the people that prefer a BGP approach.

After last IETF I had hoped to see a proposal from the chairs to  
create 2 drafts, one documenting a PIM based solutions set, and an  
other based on BGP. Both moving forward on standards track. These  
documents don't need to make comparisons between BGP and PIM (as is  
done in the Morin draft), because this creates endless discussions  
and don't get us anywhere. It just needs to document how the  
different modules work together so that vendors can be interoperable.  
Each customer can choose the preferred approach and talk to the  
vendor for an implementation.

Thx,

Ice.

---

From: Thomas Morin <[email-masked]>
Date: Wed, 22 Oct 2008 16:51:51 +0200

Hi Ice,

IJsbrand Wijnands :
> Thomas Morin:
> > 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.
> 

No, that would not describe "a multicast VPN solution", but multiple
ones.

> [...]  

For many operators its not "the vendor" but multiple vendors, and that's
why many operators (and apparently other IETF contributors too) see an
interest in standardizing one solution, with options where needed, and
not multiple profiles.

-Thomas

---

From: IJsbrand Wijnands <[email-masked]>
Date: Wed, 22 Oct 2008 17:03:04 +0200

Hi Thomas,

> interest in standardizing one solution, with options where needed, and

In your last email you say "..Misunderstanding: the draft says "MUST"  
for both PIM-based and BGP-based C-multicast routing."

How is that going to help you standardizing one solution? I also  
pointed out earlier that the Morin draft does not say which core tree  
building protocol needs to be used. This also does not help in  
getting an interoperable solution.

Thx,

Ice.

---

From: Thomas Morin <[email-masked]>
Date: Thu, 23 Oct 2008 10:30:01 +0200

Hi Ice,

IJsbrand Wijnands :
> How is that going to help you standardizing one solution?

Well, if an operator deploys equipments with compliant implementations
(implementing both BGP-based and PIM-based C-multicast routing), then he
knows that he will be able to activate the alternative it prefers, and
that it will interoperate.

> I also pointed out earlier that the Morin draft does not say which 
> core tree building protocol needs to be used. This also does not help 
> in getting an interoperable solution.

You possibly haven't read last revision.
Based on Eric comments about P-tunnels, the draft know says: "[the
recommandation is that] implementations implement the P2MP variants of
the P2P protocols that they already implement [..]".
Hence, if you have interoperable unicast tunneling techniques, the
recommandation orient implementations to also provide a set of
interoperable unicast tunneling techniques.

You can argue that this doesn't give *guarantees*, but I think we can
agree that it helps getting interoperability and that we can't
realistically do more. Moreover, RFC2547/4364 doesn't do thing much
differently and doesn't mandate either any specific tunneling
technology.

-Thomas

---

From: IJsbrand Wijnands <[email-masked]>
Date: Thu, 23 Oct 2008 14:05:47 +0200

> that it will interoperate.

What you are saying is not very different from what we document in  
our profiles. You just call it alternatives with the same MVPN  
solution set, we spell out the alternatives and call it profiles.

> differently and doesn't mandate either any specific tunneling

I disagree, because I prefer an approach that guarantees  
interoperability, that is the first priority of the IETF. The second  
priority is to converge on a single solution. You are limiting the  
building blocks and hope the end result will be interoperable.

Thx,

Ice.

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Thu, 23 Oct 2008 11:34:59 -0400

> other based on BGP. Both moving forward on standards track. These

I agree.

> vendor for an implementation.

I agree with this statement.
Comparing protocols is not productive, especially when comparing a
protocol which has a significant deployment with one that doesn't.

---

From: "MEDAMANA, JOHN B, ATTOPS" <[email-masked]>
Date: Thu, 23 Oct 2008 23:08:40 -0400

I vote NO.

Need to get agreement on requirements first, before a specific solution
proposal is voted on. I recommend pursuing agreement on requirements in
"draft-mnapierala-part-reqt", which addresses the needs of large
Multicast VPNs. 

John Medamana

AT&T

====================

Regards 
Marshall & Danny

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Fri, 24 Oct 2008 11:16:23 -0400

> other based on BGP. Both moving forward on standards track. These

Agree - if the documents are not clear as is, should clean up the
documents vs. needing to refer to a 3rd document.

> vendor for an implementation.

The Morin draft has been very helpful but it is still very confusing on
it's intention/impact - is it a requirements (non-solution favoring)
document or a comparison document which will impact the two other
drafts? It states in the abstract "mechanisms standardization should
favor". Does the sentence mean that non-favored mechanisms (e.g.
PIM-based) will be non-standards track? I'd favor as Nabil suggested, a
requirements document (with updates). Either it should have a re-write
before wg document status or else a clearly defined scope if it's a wg
document.

Deborah