Skip to main content

Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection
draft-ietf-bmwg-protection-meth-14

Yes

(Ron Bonica)

No Objection

(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Ralph Droms)
(Robert Sparks)
(Sean Turner)
(Wesley Eddy)

Note: This ballot was opened for revision 09 and is now closed.

Ron Bonica Former IESG member
Yes
Yes (for -09) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2012-11-13 for -12) Unknown
Thanks to the authors for addressing most (but not all) of the issues
I raised in my review last time this document came to the IESG.

Although I have a number of comments and concerns about this document
I will not stand in the way.

---

Reading the earlier part of the document, I got the impression that the
mechanism of failure detection and reporting was out of scope. 

However, looking at later sections (such as Section 5.9) I see that you
propose to measure based on packet loss or timestamped packets over the
failure. Both of these measures are dependent on the methods of 
detection and reporting. 

So I don't understand how the test cases work for anything other than
local errors. And even in these cases, it seems you are more likely
testing and recording fault report times in the DUT than measuring the
actual failover times.

---

Section 7.1.1 etc.

      3.   Verify primary and backup LSPs are up and that primary is
           protected.

      4.   Verify Fast Reroute protection is enabled and ready.

I don't find any description of how these items are verified.

---

Abstract

   This draft describes the methodology for benchmarking MPLS Protection
   mechanisms for link and node protection as defined in [RFC 4090].

It would be nice if this was alligned with the document title by 
specifically stating "MPLS Fast Reroute Protection"

===

The following are nits that you may want to sort out before passing the
document to the RFC Editor...

---

I think Jean Louis needs to be correclty abreviated on the front page
viz. JL. Le Roux.

---

It would be good to replace "draft" with "document" so that the text is
consistent when published as an RFC

---

Citations should not be pesent in the Abstract.

---

The Abstract suggests that the document considers "all other factors".
This seems a little unlikely :-)

---

Section 3

This section could usefully include a pointer to Appendix B.

---

Section 5

Slightly odd that the 7 points listed don't match the sub-sections of
this section.
Barry Leiba Former IESG member
No Objection
No Objection (2012-10-30 for -11) Unknown
Non-blocking comments only.  No need to respond, though I'll be happy to chat with you about them if you like.

The datatracker and shepherd writeup say this is targeted as Informational, but the document says it's Standards Track.  Which is it?

The Introduction says, "For any conflicting content, this document supersedes [RFC 6414]."  Doesn't that mean that this should Update 6414?

The 2119 boilerplate (Section 3) adds this:

   RFC 2119 defines the use of these key words to help make the
   intent of standards track documents as clear as possible.  While this
   document uses these keywords, this document is not a standards track
   document.

That seems *really* odd: you're saying that these words aren't meant for the purpose that 2119 uses them for, but you don't say what purpose they *are* used for.  If you feel you need to explain this, you should focus on explaining, not disclaiming.  Something more like this (word it as you see appropriate):

   While RFC 2119 defines the use of these key words primarily for
   Standards Track documents, this Informational document uses them
   to [...insert explanation here...].

-- Figure 1 --
The text should perhaps say what all the "Rn" boxes are, and make it clear that they are not part of the Tester -- only the TG and TA are.  It might also expand "DUT" on first use (it's not expanded until Section 5.3).
Benoît Claise Former IESG member
No Objection
No Objection (2012-11-15 for -13) Unknown
Minor points.

   Within the context of MPLS
   protection mechanisms, failures that arise due to Shared Risk Link
   Groups (SRLG) [RFC 4090] can be considered as correlated failures.

Isn't the reference rfc4202? RFC4090 doesn't even spell the acronym

Spell out the acronym or give references in (surely the RFC editor would note that as well)

   "Within the context of MPLS 
   protection mechanisms, failures that arise due to Shared Risk Link
   Groups (SRLG) [RFC 4090] can be considered as correlated failures."
Brian Haberman Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2012-11-14 for -13) Unknown
Aside from Barry's comment about the 2119 template (which I agree is poorly worded and should be changed), I don't really understand why any of the 2119 language in this document is useful. For example, when you say, "The tester MUST record the number of lost, duplicate, and out-of-order packets" in section 4, I am left to ask, "Why MUST the tester do that?" It's not explained, and I suspect all it means is, "The tester has to record those things if it wants to know those things." I'm pretty sure that all of the 2119 language could be removed from the document without changing its utility.
Ralph Droms Former IESG member
No Objection
No Objection (for -13) Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (2012-11-15 for -13) Unknown
  Thanks for addressing the issues raised in the Gen-ART Review by
  Joel Halpern on 9-Mar-2012.  Joel did a second review on 12-Nov-2012.
  Please consider these non-blocking comments from the second review.

  In section 5.1 "some" failure events are listed. It is unclear
  whether this list is the ones to be tested for, or just "some"
  events.  I think it is intended to be comprehensive, so why "some".

  I presume that the use of the term Layer2 VC in section 6 is
  intended to refer to a pt-to-pt layer2 VPN component.  Is there an
  existing document where that term is used that way?  Could it be
  referenced?  For that matter, since the number of labels is the same
  in the Layer3 cases and the Layer2 cases, could the Layer2 cases be
  omitted without loss of generality?
Sean Turner Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2012-11-13 for -12) Unknown
- s2, saying you cover "all possible failure scenarios" seems
ambitious - is it really true? How about buggy code?  I'd
suggest s/all possible/a set of interesting/

- s4, it'd be good to say what the lines in Figure 1 represent,
e.g. physical connections or routes or tunnels or whatever,
that may be well known for MPLS developers but perhaps less so
for testers?

- s4, probably a dumb question (sorry;-) but is the definition
of the number of re-ordered packets clear?  e.g. does the
sequence 1,4,3,2,5,6 have two or three re-ordered packets?
What about 1,4,4,3,2,5,6? Later sections also talk about
"Out-of-order" packets, is that meant to be the same thing?
Better to use one term only if so.

- s5.7, last para: fwiw, this seems a bit open-ended for a
benchmark to my uneducated eye. If it makes no difference to
the outcome, be good to say that maybe.
Stewart Bryant Former IESG member
(was Discuss) No Objection
No Objection (2012-12-14) Unknown
I am updating my comment to clarify it. It is a point that was somewhat obliquely a Discuss last time round, but I did not properly explain the point. I would raise this as a discuss, but I do not think the review rules permit this.

The text that says : "MPLS FRR protection  mechanisms are generally deployed in a network infrastructure where MPLS is used for provisioning of point-to-point traffic engineered tunnels (tunnel)." and the absence of discussion on the topic elsewhere suggests that you have not considered an important (arguably the most important) deployment case.

In an otherwise LDP network a one hop RSVP-TE tunnel is deployed across a link. This tunnel is normally PHPed, but is protected, so normally no label is pushed on the main tunnel. This case will impact the LSR configuration compared to the pure RSVP-TE case and will impact the restoration, because you have three routing process that interact - the IGP, LDP and RSVP-TE. You do the same think for node protection, but cannot of course PHP.

You might want to rule the case out of scope, although this will reduce the utility of the testing, or you could consider it, but you really ought to provide evidence that you have thought about the implications and validity of your tests in this network environment.
Wesley Eddy Former IESG member
No Objection
No Objection (for -12) Unknown