[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [bmwg] Updated:draft-sdry-bmwg-mvpnscale-03.txt
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);
> 'bmwg at ietf.org'
> 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); bmwg at ietf.org
> 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); bmwg at ietf.org
> > 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: bmwg at ietf.org
> > 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: Internet-Drafts at ietf.org [mailto:Internet-Drafts at ietf.org]
> > Sent: Friday, November 09, 2007 2:15 PM
> > To: i-d-announce at ietf.org
> > 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
> > i-d-announce-request at ietf.org 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:
> > mailserv at ietf.org.
> > 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
> > bmwg at ietf.org
> > https://www1.ietf.org/mailman/listinfo/bmwg
> >
>
_______________________________________________
bmwg mailing list
bmwg at ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg