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

From: Bill Cerveny <[email-masked]>
Date: Sun, 8 Jun 2008 20:16:05 -0400

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

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 …”

Introduction:

(General comment … is this too much detail for an introduction??)

“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)

(Side observation: which “layer” standard are you referring to?  Is  
this standard listed in references?)

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

New paragraph?: “The purpose of this document …”

New paragraph, changed text: “The sequence of events is:”

“The Protection MAY…”??  Do you mean “Protection MAY …” or “The  
protection system MAY…”

Terminology Section

Path:
Why is L12 the first link and not something like L1?

“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].”

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

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

Disjoint Path:
S/Discussions/Discussion/  :-)

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

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.

Redundant Node Protection:

Are VRRP and HA defined or referenced?  Expand on acronym on first  
usage.

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)

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

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?

(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

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

_______________________________________________
bmwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bmwg

---

From: Serge Ayoun <[email-masked]>
Date: Mon, 16 Jun 2008 13:06:08 +0100

Hi guys,

My name is Serge and  I am from Microsoft and have interest in performance and utm. I would like to participate and possibly have a look at your drafts. How can I find it if possible?

Thanks,

Serge A.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill Cerveny
Sent: Monday, June 09, 2008 3:16 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Samir Vapiwala; Rajiv Papneja
Subject: [bmwg] Comments on draft-ietf-bmwg-protection-term-04.txt

Bill Cerveny
Overall, Bill's over-capitalization rant applies ;-) In general, there

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

Introduction:

(General comment ... is this too much detail for an introduction??)

"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)

(Side observation: which "layer" standard are you referring to?  Is
this standard listed in references?)

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

New paragraph?: "The purpose of this document ..."

New paragraph, changed text: "The sequence of events is:"

"The Protection MAY..."??  Do you mean "Protection MAY ..." or "The
protection system MAY..."

Terminology Section

Path:

"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]."

Backup Path:

Unclear -  "A new Path computed after the Failover Event is simply
Convergence [7]  to a new Primary Path. "

Disjoint Path:

Point of Local Repair:

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.

Protected Interface:

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?

"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

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