headers
Jay Karthik | 1 Nov 2011 17:54
Picon
Favicon

Re: draft-varlashkin-router-conv-bench-00

Ilya, thanks for all the clarification.

Please see inline - got an additional comment.

Thx,
Jay

On 10/25/11 3:17 PM, "Ilya Varlashkin" <ilya <at> nobulus.com> wrote:

> Hi Jay,
> 
> thank you for your comments. Please see responses inline.
> 
> On Oct 25, 2011, at 02:07 , Jay Karthik wrote:
> 
>> Rajiv, Ilya,
>> 
>> Could you include what is out of scope for this document ? As I read this
>> initial version, I am reminded of the failure detection methodology, ECMP,
>> concurrent failures, span failure (A single span cut in the fiber network
>> can cause multiple link failures at other layers).
>> 
> 
> There are failure scenarios described in Section 5. The intention was to limit
> tests to those scenarios because they're clear in regards to what's failing
> and what reaction to expect. If you believe that some scenarios should be
> changed or more scenarios need to be added, we could discuss this possibility.
> Please note that the goal of the document is to produce a methodology that
> depends only on DUT performance, i.e. performance of other systems (however
> good or bad) either doesn't affect results at all or can be obtained prior the
(Continue reading)

Permalink | Reply | 1 comment |
headers
iLya | 1 Nov 2011 18:40

Re: draft-varlashkin-router-conv-bench-00

Hi Jay,

--------------------------------------------------
From: "Jay Karthik" <jakarthi <at> cisco.com>
Sent: Tuesday, November 01, 2011 5:54 PM
To: "Ilya Varlashkin" <ilya <at> nobulus.com>
Cc: "Rajiv Papneja" <Rajiv.Papneja <at> huawei.com>; "Scott Poretsky" 
<sporetsky <at> allot.com>; "IETF BMWG" <bmwg <at> ietf.org>
Subject: Re: [bmwg] draft-varlashkin-router-conv-bench-00

> Snippet from your ID -
> <start-quote>
>   When a failure occurs on the network a router needs to:
>
>   1.  select new best path so that the packets, which already arrived
>       to the router, can be forwarded
>
>   2.  let other routers know about new network state so they can find
>       new best path from their perspective
>
> <end-quote>
>
> Convergence is dependent on how rapidly you detect a failure. You explain
> what a node needs to do when a failure occurs but I am wondering if you
> should add more color on how you are detecting it. Depending on whether 
> the
> failure is a local or remote failure & your detection mechanish - 
> different
> protocols/layers come in to play & the expected behavior on the DUT might
> change accordingly. Do you agree ?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kenneth Green | 2 Nov 2011 04:04
Favicon

Re: draft-green-bmwg-seceff-bench-meth-00

RFC2647 provides this useful definition:

3.19 Illegal traffic
  Definition:
    Packets specified for rejection in the rule set of the DUT/SUT.
  Discussion:
    A buggy or misconfigured firewall might forward packets even though
    its rule set specifies that these packets be dropped. Illegal   traffic differs
    from rejected traffic in that it describes all  traffic specified for rejection
    by the rule set, while rejected  traffic specifies only those packets actually
    dropped by the DUT/SUT.

We have described "evil" traffic as being in one of two classes, either malicious traffic intended to
invade/damage/exploit the target or banned/disallowed traffic being that which is related to attempts
to access disallowed sites or services, or to export proprietary information that is not allowed outside
of the protected network.

It is useful in the prose to have language that naturally evokes the inherent contrast between traffic that
should pass through and traffic that should be blocked. Hence the natural opposites of "good" and "evil"
seemed appropriate.

However, the definition of "Illegal" given in 2647 does seem to encompass all packets that would be
considered "evil" so long as the concept of "specified for rejection in the rule set of the DUT" is
considered sufficiently broad to apply to whatever configuration features might be present in an NGF,
IPS or UTM system which might go beyond ACLs and the like.

Regards,
Kenneth

Kenneth Green
(Continue reading)

Permalink | Reply | 0 comments |
headers
Al Morton | 7 Nov 2011 01:54
Picon
Favicon

Draft Agenda Posted...

http://www.ietf.org/proceedings/82/agenda/bmwg.txt
now that I'm back from last week's meeting.

see you in Taipei,
Al
bmwg chair
Permalink | Reply | 0 comments |
headers
Romascanu, Dan (Dan | 7 Nov 2011 18:57
Favicon

Call for Volunteers for the Performance Metrics Directorate

The IESG recently approved RFC 6390 which describes a framework and a
process for developing Performance Metrics of protocols and applications
transported over IETF-specified protocols.  The scope of the document is
complementary to the scope of the IPPM WG and BMWG focusing on metrics
of protocols above and below the IP layer that can be used to
characterize performance on live networks, 

Section 2.2 of the document recommends the formation of a specialized
directorate: 

   The Performance Metrics Directorate is a directorate that provides
   guidance for Performance Metrics development in the IETF.

   The Performance Metrics Directorate should be composed of experts in
   the performance community, potentially selected from the IP
   Performance Metrics (IPPM), Benchmarking Methodology (BMWG), and
   Performance Metrics for Other Layers (PMOL) WGs.

Further details are available in Section 6 of RFC 6390. 

There are already a number of volunteers to start the directorate but we
can use more expert minds. If you are interested in volunteering or
would like to hear more details please approach me or Al Morton. We can
discuss more during IETF-82 for those who will make the trip to Taipei. 

Thanks and Regards,

Dan
Permalink | Reply | 0 comments |
headers
Al Morton | 8 Nov 2011 16:22
Picon
Favicon

Re: Draft Agenda Posted...

Thanks to all who provided feedback!

The revised, pseudo-final agenda is here:
https://datatracker.ietf.org/meeting/82/materials.html
(along with all other WGs and materials).

PRESENTERS:  Please send me your slides by Friday, 11/11/11!

This will give us a chance to iterate and improve discussion
possibilities, if necessary...

regards,
Al
bmwg chair

At 07:54 PM 11/6/2011, Al Morton wrote:
>http://www.ietf.org/proceedings/82/agenda/bmwg.txt
>now that I'm back from last week's meeting.
>
>see you in Taipei,
>Al
>bmwg chair
Permalink | Reply | 2 comments |
headers
Kenneth Green | 11 Nov 2011 03:27
Favicon

Re: draft-green-bmwg-seceff-bench-meth-00

Dennis,

Thank you for your comments and my apologies for the delayed response, I never saw this message in my email
but fortunately a colleague recently forwarded a copy to me.

Selecting attacks 
=============
This is indeed a pivotal issue and probably the most difficult to resolve.  To a degree the same issue
challenges the security performance ID both in terms of the attacks and the background traffic mix. 

From a purist benchmark perspective a statically defined set of attacks is the best way to ensure
apples-to-apples comparisons between test results. However, the very nature of this security
effectiveness testing requires the set of attacks to be appropriately current or else there will be
limited value to the measured outcome in terms of relevance to operation in the contemporary threat environment.

Even if we cannot be totally prescriptive about the list of attacks, the document will define how the
measurements are made and how traffic and results are to reported and this will underpin the validity of
comparisons between test runs.

Addressing the problem of attack list definition is work-in-progress and it is early days.

Mechanisms for distinguishing between legal and illegal traffic
================================================
My premise is that it is central to the role of all defensive devices that they must have one or more
mechanisms to distinguish between legal and illegal traffic. You correctly point out that there are a
variety of mechanisms (signature/pattern recognition, reputation etc.) but that does not change the
fact that discrimination is the task at hand.

It is possible that not all features or all classes of defensive box will fall under the umbrella of this
draft. The goal is to define tests that are broadly applicable.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peoples, Cathryn | 11 Nov 2011 10:14
Picon

[CfP] IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) - April 16, 2012 - Maui, Hawaii, USA

-----------------------------------------------------------------------------------------------------
 Please accept our apologies if you receive multiple copies of this CfP
-----------------------------------------------------------------------------------------------------

IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) 
==================================================================================
16 April 2012
Maui, Hawaii, USA
http://www.manfi.org

CALL FOR PAPERS
---------------
The Fourth IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) will be
held in conjunction with IEEE/IFIP NOMS 2012 in Maui, Hawaii, USA, from April 16-20, 2012. The workshop is
sponsored by the IEEE Communications Society (ComSoc) and supported by POSTECH ITCE, Ghent
University-IBBT, NEC, and Ericsson LM. The workshop is endorsed by the Technical Committee on Network
Operations and Management (CNOM).
It is widely agreed that, despite its many successes, the current Internet also has a set of systemic
problems, ranging from an upcoming shortage of IP addresses to insufficient security. However, the lack
of scalable and agile manageability is arguably more important, as without management, it is impossible
to build systems that adapt the services and resources offered in a context-dependent manner.
In either case (clean slate vs. evolution vs. revolution) we must consider the manageability of the Future
Internet from the beginning. Following the success of the three previous editions of this workshop, held
in conjunction with IM 2009, NOMS 2010 and IM 2011, ManFI 2012 aims at providing an international forum for
researchers in these and similar areas. ManFI 2012 will combine original full paper presentations with a
motivating keynote, quick hot topic presentations and a panel discussion to thoroughly explore this
challenging topic.

Topics of interest
------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Al Morton | 13 Nov 2011 04:18
Picon
Favicon

Flow Export Issue#2: Test Device Capacity

At 01:23 PM 10/2/2011, Jan Novak (janovak) wrote:

>==========PJ ===============
>
>Section 4.1:
>
>     In all measurements, the export
>     interface MUST have enough bandwidth to transmit Flow Export data
>     without congestion. In other words, the export interface MUST NOT be
>     a bottleneck during the measurement.
>
>
>PJ: What if the receiving interface, or the collector itself, is a 
>bottleneck? Previously you said it doesn't matter, and I disagreed.
>
>- data could be lost at the receiving end, making the DUT look worse 
>than it really is.
>
>==========PJ ===============
>
>I answered this in the previous review already:
>http://www.ietf.org/mail-archive/web/bmwg/current/msg02413.html
>
>I believe this is all covered in the section 4.4 already
>

Jan,

I see that Collector packet dropping issues (due to resource limits)
are covered (in Sec 4.2 and 4.4), but I don't see anything specific
(Continue reading)

Permalink | Reply | 0 comments |
headers
Al Morton | 13 Nov 2011 04:40
Picon
Favicon

Flow Export Issue #3:

At 01:23 PM 10/2/2011, Jan Novak (janovak) wrote:

>==========PJ ===============
>
>Section 4.2:
>
>     The DUT export interface (see Figure 2) MUST be configured with
>     sufficient output buffers to avoid dropping the Flow Export data due
>     to a simple lack of resources in the interface hardware.
>
>PJ: then it might not be configured as it would in real life 
>conditions. Wouldn't it be better to record the real-life results 
>than to tweak the settings just for testing purposes?
>
>- eg, consider if the DUT operates with insufficient buffers in the 
>real-world scenario, and therefore drops a lot more data than when 
>testing under "ideal" conditions in the lab.
>
>==========PJ ===============
>
>I would like to disagree here. We are not measuring real life
>scenario here. We are trying to measure the maximum what the
>DUT can do. In real life you would also configure the export interface
>(if there is one dedicated at all - see the discussion in Appendix
>B) not to drop the export packets.

The test designer has the freedom to run tests in multiple
configurations. It is therefore possible to run both ideal
and "real-world" configurations, according to the needs of the
tester.  All configurations MUST be fully documented.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane