Subject: Re: [bmwg] WG adoption of draft-asati-bmwg-reset-03

From: "Fernando Calabria (fcalabri)" <[email-masked]>
Date: Tue, 13 Apr 2010 10:20:52 -0500

Scott, while we sympathize with  your request, it is beyond the scope of
the current draft / work 

Rgds 

Fernando Calabria

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Scott Poretsky
Sent: Thursday, April 08, 2010 5:22 PM
To: Al Morton; [email-masked]
Subject: Re: [bmwg] WG adoption of draft-asati-bmwg-reset-03

I would be much more interested to have a work item to measure the
conditions that cause a networking device's software to reset.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Al Morton
Sent: Thursday, April 08, 2010 5:07 PM
To: [email-masked]
Subject: [bmwg] WG adoption of draft-asati-bmwg-reset-03

BMWG,

At our IETF-77 session, there was support to adopt the subject draft
(but few readers present at the meeting). We received advice
(from AD-Advisor Ron) that BMWG could add this work item under our
current charter.

Therefore, we are raising the question again on the list:

Should BMWG adopt http://tools.ietf.org/html/draft-asati-bmwg-reset-03
as a chartered work item?

Please *read* and express your opinion on whether or not this
Internet-Draft should be adopted as an Informational RFC.
Send your comments to this list or [email-masked]
by April 26th, at 5PM US EDT, 2200 GMT.

Al
bmwg chair

At 01:02 PM 2/19/2010, Fernando Calabria (fcalabri) wrote:
>Content-Type: multipart/related;
>         type="multipart/alternative";
>         boundary="----_=_NextPart_001_01CAB185.558EF827"
>Content-class: urn:content-classes:message
>
>Hello WG
>
>We just submitted a new revision of the  draft-asati-bmwg-reset , so 
>far we incorporated all the comments and feedback received by you, 
>so please take some time "if possible" to go over the document a and 
>let us know your thoughts and why not any  questions and or concerns 
>you may have
>
>
>Kind Regards
>
>Fernando Calabria & Authors
>

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

---

From: "Scott Poretsky" <[email-masked]>
Date: Tue, 13 Apr 2010 19:05:25 +0300

Fernando,

I appreciate your sympathy for users experiencing software resets.  I
think it is laughable that someone wants to benchmark the duration of a
software reset.  A technically-viable standard would first determine the
conditions that cause the device to reset.  Let's say hypothetically,
under Condition Set 1 vendor C resets at 180 seconds and vendor J resets
at 24 hours.  Vendor C has optimized software to recover from the
software reset in 30 seconds.  Vendor J has its software reset achieve
the same level of recovery in 240 seconds.  According to your proposed
work Vendor C would have a better reported result, which is wrong. The
mission of BMWG is to provide clarity through the smoke and mirrors, not
enable vendors to create more smoke and mirrors.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fernando Calabria (fcalabri)
Sent: Tuesday, April 13, 2010 11:21 AM
To: Fernando Calabria (fcalabri); [email-masked]
Subject: Re: [bmwg] WG adoption of draft-asati-bmwg-reset-03

Rgds 

Fernando Calabria

-----Original Message-----

Scott

-----Original Message-----

BMWG,

Al
bmwg chair

---

From: Al Morton <[email-masked]>
Date: Tue, 13 Apr 2010 12:12:19 -0400

Scott,

Your response seems to match the scope you proposed,
rather than the scope of the draft and proposal we are
discussing.  I think you know the next step now, if not,
see the last paragraph of the announcement below.

Al

---

From: "Fernando Calabria (fcalabri)" <[email-masked]>
Date: Tue, 13 Apr 2010 11:32:29 -0500

Scott, my comments / replies inline,,, 

Rgds 

Fernando 

-----Original Message-----
From: Scott Poretsky [mailto:[email-masked]] 
Sent: Tuesday, April 13, 2010 12:05 PM
To: Fernando Calabria (fcalabri); [email-masked]
Subject: RE: [bmwg] WG adoption of draft-asati-bmwg-reset-03

Fernando,

I appreciate your sympathy for users experiencing software resets.  I
think it is laughable that someone wants to benchmark the duration of a
software reset.  A technically-viable standard would first determine the
conditions that cause the device to reset

>>> Determine the conditions is really quite complex and vendor
"dependant" , each  platform specific   software implementation is
different, and the idea behind all these efforts is to steer away from
vendor's specific implementations .... 

.  Let's say hypothetically,
under Condition Set 1 vendor C resets at 180 seconds and vendor J resets
at 24 hours.  Vendor C has optimized software to recover from the
software reset in 30 seconds.  Vendor J has its software reset achieve
the same level of recovery in 240 seconds.  According to your proposed
work Vendor C would have a better reported result, which is wrong.

>>> Why this  is wrong ?? apologies but I don't quite follow it ,  with
this work, we are just measuring the amount of packets / traffic lost
(duration of the outage)  while all  vendors implementations are subject
to exactly the same failure / condition  (in other words the end user
experience / overall convergence) without getting into each specific
vendor's implementation details  / recovery mechanisms /  for even
Software and or Hardware failures.... 

>>> In the example you just provided one vendor may reset after 24 hours
(you are saying that this is better)   but maybe no network connectivity
or degraded service / performance   (traffic loss)  was experience for
this period of time ... (so now my question is which implementation you
think it is better now ?? 

>> Not sure what is more fare than comparing the amount of traffic loss
/ convergence time after the same set of failure / conditions ? 

 The

>> I sympathize with your comments from the context that there is open
room for additional work / drafts when it comes to determine the
conditions that cause a device to reset, but this like I mentioned
before is outside the scope of the current work , (we don't want to
establish any condition, they are fixed in our proposal while some are
mandatory and some others optional) 

Scott

-----Original Message-----

Rgds 

Fernando Calabria

-----Original Message-----

Scott

-----Original Message-----

BMWG,

Al
bmwg chair