Subject: [bmwg] comments on draft-sdry-bmwg-mvpnscale-00

From: Al Morton <[email-masked]>
Date: Wed, 31 Jan 2007 13:00:34 -0500

Silvija reminded me to type-up a few comments/suggestions
I had when I read this draft last year.

Al (as a participant)

Scope:

As a candidate work item, it's important to have a clear
Scope so that everyone understands what is proposed.
The Introduction section has some material in the 2nd
paragraph that should be part of the existing Scope section:

>    There are multiple proposals on architectures and protocols currently
>    in IETF for implementing MVPN service. This draft will describe
>    methodology for benchmarking MVPN scalability only for the
>    implementations following [ROSEN-8] or portion of [L3VPN-MCAST] which
>    uses PIM protocol to create 'tunnels' that instantiate MI-PMSIs (or
>    MDT tunnel) and S-PMSIs (or data MDT). We are limiting scope only to
>    above mentioned implementation as that is the only one deployed
>    today.

Also, spell-out all the acronyms at first usage:
>...MI-PMSIs (or MDT tunnel) and S-PMSIs (or data MDT).

These are some other points, spread around in the document, that
contribute to the Scope (you can find them with a search):

>       ...In this document it will be assumed
>      that MVPN service is deployed on the top of a "minimized" unicast
>      control plane.

>    We choose to limit the scope of this document so it is suitable for
>    standard comparison of disparate implementations. We included set of
                                                                  ^a
>    test cases (8.12-8.14) that will be helpful to operators with network
>    engineering for their deployments. Choices of values of variables in
>    test cases 8.12-8.14 were made using information from the MVPN
>    requirements survey conducted as part of [MVPN-REQ].
(I thought the paragraph above was very good.)

>    All P facing interfaces MUST use OSPF as IGP.

>    As the focus of this document is on the control plane scalability and
>    not on forwarding performance the data rate and packet size of
>    traffic flows can be chosen by user but it MUST be reported in the
>    test results.

>6  Test Categories, Stimulus and Execution Methodology
>
>    Following are two major test categories that this document addresses:
>
>   . Steady State Testing: DUT and network as a whole are not subject to
>      any failure stimulus/control plane events.
>   . Failure Recovery Testing: DUT and or network components are subject
>      to different failure stimulus that introduce one or more control
>      plane events.
(these categories are mentioned briefly in the current scope)

Other comments (non-scope-related):

3rd paragraph Intro:
>    Before describing the detailed test methodology, it is important to
>    review the key factors that impact scalability of MVPN deployments:
>
>    o The MVPN Metric: a set of variables that when combined indicates
>      the scalability capabilities of a PE device. MVPN scalability is
>      multi-dimensional and can not be quantified with single parameter
>      thus defining such a metric set is necessary. MVPN Metric will be
>      defined in section 4. The rest of this document focuses on a
>      methodology that characterizes different aspects of MVPN Metric.

It seems that you're talking about a set of related metrics or variables,
13 in all if you look ahead to section 4.  It might be more clear to say:

     o The MVPN Metric is a 13-tuple comprised of a set of variables that
       indicate the scalability of a PE device in various dimensions. ...

The current Scope section has a paragraph:

>    DUT (Device Under Test) term will be used interchangeably with MVPN
>    PE device. VPN related terms used in this document are defined in
>    RFC4364 and RFC2547bis. MVPN related terms used in this document are
>    defined in [ROSEN-8] and [L3VPN-MCAST].

We usually put this sort of info in an "Existing Terms" section.

In Section 6.1, item 6):

>      6) All multicast traffic MUST be received at all expected
>         destination test ports without any packet drops. This MUST be
>         verified using external test apparatus. If this state can not be
>         reached within 10 minutes of execution of step 5 test case
>         instance is considered failed and next test case instance with
>         reduced value of scaled variable/s needs to be performed.

Pass/Fail testing is not in the BMWG charter so this must be re-worded.
Something like:
                  ...  If this state can not be
         reached within 10 minutes of execution of step 5 test case,
 >>> then the "recovery time" is Undefined, and next test case instance with
         reduced value of scaled variable/s needs to be performed.
(not sure that you want to use recovery time, above, maybe just "recovery")

There are lots of other instances of "failure" in the draft,
these need to be re-worded, too.

I'd also be interested to know if the configuration parameters
are sufficiently generic in the opinion of other MVPN implementors.

That's it for now...

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