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

From: Lavanya Srivatsa <[email-masked]>
Date: Mon, 7 Mar 2011 15:17:25 +0530

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

________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

---

From: Dan Frost <[email-masked]>
Date: Mon, 7 Mar 2011 13:28:20 +0000

Hi Lavanya,

On Mon, Mar 07, 2011 at 03:17:25PM +0530, Lavanya Srivatsa wrote:
> -          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.

OK.

> -          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."

This doesn't add anything except to restrict how the querier proceeds
after receiving a response, which is intentionally left open, but it's
fair to add a note that the user should be alerted in case the querier
determines that format support is irreconcilable.

> 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?

This is all very implementation-specific, but the idea is to make the
processing of any given message type (ACH type) as simple as possible.
The offsets may of course differ across ACH types.  Also one would not
mix and match message types within a single measurement session.

Thanks for your review!

-d