headers
Rajiv Asati (rajiva | 1 Dec 2007 04:08
Picon
Favicon

RE: Updated draft on MPLS forwardingBenchmarking:draft-akhter-bmwg-mpls-meth-03.txt

Hi Rajiv,

Thanks for your support. 

Good catch about the 2 or more label scenario (in section 6). That
excerpt was supposed to be deleted. Glad you pointed out. Your
suggestion regarding the section 6.4 and 6.5 is also worth
incorporating. 

Thanks again for your careful review and feedback. 

Cheers,
Rajiv

> -----Original Message-----
> From: Rajiv Papneja [mailto:rpapneja <at> isocore.com] 
> Sent: Thursday, November 29, 2007 2:12 PM
> To: Aamer Akhter (aakhter)
> Cc: bmwg <at> ietf.org
> Subject: RE: [bmwg] Updated draft on MPLS 
> forwardingBenchmarking:draft-akhter-bmwg-mpls-meth-03.txt
> 
> Hello Aamer, Rajiv
> 
> Thanks for sending the pointer to your dradt for review. 
> Considering that
> there is an ongoing effort on LDP, and RSVP-TE convergence 
> benchmarking this
> work complements the two efforts. I do support this work, 
> however I do have
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jay Karthik (jakarthi | 3 Dec 2007 23:28
Picon
Favicon

RE: Updated draft on MPLS forwarding Benchmarking:draft-akhter-bmwg-mpls-meth-03.txt

Aamer, Rajiv,

IMO version 3 is in a good shape and more readable than the original
version.

Is forwarding benchmarking in load-balancing scenarios, "in" scope or
"out" w.r.t this memo ?

Also I wanted to highlight that MPLS-to-MPLS is not a "swap" all the
time. In a locally repaired LSP, MPLS-to-MPLS would need another
"imposition". Is it not ?

Cheers,
Jay

-----Original Message-----
From: Aamer Akhter (aakhter) 
Sent: Monday, November 26, 2007 12:06 PM
To: bmwg <at> ietf.org
Subject: [bmwg] Updated draft on MPLS forwarding
Benchmarking:draft-akhter-bmwg-mpls-meth-03.txt

Hello BMWG,

We would like to bring to your attention the updated draft on basic MPLS
forwarding that we will be submitting to the IETF as an individual
submission (once submissions opens up again). There have been
significant changes since the last version of the draft including:

* removal of many test cases thought to be out of scope
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rajiv Asati (rajiva | 4 Dec 2007 20:53
Picon
Favicon

RE: MPLS forwarding Benchmarking:draft-akhter-bmwg-mpls-meth-03.txt

Hi Silvija,

Thanks a lot for the support and careful review. 

1) Good point about multicast exclusion and IPv6. We tried to align the
MPLS benchmarking with IP (v4/v6) benchmarking documents, and none of
them included any explicit verbiage for multicast. 

Nonetheless, this is a worthy point, and we will update the scope/draft
accordingly.

2) I agree that more text can be added to clarify test setup (in section
6) wrt section 4.1.5.1. Perhaps, section 4.1.5.1 may be updated as -

"In all cases the sent traffic MUST be accounted for, whether it was
received on the wrong port, correct port or not received at all.
Specifically, Traffic loss (also referred to as frame loss) is defined
as the traffic (or frame) not received where or as expected (i.e.
received on incorrect port, or received with incorrect layer2 or above
header information etc.). In addition, the MPLS header...."

3) We will update the Section 6.5 accordingly. This was suggested by
another reviewer as well. The plan is to update the section with the
following examples -

	device/hardware reset - RouteProcessor card resetting (e.g. OIR)
	software reset - reset initiated through a CLI  

Please note that "power interruption" is to be carried out as an
additional reset per RFC2544 section 26.6.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Silvija Andrijic Dry (sdry | 5 Dec 2007 05:40
Picon
Favicon

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

Hi Gunter,

Thanks for reviewing the document and supporting this work.

That's good point. Being IPv6 version agnostic would be beneficial long
term however at this time IPv6 is not within current document scope. We
will consider that possibility for the next document version and make
explicit statement in the scope either way we decide.

Thanks,
Silvija

-----Original Message-----
From: Gunter Van de Velde (gvandeve) 
Sent: Wednesday, November 28, 2007 12: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?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Silvija Andrijic Dry (sdry | 5 Dec 2007 06:34
Picon
Favicon

RE: 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Al Morton | 5 Dec 2007 06:56
Picon
Favicon

Calling all Presenters for IETF-70...

... please send me your slides.

(I already received Jay's, so he wins first choice
of the seats in the Oak room)

Al
Permalink | Reply | 0 comments |
headers
Al Morton | 5 Dec 2007 15:59
Picon
Favicon

Re: I-D ACTION:draft-ietf-bmwg-protection-term-03.txt

Comments on:

At 10:15 AM 11/13/2007, Internet-Drafts <at> ietf.org wrote:

>         Title           : Benchmarking Terminology for Protection Performance
>         Author(s)       : S. Poretsky, et al.
>         Filename        : draft-ietf-bmwg-protection-term-03.txt
>         Pages           : 24
>         Date            : 2007-11-13
>

We have more time to work this, and a couple of definitions
here strike me as unnecessarily complex, in that they
refer to other terms we are trying to define when normal
language would suffice, IMO.

We can discuss these at the session.

Like this:
>      3.3.1.  Failover Event
>
>        Definition:
>        The occurrence of a planned or unplanned action in the network
>        that results in a change in the Path that data traffic traverses.
could be:
      3.3.1.  Failover Event

        Definition:
        The occurrence of a planned stoppage or malfunction in the network
        that results in a change in the Path that data traffic traverses.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Adrian Farrel | 5 Dec 2007 19:11
Picon

draft-ietf-bmwg-protection-term-03.txt

Hi,

Sorry, I only just became aware of this work.

Please consider aligning terminology with RFC 4427 produced by CCAMP. This 
derives terms from:
- RFC 3386
- G.808.1
- G.841

Of course, there are many other sources of terminology for protection 
features.

Thanks,
Adrian
Permalink | Reply | 0 comments |
headers
Al Morton | 6 Dec 2007 06:44
Picon
Favicon

Re: I-D ACTION:draft-ietf-bmwg-igp-dataplane-conv-term-14.txt

I found a few small problems in this one:

>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the Benchmarking Methodology Working 
>Group of the IETF.
>
>         Title           : Terminology for Benchmarking Link-State 
> IGP Data Plane Route Convergence
>         Author(s)       : B. Imhoff, S. Poretsky
>         Filename        : draft-ietf-bmwg-igp-dataplane-conv-term-14.txt

Al
(participant)

OLD
    3.3 Network Convergence

         Definition:
         The completion of updating of all routing tables, including
         distributed FIBs, in all routers throughout the network.

         Discussion:
         Network Convergence requires completion of all Route
         Convergenceoperations for all routers in the network following
NEW
         Convergence operations for all routers in the network following

Section 3.12
(Continue reading)

Permalink | Reply | 0 comments |
headers
Al Morton | 6 Dec 2007 07:13
Picon
Favicon

RE: I-D ACTION:draft-ietf-bmwg-igp-dataplane-conv-term-14.txt

At 12:47 AM 12/6/2007, Poretsky, Scott wrote:
>Are you proposing to replace "per second" with "during each second"?
>
>Scott

Yes, but I mostly want us to say exactly what we mean here
in a simple and clear way.

If what's really meant is:

Packets must be offered to every route in the FIB at a rate of
at least one packet per second.

then just say that.

We can word-smith this more tomorrow,
Al
Permalink | Reply | 1 comment |

Gmane