Re: WGLC: draft-ietf-bmwg-protection term-06 and meth-05

At 12:27 PM 7/31/2009, Al Morton wrote:
>...
>I'm hoping to finish this task on the flight home...
>
>At 02:24 PM 7/2/2009, Al Morton wrote:
>>This message begins a Last call on the Sub-IP Protection terms and methods.
>>
>>http://tools.ietf.org/wg/bmwg/draft-ietf-bmwg-protection-term/
>>http://tools.ietf.org/wg/bmwg/draft-ietf-bmwg-protection-meth/

Comments on term-06:

Section 1.2

While the General Model applies well to some protection
mechanisms (e.g. SONET), it omits key aspects of others.
Since the first technology bmwg where bmwg is applying these
terms is MPLS-FRR, and MPLS-FRR is not well-described by the
General Model, it seems appropriate to give the reader
a heads-up. So at the end of Sec 1.2, I suggest:
NEW
Some protection switching technologies may use a series of
steps that differ from the general model. The specific differences
SHOULD be highlighted in each technology-specific methodology.
Note that some protection switching technologies are endowed
with the ability to re-optimize the working path after a
node or link failure.

Section 3.5 (and 3.6) - suggested top-level text:
The following Benchmarks MAY be assessed on a per-flow basis using

Re: Draft minutes from IETF-75

I've fixed the right-margin problem on the flight home
(apparently), completed more editing/clean-up,
and received some positive feedback on the minutes.

The revised version is available at the URL below,
Al
bmwg chair

At 05:15 AM 7/29/2009, Al Morton wrote:
>the draft minutes are here:
>http://www.ietf.org/proceedings/75/minutes/bmwg.html
>
>there is a right margin problem with the HTML file,
>and there will be more editing, but info is readable!
>
>comments to me,
>Al
>bmwg chair

Re: WGLC: draft-ietf-bmwg-protection term-06 and meth-05

Hi,

Please find some comments/questions below.

comments on term-06:

* The definitions don't seem to be consistent. A "Path" is defined in the draft as a sequence of nodes/links
from R1 (ingress of IP
packets) and Rn (egress of IP packets). Other definitions in the draft point out that a "Backup Path" is not
necessarily end-to-end,
but can start and end at any node along the "Primary Path". If the Backup Path is not end-to-end, one can also
not claim that the
Backup Path becomes the Working Path upon a Failover Event.

* It needs to be made clear that the definitions of the different paths are not applicable to MPLS TE LSPs. The
definition of a path
in the draft is a physical sequence of nodes/links, while a TE LSP is a logically signalled path. A headend
may resignal a new TE
LSP following a failure. This new TE LSP may in general follow another sequence of nodes/links and may
possibly no longer be routed
over the "backup TE LSP" while the failed link/node is still not restored.

* I think it is difficult to distinguish Failover Events (for sub-IP) from Convergence Events (for IGP).
The distinction is possible
for e.g. SONET APS. But how do we distinguish the two for e.g. MPLS TE FRR? A link or node failure will trigger
IGP convergence as
well in that case and could potentially result in additional packet loss.

* The Benchmarks (3.5) give no detail about which packet loss needs to be observed. Is it for traffic going
over all Primary Paths,

Re: WGLC: draft-ietf-bmwg-protection term-06 and meth-05

Hi Kris,

Thanks for your detailed review. I have responded to your comments on
the methodology draft here. We will get back with our response to your
comments on the terminology draft.

Please see inline.

Cheers,
Jay

-----Original Message-----
From: bmwg-bounces <at> ietf.org [mailto:bmwg-bounces <at> ietf.org] On Behalf Of
Kris Michielsen (kmichiel)
Sent: Monday, August 03, 2009 9:56 AM
To: 'Al Morton'; bmwg <at> ietf.org
Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-protection term-06 and meth-05

<Snip>

comments on meth-05:

* 5.1 I don't think shutdown is a good method to simulate a failure
since the actions taken by a shutdown are very much implementation
dependent. Shutdown should only be considered as an administrative
action.

Jay: Agreed that the shutdown is very much implementation dependent and
hence the reason for including this as failover trigger event. As you
can see this is 1 of the failure events and we have listed a few other

Re: WGLC: draft-ietf-bmwg-protection term-06 and meth-05

Jay,

see below.

> -----Original Message-----
> From: Jay Karthik (jakarthi) [mailto:jakarthi <at> cisco.com] 
> Sent: 04 August 2009 19:33
> To: Kris Michielsen (kmichiel); Al Morton; bmwg <at> ietf.org
> Subject: RE: [bmwg] WGLC: draft-ietf-bmwg-protection term-06 
> and meth-05
> 
> Hi Kris,
> 
> Thanks for your detailed review. I have responded to your 
> comments on the methodology draft here. We will get back with 
> our response to your comments on the terminology draft.
> 
> Please see inline.
> 
> Cheers,
> Jay
> 
> -----Original Message-----
> From: bmwg-bounces <at> ietf.org [mailto:bmwg-bounces <at> ietf.org] On 
> Behalf Of Kris Michielsen (kmichiel)
> Sent: Monday, August 03, 2009 9:56 AM
> To: 'Al Morton'; bmwg <at> ietf.org
> Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-protection term-06 
> and meth-05
> 

Re: WGLC: draft-ietf-bmwg-protection term-06 and meth-05

Kris,

The purpose of the BMWG is to develop informational standards to
benchmark performance of different vendor implementations.  If every
vendor has the same implementation then there would be no need for BMWG
because every vendor would have the same performance.  How a Cisco admin
shut impacts layer 3 performance versus a Juniper admin shut is a very
real world performance issue that is within scope of the BMWG.

Scott

-----Original Message-----
From: bmwg-bounces <at> ietf.org [mailto:bmwg-bounces <at> ietf.org] On Behalf Of
Kris Michielsen
Sent: Wednesday, August 05, 2009 12:04 PM
To: 'Jay Karthik (jakarthi)'; 'Al Morton'; bmwg <at> ietf.org
Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-protection term-06 and meth-05

Jay,

see below.

> -----Original Message-----
> From: Jay Karthik (jakarthi) [mailto:jakarthi <at> cisco.com] 
> Sent: 04 August 2009 19:33
> To: Kris Michielsen (kmichiel); Al Morton; bmwg <at> ietf.org
> Subject: RE: [bmwg] WGLC: draft-ietf-bmwg-protection term-06 
> and meth-05
> 
> Hi Kris,

Re: WGLC: draft-ietf-bmwg-protection term-06 and meth-05

Scott,

I'm not arguing against testing performance when administratively taking a link out of service. It's
indeed a valid real world
performance issue. But a network adminstrator that cares about customer network uptime usually doesn't
do that by a plain interface
shutdown instead of following procedures such as set overload bit, cost-out link, shut adjacency, ...

I have a problem with claiming that an interface shutdown is a _failure_ scenario. Please reread my comment
below with the example
of implementations "A" and "B". Which of the two devices is the best performing (and hence expected to show
the best benchmark
metric) in your opinion?

Performance of taking an interface adminstratively out of service (using a real procedure/sequence of
actions chosen by the
user/tester -- even plain interface shutdown if that is what the user/tester cares about) should be
measured, but under the title of
Adminstrative Actions, not claiming it to be a failure.

Thanks,
Kris

> -----Original Message-----
> From: Scott Poretsky [mailto:sporetsky <at> allot.com] 
> Sent: 05 August 2009 18:52
> To: Kris Michielsen; Jay Karthik (jakarthi); Al Morton; bmwg <at> ietf.org
> Subject: RE: [bmwg] WGLC: draft-ietf-bmwg-protection term-06 
> and meth-05
> 

Re: WGLC: draft-ietf-bmwg-protection term-06 and meth-05

I agree with Kris. In fact, one would reason that the interface failure
due to 'shutdown' (executed by the admin) may provide different result
from that of the interface failure that happened on its own (fiber cut,
for ex).

It is a mere title change, IMO.

Cheers,
Rajiv

> -----Original Message-----
> From: bmwg-bounces <at> ietf.org [mailto:bmwg-bounces <at> ietf.org] On Behalf
Of Kris
> Michielsen (kmichiel)
> Sent: Thursday, August 06, 2009 4:23 AM
> To: 'Scott Poretsky'; Jay Karthik (jakarthi); 'Al Morton';
bmwg <at> ietf.org
> Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-protection term-06 and
meth-05
> 
> Scott,
> 
> I'm not arguing against testing performance when administratively
taking a
> link out of service. It's indeed a valid real world
> performance issue. But a network adminstrator that cares about
customer
> network uptime usually doesn't do that by a plain interface
> shutdown instead of following procedures such as set overload bit,
cost-out

Re: WGLC: draft-ietf-bmwg-protection term-06 and meth-05

Great.  We will maintain the 'shutdown' test case in the document.

Scott

-----Original Message-----
From: Rajiv Asati (rajiva) [mailto:rajiva <at> cisco.com] 
Sent: Monday, August 10, 2009 5:30 PM
To: Kris Michielsen (kmichiel); Scott Poretsky; Jay Karthik (jakarthi);
Al Morton; bmwg <at> ietf.org
Subject: RE: [bmwg] WGLC: draft-ietf-bmwg-protection term-06 and meth-05

I agree with Kris. In fact, one would reason that the interface failure
due to 'shutdown' (executed by the admin) may provide different result
from that of the interface failure that happened on its own (fiber cut,
for ex).

It is a mere title change, IMO.

Cheers,
Rajiv

> -----Original Message-----
> From: bmwg-bounces <at> ietf.org [mailto:bmwg-bounces <at> ietf.org] On Behalf
Of Kris
> Michielsen (kmichiel)
> Sent: Thursday, August 06, 2009 4:23 AM
> To: 'Scott Poretsky'; Jay Karthik (jakarthi); 'Al Morton';
bmwg <at> ietf.org
> Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-protection term-06 and
meth-05

I-D Action:draft-ietf-bmwg-mpls-forwarding-meth-05.txt

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           : MPLS Forwarding Benchmarking Methodology for IP Flows
	Author(s)       : A. Akhter, et al.
	Filename        : draft-ietf-bmwg-mpls-forwarding-meth-05.txt
	Pages           : 31
	Date            : 2009-08-10

This document describes a methodology specific to the benchmarking
of Multi-Protocol Label Switching (MPLS) forwarding devices, limited
to the most common MPLS packet forwarding scenarios and delay
measurements for each, considering IP flows. It builds upon the
tenets set forth in RFC2544, RFC1242 and other IETF Benchmarking
Methodology Working Group (BMWG) efforts.  This document seeks to
extend these efforts to the MPLS paradigm.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-mpls-forwarding-meth-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________