Re: [mpls-tp] [mpls] MPLS WG last call on draft-ietf-mpls-loss-delay-01

Lavanya Srivatsa <lavanya.srivatsa@aricent.com> Mon, 07 March 2011 09:46 UTC

Return-Path: <lavanya.srivatsa@aricent.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD82D3A6916 for <mpls-tp@core3.amsl.com>; Mon, 7 Mar 2011 01:46:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkHl-+m1mD4q for <mpls-tp@core3.amsl.com>; Mon, 7 Mar 2011 01:46:19 -0800 (PST)
Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 475A93A6960 for <mpls-tp@ietf.org>; Mon, 7 Mar 2011 01:46:17 -0800 (PST)
Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id B5EBF36B80 for <mpls-tp@ietf.org>; Mon, 7 Mar 2011 15:14:13 +0530 (IST)
Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id A08CB36B68 for <mpls-tp@ietf.org>; Mon, 7 Mar 2011 15:14:13 +0530 (IST)
Received: from GUREXMB02.ASIAN.AD.ARICENT.COM ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Mon, 7 Mar 2011 15:17:27 +0530
From: Lavanya Srivatsa <lavanya.srivatsa@aricent.com>
To: MPLS TP <mpls-tp@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "ahmpls-tp@lists.itu.int" <ahmpls-tp@lists.itu.int>
Date: Mon, 07 Mar 2011 15:17:25 +0530
Thread-Topic: RE:[mpls-tp] [mpls] MPLS WG last call on draft-ietf-mpls-loss-delay-01
Thread-Index: AcvcrKnj6dQpB8sdTJmRxufP+QFKQA==
Message-ID: <E13C8C03049AFA4E9CEE5A21D3E7F85DB588762F@GUREXMB02.ASIAN.AD.ARICENT.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_E13C8C03049AFA4E9CEE5A21D3E7F85DB588762FGUREXMB02ASIANA_"
MIME-Version: 1.0
Subject: Re: [mpls-tp] [mpls] MPLS WG last call on draft-ietf-mpls-loss-delay-01
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Mar 2011 09:46:25 -0000

Authors,

Others have covered most of the major comments; I just have a couple of minor ones to add -

-          In Section 3.3 for Combined Loss/Delay Measurement Message Format, it states "The LM/DM message fields have the same meanings as the corresponding fields in the LM and DM message formats."
[Suggested Text] "The LM/DM message fields have the same meanings as the corresponding fields in the LM and DM message formats with the following exceptions - (a) the OTF of the LM message is to be interpreted from the QTF of the combined LM/DM message (b) the "Origin Timestamp" of the LM message is to be interpreted from the "Timestamp 1" of the combined LM/DM message.

-          In Section 4.2.5, suggest adding following sentence at the end of the last paragraph - "If the responder is not capable of supporting the querier's preferred timestamp format, the RTF will be equal to the RPTF. The querier should change/set its current QTF as per the received RPTF (thus giving preference to the responder's timestamp format) if such a format is supported by the querier; else the querier should discard the DM response and raise an appropriate notification to the user."

Apart from this, I have one query - Sections 3.1 and 3.2 state towards the end, that ensuring that counters and timestamps (respectively) are always written in the same fixed offset in the packet is an important property for hardware processing. Does the Combined LM/DM message format not take away this property if different formats (either combined or individual) can be used at different points of time during loss and delay measurements, thus requiring hardware to support different offsets at different points of time? Or would this be more of an implementation aspect?

- Lavanya


-----Original Message-----
From: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org<mailto:mpls-bounces%20at%20ietf.org>] On Behalf Of Ross Callon
Sent: Sunday, February 06, 2011 9:33 PM
To: mpls-tp at ietf.org; mpls at ietf.org; ahmpls-tp at lists.itu.int
Subject: [mpls] MPLS WG last call on draft-ietf-mpls-loss-delay-01


Working Group,

This is to start a four week working group last call on
" Packet Loss and Delay Measurement for MPLS Networks"
(draft-ietf-mpls-loss-delay-01).

Please send comments to the mpls at ietf.org mailing list.

Also, please note that the related document
" draft-ietf-mpls-tp-loss-delay-profile-02.txt" is being last called in
parallel on the mpls-tp email list (mpls-tp at ietf.org).

This working group last call ends on Monday March 7, 2011.

Ross, Loa, and George

MPLS WG co-chairs