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

["Jay Karthik (jakarthi)" <jakarthi at cisco.com>]

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
events as well.

* 5.2 Can't the remote fault indication in the ethernet auto-negotiation
scheme be considered as a type of link failure indicator for directly
connected devices? In that configuration it doesn't need to rely on
layer3 failure detection.

Jay: Sure - we shall modify the text with your suggestion explicitly for
directly connected device.

* 5.6 Shouldn't reoptimization (signal a new LSP while the failure still
persists) be added to this section?

Jay - The authors discussed this and based on the comments we received
earlier, we have mentioned the make-before-break scenario towards the
end of section 8. Would you prefer that we include this in section 5.6
as well ?

* 5.7 If the failover is prefix/LSP dependent, chosing only 3 routes to
measure is not a good idea. In that case as much prefixes as possible
(limited by required accuracy and Throughput) are needed. Maybe a scheme
to randomly select as much prefixes as possible from the total number
could be considered. One can also first test if the failover is
prefix/LSP independent and make use of that characteristic to reduce the
number of traffic destinations that need to be measured. If there is a
dependency on the number of prefixes, the number of LSPs, ... then how
is this reflected in the measurements? Is only the fastest failover time
important, or the slowest, or the average?

Jay - Kris, we have not mandated 3 routes/streams. You probably picked
the 3 routes from the example we had furnished. We also mention at the
beginning of this section that more streams could be used as long as the
flow is steady across all the traffic streams/routes.

* 5.8 When tunnels are established from the Tester, it should be capable
to resignal/reoptimize LSPs following the receipt of a path error from
the PLR, just as real devices do

Jay - Sure but we did not see much value in including benchmarking
scenarios that would validate the Tester as opposed to the DUT. Btw,
most if not all of the testers we know do not support reoptimization as
of now.

* 6 It is confusing to mark R1 as HE and R2 as MID while their actual
roles may vary depending on the testcase

Jay - Not sure where the confusion arises from. We believe all the
different scenarios could be tested by positioning R1 and HE and R2 as
MID nodes

* 8 "Packet Size" is it layer2, layer3 ? "Forwarding rate" should be
"Offered Load"?

Jay - Packet Size is w.r.t layer3. Forwarding Rate is used in "IGP
dataplane convergence term" documents and we are consistent with that.

* 8 BGP routes, is this only applicable for VPN PEs?

Jay - We meant BGP routes from global table, just like we mentioned IGP
routes. Please note, we have explicitly listed VPN routes as well 

* 8 What is a "FRR tunnel", the primary or the backup? I think it's
important to indicate the scale of what is protected, besides the global
network scale. The Benchmarks need to indicate how they are measured,
which method.

Jay - "FRR tunnel" as in "Protected tunnel". We have left the decision
making on which method of the PBLM, TBLM and TBM to the individual
measuring the benchmarks.

* 8, p 24, bullet 1. s/Rate/Loss/

Jay - Not sure what you are referring to. I looked for this pattern and
don't see any.

* 8 The note at the end of the section should be more elaborated on (and
may have implications throughout the document).

Jay - We can elaborate on that.

<Snip>

Thanks,
Jay