Re: [bmwg] Comments on draft-ietf-bmwg-protection-term-04.txt

[Rajiv Papneja <rpapneja at isocore.com>]

Title: Re: [bmwg] Comments on draft-ietf-bmwg-protection-term-04.txt

Thanks for further clarifications, we will try to address these in the next versions. /R

On 7/16/08 10:28 PM, "Bill Cerveny" <bmwg at wjcerveny.com> wrote:Bill Cerveny

Clarifications below ...

On Jul 16, 2008, at 11:33 AM, Rajiv Papneja wrote:

[text skipped]

>
> Abstract:
> “The performance benchmarks are measured at the IP-Layer, so avoid  
> dependence on specific sub-IP protection mechanisms.” -- Consider  
> rewording “… IP-Layer, so avoid” to something like “… IP-layer,  
> avoiding…” or “… IP-layer and avoid …”

Historically, this term was used to encompass other protection mechanisms stated in the abstract and we were asked to stick with sub-IP term at least in the terminology document. If the group would like to change it for clarity, we would be happy to reword as suggested – Al, your comment is appreciated here!

I concur with what Al said in a separate e-mail :-)

[text skipped]

 > Link, Node and Path Protection definitions: To me, at least as they  
 > appear, “protection” appears to be a “condition” and not something  
 > physical such as a path (although they may describe the impact of a  
 > path).  These definitions need to be defined as something like  
 > “condition where …” or “state where …”. You may be able to convince me  
 > otherwise, but these definitions look initially awkward to me.
 
Are you suggesting that these definitions are not required or  need to be re-defined. The idea here was to define the protection against different types of failures - link, node and path and how these protections mechanisms are applied.
 >

What I am suggesting is that perhaps these need to be redefined as something describing a condition and not as something physical, such as a link. In my opinion, the various types of "protection" refer to a condition whereas a link, node or path are protected and are not the same as the link, path or node.

For example, if the way it is currently written is taken literally (like I read it), link protection is a backup path, instead of a condition where one has a backup path.

[text skipped]

> Packet Loss Based Method:
 >
 > “Offered load rate” not defined, as far as I can tell.  Additionally,  
 > the offered load rate measurement units aren’t defined (which helps in  
 > understanding  equation #3).  Finally, the line “Units are …” appears  
 > to state units are seconds, but “measurement units” are stated as  
 > milliseconds
 
 The final calculation results will be presented in millisecond. I do not believe any tester offers live measurements in milliseconds range. One point of clarification can be made is to change the measurement units to seconds, however leave the calculated results at millisecond range. Would you agreed to this?
 >

Having "offered load rate" defined would help me understand this better. I'm having difficulty visualizing the equation and how the units work out.  Perhaps seeing an equation "in action" would help me understand this.

Regards,

Bill

---

_______________________________________________
bmwg mailing list
bmwg at ietf.org
https://www.ietf.org/mailman/listinfo/bmwg

_______________________________________________
bmwg mailing list
bmwg at ietf.org
https://www.ietf.org/mailman/listinfo/bmwg