[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

First of all please accept our apologies for responding to your comments so late and we really appreciate your review of the Protection terminology document.  We are  glad that you have reviewed the document thoroughly and recommended several changes. Please see below for our response to your comments/edits. Regards, Rajiv

On 6/8/08 8:16 PM, "Bill Cerveny" <bmwg at wjcerveny.com> wrote:Bill Cerveny

> My comments on draft-ietf-bmwg-protection-term-04.txt are below. I  
> hope you find them useful and please feel free to contact me if you  
> have any questions or need clarification.
>
> Bill Cerveny
> --------------------------------------
> Overall, Bill’s over-capitalization rant applies ;-) In general, there  
> is way too much capitalization. Terms such as "working path",  
> "protection," "backup path" or "path" should not be capitalized. In  
> particular, look at IEEE reference on acronyms:
> http://www.computer.org/portal/pages/ieeecs/publications/author/style/acronyms
> .html

We will review the document for these inaccuracies, and the next version should take care of these.

>
> 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!
>
> Introduction:
>
> (General comment … is this too much detail for an introduction??)

I agree with you that it might wear out the reader before getting in to the detail of the document. We will try to address this or may be consider splitting the text.

>
> “Fast convergence times are critical to maintain reliable network  
> connectivity and performance.” — Consider changing to something like  
> “Fast convergence times are critical for maintaining reliable network  
> connectivity and performance.” (Optional change)
>
> “Technologies that function at sub-IP layers can be enabled to provide  
> further protection of IP  traffic by providing the failure recovery at  
> the sub-IP layers so that the outage is not observed at the IP-layer.”  
> — Reword to something like: “Technologies that provide failure  
> recovery at the sub-IP layers can further protect IP traffic such that  
> an outage is not observed at the IP layer.” (Not perfect, but better,  
> in my opinion)

Agreed, we accept the change.
>
> (Side observation: which “layer” standard are you referring to?  Is  
> this standard listed in references?)

We can try to remove the ambiguity here, we are referring to the network layer, but I agree with you that it should be clarified.
>
> s/Benchmarking terminology have been defined/Benchmarking terminology  
> has been defined/
>
> “New terminology and methodologies specific to benchmarking sub-IP  
> layer protection mechanisms are required.  This will enable different  
> implementations of the same protection mechanisms to be benchmarked  
> and evaluated.”  — Perhaps change to “New terminology and  
> methodologies specific to benchmarking sub-IP layer protection  
> mechanisms will enable different implementations of the same  
> protection mechanisms to be benchmarked and evaluated.”

Reads better, we will change it.
>
> New paragraph?: “The purpose of this document …”

The comment above to reduce the length of introduction will address this as well.
>
> New paragraph, changed text: “The sequence of events is:”
>
> “The Protection MAY…”??  Do you mean “Protection MAY …” or “The  
> protection system MAY…”

It should be “protection system MAY”
>
> Terminology Section
>
> Path:
> Why is L12 the first link and not something like L1?

L12 represents the path in the direction 1 to 2. The links between R1-R2 in the direction from R1 to R2 is L12.
>
> “The path is defined in the sub-IP layer in this document, unlike  an  
> IP path in RFC 2026 [1].” Perhaps change to “A path as defined in this  
> document refers to a sub-IP layer path, unlike an IP path in RFC 2026  
> [1].”

Reads better, will change it.

>
> Backup Path:
> s/The Backup Path SHALL be the Working Path/The backup path SHALL  
> become the working path/

I would go with “become”

>
> Unclear —  “A new Path computed after the Failover Event is simply  
> Convergence [7]  to a new Primary Path. “

It is dependent on the IGP convergence times. We will try to clarify.
>
> Disjoint Path:
> S/Discussions/Discussion/  :-)

Fixed!
>
> Point of Local Repair:
> s/Based on the functionality of the PLR, its role is defined based on  
> the type of method used./The role of the PLR is based on the type of  
> method used./

Accepted.
>
> s/In the case the facility backup method is used/Where the facility  
> backup method is used/
>
> 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.
>
> Redundant Node Protection:
>
> Are VRRP and HA defined or referenced?  Expand on acronym on first  
> usage.

Should be defined. There are just introduced in the abstract, but not explicitly defined or referred.

>
> Protected Interface:
>
> s/A Protected Interface is an interface protected by a Protection  
> Switching Systems/A protected interface is an interface protected by a  
> protection switching system/ (protection system system should be  
> singular)

Accept
>
> Non-Protection System Node:
> S/A node that is not capable of participating in a Protection  
> Switching System, however it MAY exist along the Primary Path or  
> Backup Path./A node that is not capable of participating in a  
> protection switching system. However, it MAY exist along the primary  
> path or backup path./

Accept
>
> Headend Node:
>
> Discussion begins and ends by discussing “headend” node, but in  
> between, discussion is regarding “failover” nodes. What is  
> relationship between headend and failover nodes?

Headend node is defined as any node which is capable of failing over, and is the ingress of the backup path. Hence the reference to the failover is made. We can look at the discussion one more time to make it simple.

>
> (Side comment: Acronym PLR is used infrequently enough that I have to  
> think back to what the acronym refers to)
>
> 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?
>
> Time Based Method:
>
> Simplify, shorten or break-up:
>   “The purpose of this method is to quantify the duration of failure  
> or reversion on a time scale with granularity of milliseconds based on  
> the observation of unimpaired packets,  using Equation 2 with the  
> difference being that the time values are obtained from the timestamp  
> in the packet payload rather than from the Tester.”

Will consider
>
>
>
>
>
>
>
> _______________________________________________
> 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