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

From: Al Morton <[email-masked]>
Date: Wed, 05 Dec 2007 09:59:28 -0500

Comments on:

At 10:15 AM 11/13/2007, [email-masked] wrote:

>         Title           : Benchmarking Terminology for Protection Performance
>         Author(s)       : S. Poretsky, et al.
>         Filename        : draft-ietf-bmwg-protection-term-03.txt
>         Pages           : 24
>         Date            : 2007-11-13
>

We have more time to work this, and a couple of definitions
here strike me as unnecessarily complex, in that they
refer to other terms we are trying to define when normal
language would suffice, IMO.

We can discuss these at the session.

Like this:
>      3.3.1.  Failover Event
>
>        Definition:
>        The occurrence of a planned or unplanned action in the network
>        that results in a change in the Path that data traffic traverses.
could be:
      3.3.1.  Failover Event

        Definition:
        The occurrence of a planned stoppage or malfunction in the network
        that results in a change in the Path that data traffic traverses.

>      3.3.2.  Failure Detection
>
>        Definition:
>        The process to identify at a sub-IP layer a Failover Event
>        along the Primary Path.

How about:
      3.3.2.  Failure Detection

        Definition:
        The process to identify a malfunction or planned stoppage
        at a sub-IP layer along the Primary Path.

and
>      3.3.3.  Failover
>
>         Definition:
>         The process to switch data traffic from the Protected Primary
>         Path to the Backup Path upon Failure Detection of a Failover
>         Event.

      3.3.3.  Failover

         Definition:
         The process to switch data traffic from the Protected Primary
         Path to the Backup Path upon detection of a malfunction or
         planned stoppage.

and even here:
>      3.3.4.  Restoration
>
>         Definition:
>         The act of failover recovery in which the Primary Path
>         recovers from a Failover Event, but is not yet forwarding
>         packets because the Backup Path remains the Working Path.

we could say:
      3.3.4.  Restoration

         Definition:
         The aspect of failover recovery in which the Primary Path
         recovers from a malfunction or planned stoppage, but is not
         yet forwarding packets because the Backup Path remains the
         Working Path.

and here:
>      3.3.5.  Reversion
>
>         Definition:
>         The act of failover recovery in which the Primary Path becomes
>         the Working Path so that it is forwarding packets.
becomes
      3.3.5.  Reversion

         Definition:
         The aspect of failover recovery in which the Primary Path becomes
         the Working Path so that it is forwarding packets.

Replacing "act" with "aspect" in these last two just seems like better
English to me.

And here's another language clean-up:
>      3.4.1.  Protection-Switching Node
>
>          Definition:
>          A node that is capable to participate in a Protection Switching
>          System.
becomes
      3.4.1.  Protection-Switching Node

          Definition:
          A node that is capable of participating in a Protection Switching
          System.

I realize I might be refining something I proposed
earlier, but it gets better every time!

Al
(participant)

PS:  I found this section from 3.3.1 a little confusing:
>        Discussion:
>        Failover Events include, but are not limited to, link failure
>        and router failure.  Routing changes are considered Convergence
>        Events [7] and are not Failover Events.  This restricts
>        Failover Events to sub-IP layers. Failover may be at the PLR or
>        at the ingress. If the failover is at the ingress it is
>        generally on a disjoint path from the ingress to egress.

Both link failure and router failure usually cause Convergence events
and Routing changes. I think we're trying to say is:

        Discussion:
        Failover Events may include link failure and router failure.
        Failover Events are distinguished from routing changes and
        Convergence Events [7] by the detection of the malfunction
        and subsequent protection switching at a sub-IP layer.
        Failover may be at a Point of Local Repair (PLR) or at the
        ingress. If the failover is at the ingress it is generally on a
        disjoint path from the ingress to egress.

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