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

From: Rajiv Papneja <[email-masked]>
Date: Wed, 16 Jul 2008 11:33:19 -0400

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" <[email-masked]> 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
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/bmwg

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

---

From: Al Morton <[email-masked]>
Date: Wed, 16 Jul 2008 14:46:39 -0400

At 11:33 AM 7/16/2008, Rajiv Papneja wrote:

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!

Bill is not suggesting changing the term "sub-IP", if I
understand

his comment.  He's just editing the text around the term
"IP-layer"

Al

---

From: Bill Cerveny <[email-masked]>
Date: Wed, 16 Jul 2008 22:28:03 -0400

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,
> 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]

>> > appear, “protection” appears to be a “condition” and not something
>> > “condition where …” or “state where …”. You may be able to  
>> convince 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]

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

---

From: Rajiv Papneja <[email-masked]>
Date: Wed, 16 Jul 2008 22:43:26 -0400

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

On 7/16/08 10:28 PM, "Bill Cerveny" <[email-masked]> wrote:Bill Cerveny

>> 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!
> 
>>> 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]
> 
> 
>>> 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
> 
>