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

[Al Morton <[e-mail]>]

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
at least 16 flows spread over the routing table (more flows is 
better). Otherwise, the impact of a prefix-dependency in the implementation
of a particular protection technology could be missed.
However, the test designer must be aware of the number of
packets per second sent to each prefix, as this establishes
sampling of the path and the time resolution for measurement
of Failover time on a per-flow basis.


in 3.6:
The following Methods MAY ... <same as above>

Section 3.6.1, 3.6.2, 3.6.3 units are in seconds, but
Section 3.5.3. and 3.5.4 units are in milliseconds.
These should match.

----------------------
Comments on meth-05:
----------------------

Following the changes in the term draft Introduction,
I suggest to add the following at the end of the meth Introduction:

...
MPLS Fast Re-Route (MPLS-FRR)
allows for the possibility that the Label Switched Paths can
be re-optimized in the minutes following Failover. IP Traffic
would be re-routed according to the preferred path for the post-failure
topology. Thus, MPLS-FRR includes an additional step to the
General model:

    1. Failover Event - Primary Path (Working Path) fails
    2. Failure Detection-  Failover Event is detected
    3. a. Failover - Working Path switched to Backup path
    3. b. Re-Optimization of Working Path (possible change from Backup Path)
    4. Restoration - Primary Path recovers from a Failover Event
    5. Reversion (optional) - Working Path returns to Primary Path

----------------------------------------------------------------------
Is there any limitation that should be added to the Scope
(with this more complete view of MPLS-FRR in mind)?
In other words, are the methodology and benchmarks robust-enough to
measure the impact of *both* Failover and Re-optimization?

Attempting to answer these questions myself, it appears that all the
3 methods are currently worded to emphasize measurement of the initial
Failover event.

So, this should be made clear in the Scope section (2):
NEW
As described above, MPLS-FRR may include a Re-optimization of the
Working Path, with possible packet transfer impairments.
Characterization of Re-optimization is beyond the scope of this memo.

-----------------------------------------------------------------------

Section 5.7
Suggest replacing some text with the following:
NEW
At least 16 flows should be used, and more if possible (3 is not sufficient).
Prefix-dependency behaviors are key in IP and tests with route-specific
flows spread across the routing table will reveal this dependency.


Section 7.
At present, all of the three Failover Time methods are equally
preferred, but it appears that at least a recommendation would be
appropriate.
Both the Time-based Loss Method and the Packet Loss
based method will have difficulty assessing any
protection switch that is successfully conducted in a
make-before-break fashion. The Time-stamp based method
would be able to detect Reversion impairments beyond loss, thus it
should be RECOMMENDED method in section 7.

Also in section 7:
There should be a reference to Section 4 of RFC 2544 to capture
important considerations for the results, such are repeatability:
NEW
The considerations of Section 4 of [RFC2544] are applicable
when evaluating the results obtained using these methodologies as well.

Section 7.1:
This seems like an appropriate place to refer to
draft-ietf-bmwg-mpls-forwarding-meth- ...
and this passage in particular, from section 4:
    ... Throughput may vary depending on the number of ports used,
    and other factors. The number of ports (p) used SHOULD be reported.
    Please see Test Setup in Section 6, and recommended to follow Fig 1
    from S6 of RFC2544.

Section 7.5: references to "6.5 to 6.8" are no longer valid
(there are no such sections in the meth draft).

Section 8:
There is a note at the end which is difficult to interpret:
OLD
    Note: If the primary is configured to be dynamic, and if the primary
    is to reroute, make before break should occur from the backup that
    is in use to a new alternate primary. If there is any packet loss
    seen, it should be added to failover time.
Question:
Is this Note referring to "Re-optimization" as described above?
The intent needs to be made more clear in this text.
Also, if we limit the Scope to Failover Time, then this "reroute"
referred to above would not be in scope.
BTW, I don't think it is appropriate to simply add the loss
observed during Failover with any loss during reroute/re-optimization.