Re: [bmwg] Last Call: <draft-ietf-bmwg-protection-meth-09.txt> (Methodology for benchmarking MPLS protection mechanisms) to Informational RFC

[Gregory Mirsky <[e-mail]>]

Hi Jay, et al.,
thank you for your careful consideration of my comments. Couple more notes on -10 version follow:

 *
"MPLS-FRR" might be interpretted as both MPLS-TE-FRR and LDP-FRR. I would consider using in the document MPLS-TE-FRR or RSVP-TE-FRR.
 *
Section 5.2 I think that "Ethernet based links do not have layer 2 failure indicators, and therefore relies on layer 3 signaling for failure detection" is not entirely accurate. I'd point to IEEE 802.1ag/CFM and Y.1731 that can be used to monitor continuity among MEPs of specified MA/MEG. Thus use of Layer 3 is not required but optional.
 *
Section 5.2 In reference to BFD "These methods can be used for the layer 3 failure indicators ..." I'd note that BFD can be used in ACH, i.e. non-IP, encapsulation to monitor LSP, Segment or Section.
 *
Section 5.6 Restoration and Reversion. Restoration in MPLS-TE FRR network relies on the control plane signalling. As I interpret Section 2. Document Scope, the document concentrates on defining benchmarking test cases to measure performance of facility backup FRR as defined in RFC 4090. I think that Restoration and Reversion are out of that scope. If that is the case, then statement "It is important to include Restoration and Reversion as a step in each test case to measure the amount of packet loss, out of order packets, or duplicate packets that occurs in this process" is confusing.
 *
Section 6.1. I find most test cases very confusing. As stated in the Section 2, the scope of this document is on facility backup method of MPLS-TE FRR. Thus backup tunnel is bypass backup tunnel that is encapsulating protected LSP(s).
 *
Section 6.1 and 6.2 I don't see enough rational for so many test cases. IMO, PLR performance in protection switchover is not affected by topology of a bypass tunnel. And I'm concerned that failure detection has not been separated from protection switchover itself and will make benchmark testing results, e.g. larger BFD interval being used larger variation in detection time will be in the tests. Hence, after a switchover protected LSP would have an extra label on its stack.
 *
Section 7.1 Benchmarking MPLS Performance seems outside of scope for this document. Can it be spawn into a separate document and then referenced?

    Regards,
        Greg

________________________________
From: Jay Karthik (jakarthi) [mailto:[e-mail]]
Sent: Friday, July 13, 2012 6:55 PM
To: Gregory Mirsky
Cc: [e-mail]; [e-mail]
Subject: Re: [bmwg] Last Call: <draft-ietf-bmwg-protection-meth-09.txt> (Methodology for benchmarking MPLS protection mechanisms) to Informational RFC

Greg,

First of all, apologies in getting back to you this late. Even though we incorporated your comments in the most recent version (-10, published on 5/29), a formal response to your comments should have been made sooner.

Please see inline marked (JK) for the specific response to your comments.

Thanks for your thorough review.

Best,
Jay

I'm concerned with the very title of the document, Methodology for benchmarking MPLS protection mechanisms, even though only MPLS-TE FRR being considered while LSP end-to-end and segment protection implicitly being kept out of the scope.

JK: Modified the title to be more explicit in the most recent version posted.

I've found several textual inaccuracies related to both MPLS and BFD to make me wonder if the document was liasioned to MPLS WG.
List of acronyms is missing - PLR, OIR, LOS, AIS, etc.

JK: PLR is defined in Term RFC 6414 that we are referencing. OIR Is mentioned in Appendix B. Other acronyms such as AIS and LOS are added in rev 10.

Introduction. I think that for "planned link or node failure" MBB is more efficient and useful than FRR. But MBB is not being mentioned in the document.

JK: We have used the term Revision which implies MBB

Introduction. "A correlated failure is the simultaneous occurrence of two or more failures." Personally, as correlated events I consider events with cause-effect relationship.
Introduction. Path restoration after FRR discussion does not appear logical, in the scope of benchmarking document.

JK: We have modified section 5.6

Document Scope. "Protection from Bi-directional Forwarding Detection (BFD) is outside the scope of this document." I frankly couldn't decode this sentense.

JK: Addressed in rev 10

Document Scope. Several references to Path Restoration as Re-optimization - doubt that it belongs in the document at all.

JK: Section 5.6 adds more color to this discussion

Sections 6.1.1 through 6.2.4 - what is relevance of listing numbers of labels in the stack?

JK: Convergence, performance may be dependent on the label stack depth.

Peerformance of control plane should be outside of the scope of benchmarking as it is end-to-end metrics, not explicitly of DUT.

JK: Scope modified