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

[Al Morton <acmorton at att.com>]

Comments on:

At 10:15 AM 11/13/2007, Internet-Drafts at ietf.org 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
bmwg at ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg