Subject: Re: [bmwg] I-D ACTION:draft-ietf-bmwg-protection-term-03.txt

From: "Tom Alexander" <[email-masked]>
Date: Wed, 5 Mar 2008 21:03:11 -0800

Scott et. al.,

I read the above-referenced terminology document on protection benchmarking.
Overall it seems pretty complete. I have a number of comments on the
document, enclosed in the attached text file.

Looking forward to the discussion in Philly.

Best regards,

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

---

From: Al Morton <[email-masked]>
Date: Sat, 08 Mar 2008 10:03:49 -0500

>document, enclosed in the attached text file.

Let me add a few comments (as a participant).
Al

Tom Identified one set of requirements for test devices
in the Introduction, and suggested that the text should move
to the Methodology draft.  I agree with this, and suggest
to take it a step further.  Let's move all the requirements
and critical material out of the Intro:

The Introductory text really ends at the 5 stage sequence of
events.

Embedded in the Introduction is the Purpose of the memo.
The Purpose and Scope are usually a separate section in standards,
consistent with their importance. I suggest
to move the purpose and add several sentences of "scope" in a
a new section.

Beyond that is a General Model of protection switching systems,
and some requirements for systems that would be covered
under this terminology and framework. For example:

>     ...  Figures 1
>    through 5 show fundamental models that MAY be used in
>    benchmarking Sub-IP Protection mechanisms.  Sub-IP Protection
>    mechanisms MUST use a Protection Switching System that consists
>    of a minimum of two Protection-Switching Nodes, an Ingress Node
>    known as the Headend Node and an Egress Node known as the Merge
>    Node.  The protection MAY be provided with either a Primary
>    Path and Backup Path, as shown in Figures 1 through 4, or a
>    Primary Node and Standby Node, as shown in Figure 5.

So, I suggest moving all the Figures and supporting text to a new
section, "General Model of Protection Switching Systems".
The Scope section can refer to this section for more detail and
requirements.

>Looking forward to the discussion in Philly.

Me too.  Probably some more comments will follow...

---

From: Al Morton <[email-masked]>
Date: Sun, 09 Mar 2008 09:43:47 -0400

Scott,

In summary, you're saying that the BMWG understands the
scope of this work item, and I agree. Your slide contains
the key points, but it has to appear in the memo to matter!
(This is partly why we need the Standard Security Paragraphs:
the charter of our WG also determines the scope of our RFCs,
but it has to appear in the text to be clear to any reader.)

When I said you needed a Scope section, this is exactly
the sort of discussion that would be resolved easily
(or avoid in the first place) by having a good scope.
And to clarify further, all my comments move text around
within the terminology memo.

You're right that we can't move a requirement out of the
terminology draft without loosing applicability across all
the methodologies.  But this is still a reasonable comment.
The Intro is not a typical place for requirements.
So, a simple resolution of your concern and Tom's
is to put the requirement in the "General Model of Protection
Switching Systems" section (with the figures and other
requirements I identified).

hope this helps,
Al

At 05:18 PM 3/8/2008, Poretsky, Scott wrote:
>Hi Tom and Al,
>
>The comments are much appreciated and the reviews are most appreciated.
>It is important to keep in mind the structure of this work item in the
>BMWG.  As a working group we decided that the Sub-IP Protection
>Switching work item would be a single Terminology document with multiple
>methodology documents.  The Terminology has been written with this scope
>in mind.  The attached slide has been included in the work item
>presentations at IETF meetings.
>
>The information in the terminology document Introduction is important to
>remain in the Terminology so that it is used across all methodology
>documents.  If it is moved to the MPLS Protection methodology document
>then there is good chance that this information will be forgotten (or
>avoided) in the other methodology documents to follow.  In fact, some of
>that information is not applicable to MPLS Protection at all.  Perhaps
>we should consider creating a separate Considerations document as has
>been done for other work items and moving this information to it?  Also,
>it is the authors' expectation that this understanding of the work item
>scope will obviate some of the other comments that were provided.
>
>Thanks,
>Scott
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Al Morton
>Sent: Saturday, March 08, 2008 10:04 AM
>To: Tom Alexander; [email-masked]
>Subject: Re: [bmwg] I-D ACTION:draft-ietf-bmwg-protection-term-03.txt
>

---

From: "Poretsky, Scott" <[email-masked]>
Date: Sat, 8 Mar 2008 16:18:52 -0500

Hi Tom and Al,

Thanks,
Scott

---

From: "Poretsky, Scott" <[email-masked]>
Date: Sat, 8 Mar 2008 17:03:14 -0500

Hi Tom,

Thanks for the thorough review.  The comments are very much appreciated.
Please see responses below in-line.

Scott

--------------------------
	Comments on "Benchmarking Terminology for Protection
Performance" 
			<draft-ietf-bmwg-protection-term-04.txt > 

On Page 3:

1. Resilient Packet Ring (RPR), or IEEE Std 802.17, has little to do
with
Ethernet (IEEE Std 802.3), apart from the fact that the RPR protocol has
hijacked the Ethernet physical layer. RPR is a completely separate MAC
protocol. The Ethernet committee defines separate protection mechanisms
in
the 802.3 standard.

SP> The "for ethernet" will be removed.

On Page 4:

2. "The tester MUST record the IP packet sequence numbers, departure
time,
and arrival time so that the metrics of Failover Time, Additive Latency,
Packet Reordering, Duplicate Packets, and Reversion Time can be
measured."
This is a specification of the tester, not a definition of a term. It
belongs in the corresponding methodology document.

SP>  I agree with including this in the methodology.  It also is
important
to include this sentence in the Terminology as part of the explanation
of 
Figure 1. Otherwise the explanation of Figure 1 would be incomplete.

3. Further to item 2 above. I assume that by "IP packet sequence number"
the authors are referring to the IP Identification field, because there
is no sequence number in the IP header. It is not clear why there is an
unnecessary specification of implementation with regards to the tester.
For
example, if the tester elects to generate IP datagrams containing
proprietary signatures for tracking, then there is no need to record IP
header information, departure time, and arrival time in the manner
described.

Further, using the IP Identification field is not necessarily the best
way
of determining failover time or latency. Apart from the fact that there
is
no requirement on the IP Identification field to be sequential, the
width of
the field is only 16 bits (i.e., 65,536 packets before it wraps). In the
case of a 10 Gb/s Ethernet link carrying 64-byte MAC frames, a
protection
switch time of 50 msec, the IP Identification field will wrap >11 times
before the failover completes. It will be impossible to determine the
actual
failover time or latency. Packet identification fields that are much
wider
than 16 bits are needed.

SP>  It is not the ID field.  The ID field is used to distinguish packet
fragments, which is outside the scope of this work item.  Typically,
testers
include the IP Packet Sequence Number in the payload with a timestamp.

On Page 8:

4. In Section 3.1.3, a Primary Path is defined as: "The preferred path
for
forwarding traffic between two or more nodes." This implies some kind of
subjective preference or quality imposed on the paths, 
SP> Not at all.  As is the case for operational links, the test case
must 
have a 100% determinstic process to select the Primary Path.  This may
be 
set by policy or calculation.

which may not
exist in practice. 
SP>  Could you provide an example?

For example, in the case of two identically configured
redundant links, one link may be arbitrarily selected to serve as the
default path and the other link as the backup; but there is no
preference
imposed. It would be better to word the definition as: "The default or
initial path for forwarding traffic between two or more nodes."

SP> If one of two redundant links is the Default, then there is 
some preference applied to select that Default.   This is the case in
production networks as well.  Operations requires path selection to be
100% 
deterministic.

On Page 9:

5. In Section 3.1.5, the Backup Path is defined as: "A path that exists
to
carry data traffic only if a Failover Event occurs on a Primary Path."
This,
however, excludes RPR protection switching. In the case of RPR, the
backup
path may also be used to carry data (often, lower-priority data that can
safely be dropped if a protection event occurs) during normal operation.
When a protection event occurs, the traffic on the Primary Path is
rerouted on to the Backup Path, thereby adding to the load on the Backup
Path. If the capacity of the Backup Path is exceeded, the RPR QoS
mechanisms
are used to prioritize and manage the traffic such that the QoS
guarantees
are maintained.

It is therefore better to word the definition as: "A path that, in the
event of a failover, carries data traffic that was previously carried on
a
Primary Path".

SP>  The suggested rewording misses the important piece of the
definition
that traffic is carried on the Backup Path only upon occurrence of a
Failover 
Event.

On Page 10:

6. The definitions in 3.1.7 and 3.1.5 are apparently in conflict. A
Dynamic
Backup Path cannot be a Backup Path because it is established after the
Failover Event.

If the definitions are in fact not in conflict, then the document needs
to
clearly distinguish between "established", "computed", and "created". It
is
not clear what the authors mean by each term, but they seem to be used
to
distinguish various types of paths. (If there is no difference, then
pick
one term and use it consistently.)

SP> There are two types of Backup Paths - Standby and Dynamic.  The 
authors believe that the definitions as written read to be consistent.

    3.1.5.  Backup Path 

       Definition: 
       A path that exists to carry data traffic only if a Failover  
       Event occurs on a Primary Path. 

     3.1.6.  Standby Backup Path   

        Definition: 
        A Backup Path that is established prior to a Failover Event 
        to protect a Primary Path.   

     3.1.7. Dynamic Backup Path   

        Definition: 
        A Backup Path that is established upon occurrence of a  
        Failover Event.   

7. The terms "Protected Primary Path", "Standby Backup Path", "Dynamic
Backup Path", "Disjoint Path", etc. are not used in the methodology
document. Further, they seem to have little to do with the purpose of
the
document, which is to define terms relating to the benchmarking of
protection performance (not about how the DUT implements various
protection
schemes). Why are these terms being defined?

SP>  The scope of this work item requires definition of these protection
terms.  
It is not required that the terms be used in the Methodology for MPLS
Protection.

On Page 13:

8. In section 3.2.5, the document says: "Local Link Protection MUST be
provided as a Backup Path between two nodes along the Primary Path
without
the use of a Backup Node." This statement is a requirement placed on the
construction of the DUT. It has little to do with protection performance
measurement, and nothing at all to do with terminology. It should be
moved
to the methodology document, or, better still, removed entirely (or at
least
restated as a non-normative statement).

SP>  this is applicable to SONET APS, which was the original tachnology
application
for this work item.

On Page 15:

9. In section 3.3.2: "The occurrence of a planned or unplanned action in
the
network that results in a change in the Path that data traffic
traverses."
An operator may use a craft interface to shut down a link and manually
reroute traffic over another link, without any concept of Primary or
Backup paths. It is not clear whether such an event is considered to a
failover event. Do the authors consider a failover event to be an
automatic
action (even though it may be induced manually), or are manual actions
covered as well? It is difficult to make repeatable performance
measurements
on manual actions.

SP> The test cases and procedures are specific to the Methodology
documents.  
The Operators are 100% aware of primary/backup paths (Sub-IP) and
preferred/next-best interfaces (IP) when performing manual operations on
management interfaces.

On Page 17:

10. In section 3.3.4: "Failover is complete when Packet Loss [7],
Out-of-order Packets [4], and Duplicate Packets [4] are no longer
observed."
This presumes that packet loss is not normally observed in the DUT, due
to
either momentary or continuous overload. Some specification of the
traffic
conditions should probably be added to this definition.

SP>  This point is not applicable to the definition of 3.3.4 Failover.
It is
necessary to include this point in the Methodologies.

On Page 19:

11. The definition of Headend Node in section 3.4.3 conflicts with the
diagrams in section 4 of the methodology document. The methodology
document
shows the head-end node as being physically and logically separate from
the
PLR. Further, the diagrams represent the head-end node as always being
the
start of the path (the intermediate nodes being labeled as "MID" or
"PLR").
However, the definition says that a head-end node may occur anywhere
along
the primary path, and is always a PLR. Please clarify one or the other.

SP>  As stated in the Terminology text, "Figure 4, provides Sub-IP
Protection 
of a link between two nodes, without a Backup Node.  An example of such
a 
Sub-IP Protection mechanism is SONET APS."  It is not applicable to the 
MPLS Protection Methodology document.

On Page 21:

12. In section 3.4.7: why do we care whether the Standby Node is
geographically dispersed from the primary node (or not), and whether the
standby node is passive or active? 

SP> As stated in the text "When geographically dispersed, the 
        number of hops of separation may increase failover time."

These details are pertinent to the
network operator, 
SP> And therefore to our benchmarking!

and has little to do with the definition of the standby
node (or the measurement of protection performance). If it is desired to
provide background information, this should preferably be done in a
different
section (an overview?) or, at the very least, provided without RFC 2119
keywords such as "MUST" and "MAY".

SP>  The authors believe this explanation is best served in its current 
location in the Discussion for term Standby Node to which it is
applicable.

13. In section 3.5.1: please clarify what an "unimpaired" packet is.
SP> It is believed that this is covered in the Discussion.

On Page 22:

14. In section 3.5.3: the term "PLBM" is referred to in the methodology
document as "PBLM".

SP> This is a point to be made for editing in the methodology and
requires 
no change to the Terminology.  The authors agree with the comment.

15. In section 3.5.3: it is recommended that the TBM is used. However,
the
methodology document makes no such recommendation. It is recommended
that
this recommendation be moved to section 6 of the methodology document.

SP> This is a point to be made for editing in the methodology and
requires 
no change to the Terminology.  The authors agree with the comment.

On page 25:

16. The definition of the TBM seems to include, nested within it, a
definition of "unimpaired packet". This term is used elsewhere in the
document, and hence should be pulled out and placed in a separate
section.

SP>  Al, you had provided the text with two occurences of the phrase
"unimpaired packet".  
Do you think this is a well-known term?  A term defined in another IETF
document?  
One that needs to be defined in this terminology document?

-----Original Message-----
From: Tom Alexander [mailto:[email-masked]] 
Sent: Thursday, March 06, 2008 12:03 AM
To: [email-masked]
Cc: Poretsky, Scott
Subject: RE: [bmwg] I-D ACTION:draft-ietf-bmwg-protection-term-03.txt 

Scott et. al.,

I read the above-referenced terminology document on protection
benchmarking.
Overall it seems pretty complete. I have a number of comments on the
document, enclosed in the attached text file.

Best regards,

- Tom