Subject: Re: [mpls-tp] OAM requirements discussions in Geneva

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Wed, 4 Feb 2009 12:28:54 -0500

Hi Huub,

I had forgot to reply on this one - I was referring to the recent
liaison from Q17/12 (from their Dec 9-11, 2008) meeting "Comments on
Y.1731 PM" as it specifically mentioned MPLS-TP and the need for
alignment on definitions. It may have got lost with the churn in your
Question shift to SG15?

Deborah

-----Original Message-----
From: Huub van Helvoort [mailto:[email-masked]] 
Sent: Thursday, December 18, 2008 3:31 PM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: Maarten Vissers; Greg Mirsky; Adrian Farrel; [email-masked]
Subject: Re: [mpls-tp] OAM requirements discussions in Geneva

Dear Deborah,

You wrote:

> Considering the considerable debate in SG12 and MEF on Y.1731 
> definitions and their recent liaisons to SG15, we should ensure we are

> aligned also with those groups and their preferred definitions. 

Would you please be so kind to elaborate on the above.

What was the topic of the debate?
And if possible can you tell me the where I can find the liaisons
you mention?

As the rapporteur of Q10/15 I have the responsibility of Y.1731,
which was discussed in the recent SG15 meeting. However there
were no incoming liaisons from SG12 nor MEF.

Regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 04 Feb 2009 23:03:36 +0100

Dear Deborah,

You wrote:

> I had forgot to reply on this one.

Thank you for replying now.

> - I was referring to the recent

I have spent 3 hours searching the ITU-T documents for this liaison
but could not find a liaison with the title you mention. Maybe it
was drafted and is still in the process of being published.
Neiter did the rapporteur of Q17/12 (one of your colleagues) mention
it in an email exchange I had with him on december 18 2008.
All he mentioned in that exchange was a liaison titled "Use of RFC
2544 in Y.1731".

This was drafted in the Q17/12 interim meeting April 1-3, 2008 and
accepted in the plenary meeting of SG12 May 22-30, 2008:
http://www.itu.int/md/T05-SG12-080522-TD-WP3-0186/en
[186-WP3]  Report of Q17 Meeting and Status, ITU-T SG12
Quote" Q17/12 developed a Liaison to Q5/13 giving guidance on use
of IETF Benchmarking Methodology Working Group’s RFC 2544 in Y.1731,
the Ethernet OAM Recommendation."

This liaison was sent to Q5/13 because at that time the move of
this question to SG15 was not finalised. So it appeared as:
http://www.itu.int/md/T05-SG13-080912-TD-WP4-0259/en
[259-WP4]  Use of RFC 2544 in Y.1731, ITU-T SG13
Meeting  from 2008-09-12 to 2008-09-12
Quote" The use of RFC 2544 in Y.1731 was discussed, and we offer
the following comments. Such tests do not appear to be within the
scope of Y.1731."

Note that Y.1731 contains a warning note where RFC 2544 is
mentioned that the method described in RFC 2544 should be used
only when there is no traffic on the tested section.

After the agreement to move Q5/13 to SG15 i.e. Q10/15 the liaison
has also been transferred and is now available as:
http://www.itu.int/md/T09-SG15-090928-TD-WP3-0095/en
[95-WP3]  Use of RFC 2544 in Y.1731, ITU-T SG 15
Meeting  from 2009-09-28 to 2009-10-09

So it is not lost and will be discussed and replied in the next
Q10/15 meeting.

Regards, Huub.

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Thu, 5 Feb 2009 09:53:58 -0500

Hi Huub,

This is a different liaison. Al (Rap of Q17/12 - he's also Chair of
IETF's bmwg) will check on it and send to you. The liaison provides PM
definitions which are consistent with that used in the industry. It is
recommended they be used for Y1731 and future OAM work on MPLS-TP.
Deborah

-----Original Message-----
From: Huub van Helvoort [mailto:[email-masked]] 
Sent: Wednesday, February 04, 2009 5:04 PM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]
Subject: Re: [mpls-tp] OAM requirements discussions in Geneva

Dear Deborah,

of IETF Benchmarking Methodology Working Group's RFC 2544 in Y.1731,

Regards, Huub.

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 6 Feb 2009 08:12:52 -0600

Deborah,

	Perhaps you could send it to this list, as opposed to just
sending it to Huub?  Others would like to see it as well...

--
Eric 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Thursday, February 05, 2009 9:54 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] OAM requirements discussions in Geneva

Hi Huub,

-----Original Message-----
From: Huub van Helvoort [mailto:[email-masked]] 
Sent: Wednesday, February 04, 2009 5:04 PM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]
Subject: Re: [mpls-tp] OAM requirements discussions in Geneva

Dear Deborah,

Regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 06 Feb 2009 17:20:16 +0100

Hi Eric,

> sending it to Huub?  Others would like to see it as well...

Here is a link:
http://wftp3.itu.int/packet/Dec2008_Q17/OUT-docs/LS_SG13_Y1731.doc

Cheers, Huub.

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 9 Feb 2009 08:08:01 -0600

Thanks, Huub for the pointer!

I found this very interesting reading, especially considering that we
have discussed these same sources of potential measurement inaccuracy  
in the design team meetings in Westford, MA, USA (hosted by Juniper) and
in Martlesham Heath, UK (hosted by BT).

It must be noted that the potential sources of inaccuracy in measuring
a single errored second have only a very weak impact on the reliability
of SES as a performance monitoring parameter, given the way that an SES
determination is used to trigger Unavailability (which converts to what
the service provider typically worries about in SLA terms).  An off-by-
N error (resulting from frame re-ordering) needs to occur for each of
10 consecutive measurements before any Unavailable Seconds would be
reported.

I believe it's quite easily arguable that a service that delivers out-
of-order frames for 10 consecutive measurement periods in a row may be
an indication of some problem that requires reporting anyway.

We must also consider that - for routing changes (particularly within a
building or CO, as opposed to a change where light-speed delay is likely

to be afactor) - unless the PDUs for a single measured service are a 
substantial fraction of link speeds in the routing core, the probability

of an actual out-of-order delivery (within the service instance) may be 
significantly smaller in many cases than was the case when link speeds 
were typically measured in K-bits/second.  Where this does not apply, a 
service provider may elect to pin the path for those premium services 
that are likely to require such accurate measurement.

--
Eric

-----Original Message-----
From: Huub van Helvoort [mailto:[email-masked]] 
Sent: Friday, February 06, 2009 11:20 AM
To: Eric Gray
Cc: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
Subject: Re: [mpls-tp] OAM requirements discussions in Geneva
Importance: High

Hi Eric,

Here is a link:

Cheers, Huub.