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

From: Jeff Byzek <[email-masked]>
Date: Tue, 11 Mar 2008 15:33:11 -0400

Howdy,

I'm new here and just attended the WG yesterday for the first times, so 
apologies in advance if I'm not familiar with the process.

General comment:

The benchmarks section (3.5) and the failover time calculation methods 
(3.6) (and perhaps some other sections) are not specific to protection 
switching and, in my opinion, should be in a separate document that 
other docs can reference.  For example, Scott discusses the exact same 
topics in his IGP convergence paper, and there's nothing specific about 
IGP vs protection mechanisms vs anything else (BGP, BFD) that would 
require these definitions to be unique.  Since most of the work has 
already been done, it's just a matter of moving relevant sections out 
and adding pointers.  I'm willing to (co)author this, perhaps titled 
something along the lines of "Convergence Mechanisms Terminology".

More specific stuff:

-In the introduction, each type of protection is described, but only one 
example is provided (for SONET APS) -- I think either all of them should 
include examples or none of them should.
-Perhaps 3.2.8 should include a provision for the possibility that the 
protected interface could be a link bundle
-In 3.3.2, the first sentence of the 2nd paragraph is redundant.  In 
fact, the whole paragraph is redundant.  I also think it would be useful 
to more clearly define the relationship between failover events and 
convergence events since there seems to be some overlap (or completely 
separate them if there's no overlap at all).  Or perhaps distinguish 
that failover events and convergence events can have lots of overlap, 
but perhaps the failure detection method is different.
-3.4.3 -- what's the difference between a headend node and a PLR?

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

---

From: "Poretsky, Scott" <[email-masked]>
Date: Wed, 12 Mar 2008 00:45:37 -0400

Hi Jeff,

The comments to these BMWG work items are very much appreciated and we
look forward to your continued involvement as the newest participant to
the working group.  It would be beneficial if you could provide your
list and justification for terms that overlap between the IGP
Convergence Benchmarking Terminology and the Sub-IP Protection
Benchmarking Terminology.  The BMWG certainly makes it a goal to re-use
existing IETF/BMWG terms whenever possible.  The other comments will be
incorporated.  The issue of PLR versus Headend has been raised by a
couple of other reviewers (as discussed at the microphone on Monday), so
that will certainly be rectified in the next revision.

Thanks,
Scott

-----Original Message-----
From: Jeff Byzek [mailto:[email-masked]] 
Sent: Tuesday, March 11, 2008 3:33 PM
To: [email-masked]
Cc: Poretsky, Scott; Rajiv Papneja; Samir Vapiwala; [email-masked]
Subject: Comments on draft-ietf-bmwg-protection-term-04

Howdy,

General comment:

More specific stuff:

-J

---

From: Jeff Byzek <[email-masked]>
Date: Thu, 13 Mar 2008 15:01:39 -0400

Hey Scott,

These are the definitions I feel could be generalized from the 
protection draft:

Failover Packet Loss
Reversion Packet Loss
Failover Time
Reversion Time
Additive Backup Delay
Time-Based Loss Method (TBLM)
Packet-Loss Based Method (PLBM)
Timestamp-Based Method (TBM)

And, honestly, everything from the IGP Data Plane Convergence 
Terminology draft, since they're applicable for other areas like BGP 
(regardless of if there's an active draft for it).

My first instinct was to merge the definitions of similar terms like 
"Failover Time" and "Convergence Time" but I can appreciate subtle 
differences in the concept of a Convergence Event and a Failover Event, 
even though there's overlap.

Another comment after re-reading the protection terminology draft -- it 
seems to assume a single protection mechanism that impacts a single 
stream.  I understand the desire keep the scope narrow, but the draft 
should also consider the possibility that the protection mechanism 
impacts multiple instances of protected objects.  The easiest example of 
this is a backup TE tunnel that protects multiple primary tunnels.  The 
reason this matters is that a definition like the Timestamp-Based Method 
assumes a single stream of traffic.  Once we add multiple streams that 
could have different convergence characteristics, TBM either loses 
accuracy or loses relevancy.  Thus, it might be useful to either 
elaborate on this possibility in the protection drafts and how they 
impact the measurements.

Alternatively, if we create a generic convergence terminology draft, we 
could elaborate there instead.

-J

---

From: "Poretsky, Scott" <[email-masked]>
Date: Fri, 14 Mar 2008 12:31:51 -0400

Hi Jeff,

The BMWG has recognized and appreciated the applicability of the IGP
Convergence drafts to other protocols.  This is why the BMWG decided to
tackle IGP Convergence first.  There is an active BGP Convergence
Benchmarking work item in the BMWG.  Also there has been a proposed work
item for LDP Convergence Benchmarking.  Both BGP and LDP convergence
have a dependency on IGP convergence.  Many of the terms and
methodologies developed in the IGP work can be referenced by the other
protocol convergence drafts that follow the IGP work.  As you note
below, subtle differences necessitate that the scope of these work items
be focused on the protocol being benchmarked.  I am sure the authors
would appreciate your review and comments on the BGP and LDP documents.

Also, thank you for the point about single stream versus multiple stream
measurements in the Sub-IP Protection Benchmarking draft.  The authors
will look at that and send a more detailed response.

Scott

-----Original Message-----
From: Jeff Byzek [mailto:[email-masked]] 
Sent: Thursday, March 13, 2008 3:02 PM
To: Poretsky, Scott
Cc: [email-masked]; Rajiv Papneja; Samir Vapiwala; [email-masked]
Subject: Re: Comments on draft-ietf-bmwg-protection-term-04

Hey Scott,

Failover Packet Loss
Reversion Packet Loss
Failover Time
Reversion Time
Additive Backup Delay

-J