RE: [bmwg] Updated:draft-sdry-bmwg-mvpnscale-03.txt

["Silvija Andrijic Dry (sdry)" <[e-mail]>]

Hi Rajiv,

Thanks for careful review of the document and your supportive comments.
See [SD] in line ....

-----Original Message-----
From: Rajiv Asati (rajiva) 
Sent: Wednesday, November 28, 2007 5:06 AM
To: Gunter Van de Velde (gvandeve); Silvija Andrijic Dry (sdry);
[e-mail]
Cc: NAPIERALA, MARIA H, ATTLABS
Subject: RE: [bmwg] Updated:draft-sdry-bmwg-mvpnscale-03.txt 

Dear Authors,

This document has shaped up really well. Few minor comments -


1) In Abstract and Introduction, special attention is given to the
'standard metric' in addition to the test methodology. 

I wonder whether it is necessary. The variables refered to by the metric
are used as the setup input(s) to the methodology, and implicitly
covered within. Is there more to it?  

[SD]Metric was actually intended to be test output describing overall
scalability of PE device. As you are aware MVPN scale is
multidimensional problem and there is no single number that can describe
scalability of MVPN PE device, so it's important to define the standard
tuple (which we call metric) so that results can be fairly compared. But
as you observed in each test case some of metric variables are included
in the test setup, while others were varied. That is done to reduce
multidimensional problem to finite set of tests. Let me know whether
this makes sense to you and let's discuss if you have any other ideas on
how to approach it.

2) The document uses the term 'metric', which may confuse those who
perceive 'metric' as a real nonnegative number analogous to link metric
(say). 

Perhaps, the intention was to use 'matrix' term instead!!

[SD] This is useful feedback. Let me see if we can come up with better
term. Do you feel there is confusion even though we defined what we mean
by metric at the beginning of the section 5 (MVPN Metric Definition)? Do
you think if we move that definition closer to the beginning of the
document would suffice?

3) While having route-reflector in the test topology is desirable, I
wonder whether it needs to be mandatory!! Perhaps, a bit of
clarification would be helpful.

	There are no of providers (albeit small) who don't 
	utilize route-reflector, and may be interested in
	this work. 

[SD] Good question. Reason why we included it as a requirement is to
ensure results done by different parties are comparable from MVPN
perpective. As in cases when there are large number of PEs (which is the
case most of the times), full mesh of BGP peerings among PEs would
utilize much larger amount of PE resources for BGP peerings compared to
case with RR. That in turn would leave less resources for MVPN and make
MVPN results for two cases uncomparable.
Perhaps we could change wording to SHOULD and add a note that lack of RR
use MUST be documented in test report?

4) On IPv6, I agree with Gunter. A clarification in this draft would be
good to include.  

Although, I thought that draft-ietf-l3vpn-2547bis-mcast-05.txt was
either IP version agnostic or included consideration for IPv6, if any,
but that didn't seem the case.

[SD] Agree. We will address this in next version.


5) It is important that the document provides flexibility to select one
of MVPN architectures (specified in "rosen-8" architecture" or
"draft-ietf- l3vpn-2547bis-mcast") for the mVPN benchmarking. It would
be sub-optimal to benchmark each and every mVPN architecture when there
is just one (or few) architecture being deployed.

[SD] I agree "draft-ietf- l3vpn-2547bis-mcast" provides large number of
protocol/options combinations and it's not practical not only to
benchmark but also to implement and deploy all of them. In L3VPN WG
there are proposals to reduce number of possible combinations (from
"draft-ietf- l3vpn-2547bis-mcast") to be implemented and deployed.

To address the same problem in benchmarking draft, in the latest version
we are proposing generic metric and methodology that is applicable
regardless of which "architecture" (from "draft-ietf-
l3vpn-2547bis-mcast") is being benchmarked. In addition we are proposing
couple of complementary test cases for only widely deployed
"architecture" from "draft-ietf- l3vpn-2547bis-mcast" (i.e. 'rosen-8'
"architecture") 
This approach should both ensure longevity of this work regardless of
which other "profiles" (besides PIM+GRE) end up being deployed in the
future and at the same time satisfies immidiate need to benchmark widely
deployed profile.
Let us know whether you agree with this approach.


Lastly, this draft provides value to the network operators deploying or
planning to deploy mVPN.

Cheers,
Rajiv
 

> -----Original Message-----
> From: Gunter Van de Velde (gvandeve)
> Sent: Wednesday, November 28, 2007 3:13 AM
> To: Silvija Andrijic Dry (sdry); [e-mail]
> Cc: NAPIERALA, MARIA H, ATTLABS
> Subject: RE: [bmwg] Updated:draft-sdry-bmwg-mvpnscale-03.txt
> 
> Hi Silvija and author team,
> 
> Nice document.
> 
> Would it be desirable (possible) to have the work IP version agnostic?
> 
> It is a brief question, but 'if' IPv6 gets full addoption the 
> impact/value of the draft is amplified. If it is not within the 
> forecasted scope then maybe a note in abstract or the introduction 
> could have value?
> 
> Nice to see this work happening,
> Groetjes,
> G/
> 
> -----Original Message-----
> From: Silvija Andrijic Dry (sdry)
> Sent: Tuesday, November 27, 2007 8:46 PM
> To: [e-mail]
> Cc: NAPIERALA, MARIA H, ATTLABS
> Subject: [bmwg] Updated:draft-sdry-bmwg-mvpnscale-03.txt
> 
> Hi BMWG members,
> 
> We would like to solicit your feedback on the new version of MVPN 
> scalability benchmarking proposal:
> http://www.ietf.org/internet-drafts/draft-sdry-bmwg-mvpnscale-03.txt
> 
> Note that in rev 03 we made couple of major changes based on feedback 
> from IETF68, namely:
> - scope is modified to include both generic sections applicable to all

> MVPN architectures specified in "draft-ietf- l3vpn-2547bis-mcast" and 
> sections specific to widely deployed "rosen-8" architecture
> - metric is changed to be architecture agnostic
> - text is rewritten to address changed scope of the document
> 
> We are looking forward to the discussion in Vancouver. And for those 
> of you that won't be able to attend the meeting we would greatly 
> appreciate your comments sent to the mailing list.
> 
> Thanks,
> Authors
> 
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, November 09, 2007 2:15 PM
> To: [e-mail]
> Subject: I-D ACTION:draft-sdry-bmwg-mvpnscale-03.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: Multicast VPN Scalability Benchmarking
> 	Author(s)	: S. Dry, et al.
> 	Filename	: draft-sdry-bmwg-mvpnscale-03.txt
> 	Pages		: 44
> 	Date		: 2007-11-9
> 	
> Multicast VPN (MVPN) is a service deployed by VPN service providers 
>    to enable their customers to use IP multicast applications over 
> VPNs.
> 
>    With the increased popularity the scalability of deploying such a 
>    service is becoming of a great interest. This document defines 
>    standard metric and test methodology for characterizing and 
> comparing
> 
>    control plane MVPN scalability of Provider Edge (PE) devices that 
>    implement MVPN service.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-sdry-bmwg-mvpnscale-03.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [e-mail] with the word unsubscribe in the body of

> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then "get 
> draft-sdry-bmwg-mvpnscale-03.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[e-mail].
> In the body type:
> 	"FILE /internet-drafts/draft-sdry-bmwg-mvpnscale-03.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.
> 
> _______________________________________________
> bmwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/bmwg
> 

_______________________________________________
bmwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bmwg