Subject: draft-morin-l3vpn-mvpn-considerations

From: Ron Bonica <[email-masked]>
Date: Mon, 10 Dec 2007 16:11:28 -0500

Folks,

Unless I hear an objection before COB Friday, this document will become
a WG draft.

                                      Ron

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 13 Dec 2007 14:27:20 -0800

Ron,

I'm in favor of this becoming a WG draft.  While some of the pieces in
the document may require further work, it's important that this be done
by the L3VPN working group.

Thanks,

John 

>-----Original Message-----
>From: Ron Bonica [mailto:[email-masked]] 
>Sent: Monday, December 10, 2007 1:11 PM
>To: [email-masked]
>Subject: draft-morin-l3vpn-mvpn-considerations
>
>Folks,
>
>Unless I hear an objection before COB Friday, this document 
>will become a WG draft.
>
>                                      Ron
>
>

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 14 Dec 2007 14:49:27 +0100

hi ron, all

the document should focus on a solid analysis/description before
concluding with (strong) recommendations that are prescriptive and this,
at an early stage of the analysis.

here below a specific example to show that this analytical phase is not
completed to draw such conclusions/recommendations:

"By contrast, experience proves that PIM-based mechanisms are
operationally viable, but with well identified limitations.  Some of
those limitations may be improved upon (although there is currently no
clearly defined proposal to do this), however some of the limitations
appear to be intrinsic to the approach."

there are stated limitations but which limitations ? and to which extend
(all protocols developed by the IETF have certain limitations what.
matters is whether or not they are impacting in the interval of the
protocol operations and how degradations are impacting outside of this
interval) 

more interestingly, the statement ack's they may be elevated but since
these limitations are stated to "appear as" intrinsic to the approach
and so they can not be elevated ? if this is the case where is the proof
for such statement ?

in general also, i suggest that authors keep protocol capabilities
analysis and consolidate their argumentation from feedback obtained on
the field as long as BGP-based approaches do not benefit from experience
on the field. indeed, in its current form, the document reads as
comparing disadvantages of experimental / deployment experience gained
from PIM wrt to theoretical expectations/advantages from new BGP-based
standards.

=> conclusions/recommendations need to be based on solid and fair
arguments enough to be perceived as truly prescriptive for driving the
protocol work and subsequent decisions of the working group. if these
conclusions/recommendation keep changing on per version basis (because
not complete or balanced enough) the document will miss its target.

imho, we have two solutions:

- either the document states that it is at an "early stage" of ongoing
investigation and removes statements that are, at this point in time,
interpretable and/or leading to early conclusions/ recommendations or
alike. hence, it can then become a WG document after re-spin. such
conclusions would be incorporated at final stage of analysis. 

- or if the document wants to maintain its current conclusions it needs
to re-inforce and complete its argumentation/analysis. in that case
however, it is not ready in its current form to become now a working
group doc.

-d.

> Sent: Monday, December 10, 2007 10:11 PM
> To: [email-masked]
> will become

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 14 Dec 2007 06:21:05 -0800

Dimitri,

> protocol operations and how degradations are impacting outside of this

Read section 3.3 of draft-morin-l3vpn-mvpn-considerations,
as it covers the issues you mentioned above.

> from PIM wrt to theoretical expectations/advantages from new BGP-based

The document compares different *technologies*, and makes recommendations
based on such comparison. Such comparison reflects underlying
properties/characteristics of these technologies. Since these are
the properties/characteristics of the technologies, these
properties/characteristics do not depend on whether these technologies
are deployed or not.

> however, it is not ready in its current form to become now a working

While one may argue that the argumentation/analysis is not perfect,
it is good enough for the draft to be accepted as an L3VPN WG
document. The argumentation/analysis could be perfected after
the document is accepted, and it would reflect the L3VPN WG
consensus.

Yakov.

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 14 Dec 2007 17:58:18 +0100

yakov,

> From: Yakov Rekhter [mailto:[email-masked]] 
> Sent: Friday, December 14, 2007 3:21 PM
> To: PAPADIMITRIOU Dimitri
> Cc: Ron Bonica; [email-masked]
> Subject: Re: draft-morin-l3vpn-mvpn-considerations 
> 
> Dimitri,
> 
> > hi ron, all
> > 

not possible to miss it. the problems i see are:

o) that exerpt from that section 3.3 reads

"BGP-based customer multicast routing clearly presents some advantages
   over the PIM-based alternatives.  However it has yet to be deployed
   within an operational MVPN, and service providers currently lack
   experience of its implementation.  By contrast, experience proves
   that PIM-based mechanisms are operationally viable, but with well
   identified limitations.  Some of those limitations may be improved
   upon (although there is currently no clearly defined proposal to do
   this), however some of the limitations appear to be intrinsic to the
   approach."

it is a general conclusion, meaning that either you detail "some"
limitations or you state the same for BGP that also comes with "some"
limitations (generic statements are to be used uniformly)

o) section 3.3 limits itself to a base analysis of the B interconnection
model and capabilities offered by PIM. for inst. it is not clear why one
would not consider PIM in combination with per AS-tree segmentation.

that section states there are robustness issues observed in PIM (if i
well understand because the section just refers to communication ?) but
do what do you define as robustness in the present case to come at the
conclusion reached that section ? 

that section states that there are security issues in PE-to-PE
communication - well i think that in any inter-AS exchange you will have
security issues anyway - the base point is that before concluding
anything specific on security it would be appropriate to complete the
analysis on security and document trade-offs in intermediate in data and
routing protocol exchanges for mVPN.

o) an approach may necessitate a specific mechanism. but this is not a
limitation. this is a confusion that occurs many times in that specific
section. if authors want to describe the additional mechanisms needed
one should agree about starting points/RFCs.

> properties/characteristics do not depend on whether these technologies

what i ask is to keep comparison at the same level. do not use
experimental experience to draw observation that are compared with
"theoretical" technological properties (having said this it is not
obvious without further analysis that the introdcution of multicast/mvpn
into BGP other than discovery would be verified)

> the document is accepted, and it would reflect the L3VPN WG

this would read to me: agree on the conclusions before having a
sufficient level of confidence on the analysis itself.

-d.

---

From: Rahul Aggarwal <[email-masked]>
Date: Fri, 14 Dec 2007 12:04:53 -0800 (PST)

Hi Ron,

I strongly support adopting this document as a WG draft.

To me the goal of draft-morin is to provide a set of
mandatory and optional, options (from the set of options in
draft-ietf-l3vpn-2547bis-mcast) that would allow SPs to deploy
inter-operable implementations using technology/options that the *SPs
want*.

This is a very important excercise for the L3VPN WG to progress on the
MVPN subject. draft-morin IMO is an excellent start towards this
excercise. It should be adopted as a WG document and can evolve to address
areas that require further work.

rahul

---

From: Thomas Morin <[email-masked]>
Date: Thu, 20 Dec 2007 14:02:24 +0100

Hi Dimitri,

Thanks for your comments, a few reply below...

> protocol operations and how degradations are impacting outside of this

The limitations of the Full PIM peering solution is something that has
been discussed quite a lot in this working group in the past years. But
you are right in highlighting that we should be more explicit. The aim
is not not repeat in mvpn-considerations many things that have been
already discussed a lot, but I think we can improve the doc by making a
few things more explicit (such as the limitations of PIM, as you
mentioned, but also as pointed out by Eric, on a few other points).

> and so they can not be elevated ? if this is the case where is the proof

We actually say that some limitations seem to offer place for
improvement, whereas some others appear as intrinsic. 

The reference (too implicit, I agree) is to elements such as the
scalability limitations of PIM that may be improved upon by improvements
of PIM such as the refresh reduction worked on by the PIM WG
(non-intrinsic limitation), and such as the fact that the use of PIM for
C-multicast routing doesn't offer the level of consistency between
unicast and multicast that the BGP approach is providing (intrinsic
limitation).

We will clarify this in the document.

> from PIM wrt to theoretical expectations/advantages from new BGP-based

Not exactly : we do also look at theoretical
aspects/advantages/drawbacks of the PIM approach.  

And as soon as experience is gained from the BGP approach, we should be
able to also talk in terms of experimental experience about this
approach.  

Thanks for your input,

-Thomas