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

["Scott Poretsky" <[e-mail]>]

Hi Jerry,

I believe the attached posting to the mailing list provided
clarification.

Scott

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Jerry Perser
Sent: Saturday, February 28, 2009 1:58 PM
To: [e-mail]
Subject: Re: [bmwg] Comments on draft-ietf-bmwg-protection-meth-04.txt

Scott,

My view is both.

One, the BWMG focus is on a SUT/DUT.  If you can draw a box around what 
you are testing and some of the network is outside the box, then it 
falls under the BMWG.  If you can't draw a box around what you are 
testing or none of the network is outside the box, then is falls under 
the IPPM.  My notion of what a DUT is was destroyed by a company called 
Avici Systems.  Those guys can take 14 routers, each in their own rack, 
and connect them to look like a single DUT.  From the networks point of 
view, the routers look like a single DUT.  If your draft can not support

SUT, you should be clear about it.  I assumed that the draft supported 
both SUT and DUT.  Please clarify if we need another draft for SUT.

Two, does Al's comment about a Node Crash also apply to SUT, but not a
DUT?

Jerry Perser

Scott Poretsky wrote:
> David,
>
> Are you making a general statement or a point relevant to this thread?
>
> Scott
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> David Newman
> Sent: Wednesday, February 25, 2009 3:42 PM
> To: [e-mail]
> Subject: Re: [bmwg] Comments on draft-ietf-bmwg-protection-meth-04.txt
>
> On 2/25/09 12:38 PM, Scott Poretsky wrote:
>   
>> Yes, but in the BMWG we focus on a single DUT
>>     
>
> Not necessarily. Many bmwg documents use the term DUT/SUT, where SUT
may
> be comprised of multiple systems (just not on a production network).
>
> dn
>
> _______________________________________________
> bmwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bmwg
> _______________________________________________
> bmwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bmwg
>
>
>   


-- 
Jerry Perser

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

--- Begin Message ---

OK, that's a welcome clarification.

There was a line of thought I was pursuing in this thread
(whether Node Crashes are correlated failures or not),
and it sounds like we're closing in on this as the conclusion:

Although Node Crashes may cause the other devices in the network
to experience distinctly separate failure events, the DUT only
observes the crash as a single failure event on its connecting link.

re-booting,
Al

At 04:40 PM 2/25/2009, Scott Poretsky wrote:
>In the test topologies for this methodology document there is only 
>one DUT.  The DUT is always a PLR.  The benchmarks are specific to 
>the DUT.   The Tester may emulate all of the other nodes.  The test 
>topology may have additional devices as the other nodes if the 
>Tester does not emulate those.  This is the reason the baseline 
>throughput test cases are so important to perform first.
>
>This note will be added to the Introduction and Scope.
>
>Scott
>Sent via BlackBerry.
>
>-----Original Message-----
>From: "Al Morton" <[e-mail]>
>
>Date: Wed, 25 Feb 2009 16:06:02
>To: <[e-mail]>; <[e-mail]>
>Subject: Re: [bmwg] Comments on draft-ietf-bmwg-protection-meth-04.txt
>
>
>Scott,
>
>The meth draft has lots of SUT topologies --
>there may be one device you are focusing on (the
>point of local repair, PLR), but the system's
>performance is measured from TG to TA:
>
>             --------      --------      --------      --------
>            |  R1    |    |  R2    |    |   R3   |    |   R4   |
>         TG-|  HE    |    |  MID   |PRI |  MID   |PRI |  TE    |-TA
>            |        |----|  PLR   |----|        |----|        |
>             --------      --------      --------      --------
>                            |                            |
>                         BKP|          --------          |
>                            |         |   R6   |         |
>                             ---------|  BKP   |---------
>                                      |  MID   |
>                                       --------
>
>                               Figure 7.
>
>Also, the node that crashes is never the DUT,
>so the system sees correlated failures.
>
>Al
>
>At 03:38 PM 2/25/2009, Scott Poretsky wrote:
> >Yes, but in the BMWG we focus on a single DUT, so correlated events
> >are from the point of view of the DUT.
> >
> >Scott
> >Sent via BlackBerry.
> >
> >-----Original Message-----
> >From: "Al Morton" <[e-mail]>
> >
> >Date: Wed, 25 Feb 2009 14:27:07
> >To: Scott Poretsky<[e-mail]>; <[e-mail]>
> >Subject: Re: [bmwg] Comments on draft-ietf-bmwg-protection-meth-04.txt
> >
> >
> >It seems that a Node Crash would be viewed by adjacent nodes
> >as more than one of the Link Failure events listed in the definition
> >of Failure Event, below.  It all depends on how much of the
> >network you are looking at, and a crash seems to have the same kind of
> >"dependency on a common physical resource" mentioned in the definition
> >of correlated events: >1 links depend on the nodes.
> >
> > >       ...Some of these failure events are listed below.
> > >
> > >    Link failure events
> > >        - Interface Shutdown on PLR side with POS Alarm
> > >        - Interface Shutdown on remote side with POS Alarm
> > >        - Interface Shutdown on PLR side with RSVP hello enabled
> > >        - Interface Shutdown on remote side with RSVP hello enabled
> > >        - Interface Shutdown on PLR side with BFD
> > >        - Interface Shutdown on remote side with BFD
> > >        - Fiber Pull on the PLR side (Both TX & RX or just the TX)
> > >        - Fiber Pull on the remote side (Both TX & RX or just the RX)
> > >        - Online insertion and removal (OIR) on PLR side
> > >        - OIR on remote side
> > >        - Sub-interface failure (e.g. shutting down of a VLAN)
> > >        - Parent interface shutdown (an interface bearing multiple sub-
> > >          interfaces
> >
> >
> >At 12:21 PM 2/25/2009, Scott Poretsky wrote:
> > >No.  That is an unplanned uncorrelated failure.  Correlated failures
> > >require more than one Failover Event.
> > >
> > >Scott
> > >
> > >-----Original Message-----
> > >From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > >Al Morton
> > >Sent: Tuesday, February 17, 2009 11:14 AM
> > >To: [e-mail]
> > >Subject: Re: [bmwg] Comments on draft-ietf-bmwg-protection-meth-04.txt
> > >
> > > >The last sentence of the Scope:
> > > >    Benchmarking of unexpected correlated failures is currently out of
> > > >    scope of this document.
> > > >Wouldn't a Node Crash event be an example of an unexpected correlated
> > >failure?
> > >
> > >_______________________________________________
> > >bmwg mailing list
> > >[e-mail]
> > >https://www.ietf.org/mailman/listinfo/bmwg
> >
> >_______________________________________________
> >bmwg mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/bmwg

--- End Message ---