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

["Rajiv Asati (rajiva)" <[e-mail]>]

Hi Silvija,

Sorry about the delayed response. 

Please see inline,

> [SD]Metric was actually intended to be test output describing 
> overall scalability of PE device. As you are aware MVPN scale 

Is the term still intended in the same respect?

> [SD] This is useful feedback. Let me see if we can come up 
> with better term. Do you feel there is confusion even though 

Perhaps, an appropriate term needs to be considered, IMHO.

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

This should suffice.

Thanks.

Cheers,
Rajiv

> -----Original Message-----
> From: Silvija Andrijic Dry (sdry) 
> Sent: Wednesday, December 05, 2007 12:35 AM
> To: Rajiv Asati (rajiva); Gunter Van de Velde (gvandeve); 
> '[e-mail]'
> Cc: 'NAPIERALA, MARIA H, ATTLABS'
> Subject: RE: [bmwg] Updated:draft-sdry-bmwg-mvpnscale-03.txt 
> 
> 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