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

["Kris Michielsen" <[e-mail]>]

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,
or a single Primary Path? Is it to a single destination reachable over a Primary Path or all destinations reachable over a Primary
Path?

* The definition of Failover Packet Loss (3.5.1) doesn't need to point out start and end of traffic loss, how the start end end are
defined doesn't seem right anyway (not for multiple streams anyway). I think it is important to take the time between Failover Event
and first observed packet loss as well in case the failure does not cause instantaneous packet loss. Shouldn't there be a "Sustained
Failover Validation Time", i.e. a period in which there is no aditional packet loss before declaring Failover as completed?

* What are the definitions of the "Time(xxx)" terms used in 3.6.1?

* It needs to be pointed out that the PLBM gives the _average_ loss over the measured destinations.


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.

* 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.

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

* 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?

* 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

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

* 8 "Packet Size" is it layer2, layer3 ? "Forwarding rate" should be "Offered Load"?
* 8 BGP routes, is this only applicable for VPN PEs?
* 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.
* 8, p 24, bullet 1. s/Rate/Loss/
* 8 The note at the end of the section should be more elaborated on (and may have implications throughout the document).

Thanks,
Peter and Kris


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Al Morton
> Sent: 02 July 2009 20:25
> To: [e-mail]
> Subject: [bmwg] WGLC: draft-ietf-bmwg-protection term-06 and meth-05
> 
> BMWG,
> 
> 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/
> 
> The Last Call with end on July 31, 2009.
> 
> We've been discussing this topic in BMWG almost as long as I 
> been chairman.  Two original authors of the terms had to 
> leave us, but others stepped-up and have brought this work to 
> a good state of completeness.  In fact, I've recently shared 
> our terms draft with some colleagues in the MEF who were 
> quite impressed.
> 
> Please weigh-in on whether or not these Internet-Drafts 
> should be given to the Area Directors and IESG for 
> consideration and publication as an Informational RFCs.  Send 
> your comments to this list or [e-mail].
> 
> Al
> bmwg chair
> 
> _______________________________________________
> bmwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bmwg
>