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

From: Ross Callon <[email-masked]>
Date: Sun, 6 Feb 2011 22:33:06 -0500

Working Group,

This is to start a four week working group last call on
"A Packet Loss and Delay Measurement Profile for MPLS-based 
Transport Networks"
(draft-ietf-mpls-tp-loss-delay-profile-02.txt).

Please send comments to the [email-masked] mailing list.

Also, please note that the related document 
"draft-ietf-mpls-loss-delay-01" is being last called in 
parallel on the MPLS WG email list. 

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

Ross, Loa, and George

MPLS WG co-chairs

---

From: Dan Frost <[email-masked]>
Date: Tue, 15 Feb 2011 14:15:19 +0000

Hi Linda,

Linda Dunbar <[email-masked]> writes:
> I have some issues with this draft:
> There had been a lot of discussions on email list on what should
> Initiator (querier) do when not receiving a response from far end.
>
> Ben Jenkins suggested the following text
> (http://www.ietf.org/mail-archive/web/mpls/current/msg05696.html)
> which is not incorporated to this new draft yet.
>
>       When initiating an LM operation, the far end may require a
>       period of time to become ready for the requested measurement
>       operation or the far end may not be able to support the
>       requested measurement. Under those circumstances, LM queries MAY
>       simply be discarded, and the querier expecting a response SHOULD
>       be prepared for this situation. Alternatively, the receiver MAY
>       respond, possibly in a rate-limited manner, to queries received
>       during this period with an appropriate notification code.  The
>       querier should abort the measurement after not receiving any
>       positive feedback when a specified timer expires.

With one exception, this text looks substantially the same to me as the
last paragraph of Section 4.1.1.  The exception is your addition of 'or
the far end may not be able to support the requested measurement' to the
first sentence, but that case is not what this text is meant to cover:
if the far end doesn't support the requested measurement, the right
thing to do is to reply with an appropriate error code so the querier
knows what went wrong.

> Section 3.5.3: It stated:
>        When a query is received with a Session Query Interval that is
>        too low for the receiver to support, the receiver SHOULD
>        include this object when it generates an error response.
>
> Question:
>       Which error code should be used? Is it 0x18:Error - Unsupported
>       Query Interval? If Yes, should add this to the sentence.

Yes, that's the purpose of this error code.  We can be explicit here.

>       What if the Querier indicates "0x2: No Response Requested"?

In general, a no-response-requested measurement means that the querier
can't receive any direct feedback; the assumption of this measurement
mode is that control is achieved through some external means, e.g. an
NMS that ensures consistent operation among the nodes involved.

> Section 4.1.5:
> * Should allow the Loss measurement to be calculated somewhere else,
> in case the initiator (querier) doesn't have the capacity to do the
> calculation.

Ben Mack-Crane has made comprehensive comments on this topic, so we'll
address it in that context.

> * Should add a description that measurement is to be stopped when far
> end not respond anymore.

OK.

Thanks for your comments!

-d

> Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 15 Feb 2011 16:07:12 +0000

Dan:

 You said:
            "if the far end doesn't support the requested measurement, the right thing to do is to reply with an appropriate error code so the querier knows what went wrong."

What if the reply message got lost? Then you have to add the mechanism to make far-end sending multiple messages with the correct Error Code.

So the simplest thing is for the Querier to stop the measurement either upon receiving a reply with Error Code or not receiving any reply for a while.

Linda Dunbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Frost
Sent: Tuesday, February 15, 2011 8:15 AM
To: Linda Dunbar
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [mpls] MPLS WG Last call on draft-ietf-mpls-loss-delay-01

Hi Linda,

OK.

-d

> Linda Dunbar
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Dan Frost <[email-masked]>
Date: Wed, 16 Feb 2011 11:22:45 +0000

Hi Linda,

On Tue, Feb 15, 2011 at 04:07:12PM +0000, Linda Dunbar wrote:
> You said:
>  "if the far end doesn't support the requested measurement,
>   the right thing to do is to reply with an appropriate
>   error code so the querier knows what went wrong."
> 
> What if the reply message got lost? Then you have to add the mechanism
> to make far-end sending multiple messages with the correct Error Code.

There's no extra mechanism needed; this is the normal operation of the
protocol.  A lost response just means another query/response will
happen.

> So the simplest thing is for the Querier to stop the measurement
> either upon receiving a reply with Error Code or not receiving any
> reply for a while.

Sure.  In essence, upon receiving a query requesting an unsupported
operation, the responder SHOULD respond with an appropriate error code,
and in general, the querier SHOULD time out any measurement attempt
that's been outstanding for too long.  We'll clarify this in the text.

Cheers,

-d