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

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

Hi Thomas,

Thanks for your feedback !

I'm glad to see that you seem to be in agreement with revised scope of
the document.

See [SD]..[\SD] in-line for response to your specific comments and will
appreciate any others you might have. Our intent is certainly to make
any changes necessary to ensure document text is in line with its scope.

Thanks,
Silvija


-----Original Message-----
From: Thomas Morin [mailto:[e-mail]] 
Sent: Thursday, December 06, 2007 11:58 AM
To: Silvija Andrijic Dry (sdry)
Cc: [e-mail]; NAPIERALA, MARIA H, ATTLABS
Subject: Re: [bmwg] Updated:draft-sdry-bmwg-mvpnscale-03.txt

Hi Silvija, BMWG folks,

My apologizes for only sending my comments now.
I won't be able to attend bmwg meeting, but here are the general
comments I have after reading your updated proposal.

Having restructured the document in order to make it agnostic how mVPN
is designed, is definitely a good point, but I still have the concern
that the content itself is in many places still restricted to the
draft-rosen implementation. 

For instance:
- section 8.1 is supposedly generally applicable, but items 5,6, 7 only
apply to a deployment using PIM in the provider backbone

[SD] It is true that items 5,6,7 are applicable only when PIM is used in
the core, but it is necessary to report them in that scenario as their
value impacts system resources remaining for scaling of variables
defined as a metric.
Our intent was, rather than complicating text of Reported Results with
"if-then" statements to make this a superset that includes relevant data
for all architectures and for scenarios where for example PIM is not
used in the core then value of these variables will be = 0 in the
report. I still prefer that approach rather than complicating Reporting
Results list with "if-then" type of statements and I think there is
enough text in other areas of the document that explicitly state that
PIM doesn't have to be used in the core so shouldn't be any confusion.
But I don't have strong objections to changing text in section 8.1 if
that's what majority feels would be better. Comments ?
Perhaps, we should just add relevant variables for cases of MLDP and
P2MP-TE, and by same logic their value would be 0 when PIM is used. 
[\SD]

- section 9 is also supposedly generally applicable, but the test
procedure common to 9.8, 9.9, 9.10 is described in terms only applicable
to the PIM LAN procedures case

[SD] Can you point out which sentence you specifically refering to here?
Is it "mVPN 
     instance here includes C-instance state, OIFs, PIM neighborships 
     and data MDTs (S-PMSIs) as specified by Test Setup". ?
     If it's this one, I agree we should make it more clear ....perhaps
"mVPN 
     instance includes C-instance mroutes, C-instance OIFs, C-instance
PIM neighborships 
     and S-PMSIs as specified by Test Setup" ?
[\SD]   
     
- section 10.1 is supposedly specific to the case of PIM LAN procedures,
but could and should be made agnostic (writtent in terms of number of
VRFs per VPN instance, instead of "PIM neighbourships")

[SD] I was actually debating whether to make generic case where we look
at impact of number of PEs, in place of this test case which looks at
PIM neighborships for case where PIM is used to distribute C-instance
mroutes. Reason why we went this way is because for cases where PIM is
not used impact of number of PEs on PE router scale is I felt covered
sufficiently through other test cases such as  9.8. But since in case
where PIM is used, number of PIM neighborships device can scale to is
often one of the most asked questions we included this additional test
case which focuses on finding impact of PIM neighborships alone (i.e.
excluding impact additional C-instance mroute messaging between PEs has)
while minimizing impact of all other variables. If for example BGP is
used impact of BGP neighborships alone on PE device should be negligable
thus the test case in spirit of 10.1 wouldn't add too much value.
On other hand generic case written in terms of number of PEs would not
take away any value from this test case for PIM case, so I personaly
don't have objections to making the change in that direction. Only
drawback is that executors of the document will have to do one more test
case regardless of whether PIM is used or not, and regardless whether it
adds value or not for given architecture. Do you feel this additional
test case in cases when PIM is not used would provide significant value
to operators compared to test case 9.8 for example? 
[\SD]


- section 11 could also be made agnostic to the type of PMSI used
I have also other concerns which I'll take the time to share later, but
the above are my primary concerns, and while I don't deny the effort
made, major changes to the doc are still required to make it independent
of the design process for mvpn standardization in the l3vpn working
group.

Thank you,

-Thomas

Silvija Andrijic Dry (sdry):
> 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