Subject: [bmwg] RFC2544 Statement

From: Barry Constantine <[email-masked]>
Date: Thu, 28 Jul 2011 15:06:50 -0700

Hi All,

I think this is a good effort with the right intentions.

There are two (2) scenarios that network providers use RFC2544 (or derivatives) today:

1. "Turn-up" testing which is conducted on a business class, production network before end-customer traffic is commissioned.  This is generally considered the verification of the end-customer SLA.

2. Troubleshooting.  This is performed after a end-customer has been commissioned and the SLA is disputed (poor application performance, etc.).  The network provider coordinates a time to swtich the end-customer to a back-up link and then re-conducts RFC2544 type testing on the production link.

I think this statement will be taken more credibly by network providers if it is acknowledged that these types of scenarios exist today and that caution should be used when performing RFC2544 (especially in case #2, troubleshooting).

Al, I think you mentioned there was a section related to exceptions (?), if these points are agreeable, then I think this section should be moved closer to the front so that a reader will grasp the overall message.

My two cents,
Barry

---

From: Al Morton <[email-masked]>
Date: Fri, 29 Jul 2011 20:07:30 -0400

Hi Barry,

I think you've pointed-out two of the problems

with industry references to RFC 2544 in your message below:

Few, if any, vendors say that their tests are "derived
from"

RFC 2544, because then they would clearly state what parts of

the procedures they changed, what new metrics they defined, etc.

Also, few if any service providers use the exact RFC 2544 metrics

in their SLAs. Various metrics like Committed Info Rate and Delay
Variation

need to be measured and validated, but these metrics do not appear in

RFC 2544.

Speaking for my co-authors, I think we would prefer that network

providers apply appropriate standards for real-world service activation
and

trouble-shooting where they exist (ITU-T Rec Y.1564 is one example),

and develop new standards where they don't. Standards Development
Orgs

should include RFC 2544 as an informative reference if they believe

those methods can be used as a starting point for live

network test procedures and trouble-shooting.

Al

(as co-author/participant)

At 06:06 PM 7/28/2011, Barry Constantine wrote:

Content-Language: en-US

Content-Type: multipart/alternative;

boundary="_000_94DEE80C63F7D34F9DC9FE69E39436BE3A0BCB7BB3MILEXCH1dsjds_"

Hi All,

I think this is a good effort with the right
intentions.

There are two (2) scenarios that network
providers use RFC2544 (or derivatives) today:

1. "Turn-up"
testing which is conducted on a business class, production network before
end-customer traffic is commissioned.  This is generally considered
the verification of the end-customer SLA.

2. Troubleshooting.  This is performed
after a end-customer has been commissioned and the SLA is disputed (poor
application performance, etc.).  The network provider coordinates a
time to swtich the end-customer to a back-up link and then re-conducts
RFC2544 type testing on the production link.

I think this statement will be taken more
credibly by network providers if it is acknowledged that these types of
scenarios exist today and that caution should be used when performing
RFC2544 (especially in case #2, troubleshooting).

Al, I think you mentioned there was a section
related to exceptions (?), if these points are agreeable, then I think
this section should be moved closer to the front so that a reader will
grasp the overall message.

My two cents,

Barry

_______________________________________________

bmwg mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/bmwg

---

From: Barry Constantine <[email-masked]>
Date: Fri, 29 Jul 2011 17:30:54 -0700

That makes very good sense Al, especially the part that you pointed out the metrics that do not exist in RFC2544 and that providers use for SLAs.

Let me re-read the draft; I am thinking some of the points you make here would be very beneficial to point out in the intro.

I am supportive of this work and think a little more background will help providers to clearly understand the risks and drawbacks of RFC2544 testing.  Interpreted at face value, some providers my simply say "this is how we always test and this does not cause any problems".

Again I will reread and hope my comments are reasonable.

-Barry

Sent from my iPad

On Jul 29, 2011, at 8:07 PM, "Al Morton" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Barry,

Few, if any, vendors say that their tests are "derived from"
RFC 2544, because then they would clearly state what parts of
the procedures they changed, what new metrics they defined, etc.

Also, few if any service providers use the exact RFC 2544 metrics
in their SLAs. Various metrics like Committed Info Rate and Delay Variation
need to be measured and validated, but these metrics do not appear in
RFC 2544.

Speaking for my co-authors, I think we would prefer that network
providers apply appropriate standards for real-world service activation and
trouble-shooting where they exist (ITU-T Rec Y.1564 is one example),
and develop new standards where they don't. Standards Development Orgs
should include RFC 2544 as an informative reference if they believe
those methods can be used as a starting point for live
network test procedures and trouble-shooting.

Al

Hi All,

My two cents,
Barry
_______________________________________________
bmwg mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/bmwg>https://www.ietf.org/mailman/listinfo/bmwg