Re: [bmwg] Proposal: Network Service Layer Abstract Model

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Sean,
Thanks for preparing a draft to describe your proposal.

Comments:

The Node, Topo, and INFRA portions of the model
might be useful in benchmarking. It seems to me
that we are already collecting most of this information
in the process of documenting the test config. so
the test can be repeated. However, there is much
more detailed information (beyond what is
mentioned here) that would need to be
modeled in a general (non-vendor specific) way,
to fully support benchmarking.  As mentioned in several
BMWG RFCs - Virtual network function benchmarking is a
critical need at this time, so any new model needs to
serve the non-physical testing scenarios as well, noting that
there is a vast expansion of configuration details
for VNFs and their Infrastructure.

regards,
Al
(as a participant)

> -----Original Message-----
> From: bmwg [mailto:[e-mail]] On Behalf Of Sean Wu
> Sent: Thursday, November 02, 2017 10:49 PM
> To: [e-mail]
> Subject: [bmwg] Proposal: Network Service Layer Abstract Model
> 
> Hello BMWG,
> 
> Missed the submission deadline, sending out here for comments. Draft
> itself needs improvement in both content and format wise, and will be
> formally submitted once the portal reopens.
> 
> Most of the past benchmarking methodology is for device level, or a
> given service, feature, or protocol. Sometimes, we call it black box or
> white box testing. With advanced intelligence built in the
> infrastructure, more and more underlying details are now taken care of
> by the device/controller, and users can focus on intent-based network
> solutions. As a result, we need a black network or white network level
> benchmark test.
> 
> Network Service Layer Abstract Model (NSLAM) is a high level abstraction
> with four supporting pillars: infrastructure, services, capacity, and
> performance. A set of sufficient but not exhaustive metrics are selected
> to define characteristics of each layer. The capacity here refers to a
> collection of route/traffic profiles that define the requirements for
> the network services. We can use the same capacity requirements to
> benchmark alternative implementations using different products or
> protocols. Boundary has been blurred between layer 2 and layer 3 these
> days.
> 
> Any comments/feedback would be appreciated. If you are interested to
> collaborate on this draft, I'll be more than happy to take some help.
> 
> Thanks,
> Sean