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

From: "t.petch" <[email-masked]>
Date: Wed, 2 Mar 2011 16:46:03 +0100

The choice of parameters here looks fine but the language that goes with it less
so.

The protocol will still send the parameters in TLV but this I-D says that
"When an LM session is externally configured, the values of several
   protocol parameters can be fixed in advance at the endpoints involved
   in the session, so that inspection or negotiation of these parameters
   is not required."
" A simple implementation may assume that external configuration will
   ensure that both ends of the communication are using the default
   values for these parameters."

This seems to me too cavalier.  If one end is configured correctly for
eg packet and the other incorrectly for byte and these recommendations
are followed, then the protocol will work, will produce values and those
values will be a complete nonsense.  Ditto the other parameters and DM.

I do not think we should be recommending something which is open
to such errors.  There have been a fair number of posts on the mpls-tp
list about misconfiguration, about the fact that it is always with us
and that we need to be robust in the presence of it.  Here we seem
to be digging a heffalump trap for mpls-tp to fall into.

Tom Petch

----- Original Message -----
From: "Ross Callon" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, February 07, 2011 4:33 AM
Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-loss-delay-profile-02

> 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
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Thu, 3 Mar 2011 16:15:00 +0100

See below for a list of major and minor comments.

Thanks,
Marc
--------------------------------------------

Major comments

- Section 2.7.9

The draft specifies the 1588 (PTP) is the default and a MUST. While there is a good amount of hardware out there that supports 1588 but making this a MUST means that older hardware that supports NTP and not 1588 would require the carrier to upgrade their equipment for this.

Shouldn't NTP be the default and a MUST, and 1588 PTP an option?

- Comment #5: Proposed text as last sentence of sections 4.1.3, 4.1.4,
4.2.[1-3]

In the case of an invalid message (e.g. request or response), an error report should be made, in a form a response message if the code = 0 or 
1, or as an alarm report.

Suggest rewording sentence in section 3.1:

"0x2: No Response Requested.  Indicates that no response to the query should be sent. This mode can be used when an NMS is controlling both nodes"

- Section 3.4

After sentence "1: Sequence number.  This value indicates that the timestamp field is to be viewed as a simple 64-bit sequence number."

Suggest adding sentence: The sequence number provides a simple solution for applications that don't need a real absolute timestamp but just an
indication of message ordering.  An example is LM exception detection.

- Section 3.5.1

Suggest adding sentence:

"Asymetrical padding may be useful in the case of OOB response or when different MTUs are used in a bidir path"

- Suggest deleting "which is usually what is desired." in section 4.1.10

- Section 4.1.9

Suggestion adding sentence "Separate test message protocol SHOULD include a timeout value that informs the responder when to discard any state associated with this test."

Minor comments

- Suggest adding sentence in section 1

"The direct method is also known as "frame-based" in [Y.1731]. The inferred method is a superset of the "synthetic" approach being currently specified within Ethernet documents, because it allows for the possiblity of decoupling measurement messages from test messages"

- editorial - Section 2.1, page 8, 3rd paragraph: change "response code" to "response control code"
 
Editorial - Section 2.3, page 10, 7th paragraph: change "response code" to "response control code"

- Section 2.3

Clarify that clock synchronization is required for 2-way channel delay but not for roundtrip delay

- Fix consistency between 1588v1 and v2 references

- Editorial - Section 3.5.3: In second paragraph, change "too low" to "too short", and in last paragraph, change "Lower" to "Shorter".

- Section 4.1.10: We can note that misorderings are rare in the absence of ECMP.

----- Original Message -----
From: "Ross Callon" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, February 07, 2011 4:33 AM
Subject: [mpls] MPLS WG last call on draft-ietf-mpls-tp-loss-delay-profile-02

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

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Thu, 3 Mar 2011 16:30:04 +0100

Thanks,
Marc

- Add comment "ECMP/LDP/PHP considerations are not applicable to MPLS-TP"

- Section 2: Suggest removing "This profile is restricted to direct-mode 
LM and therefore uses the MPLS Direct Packet Loss Measurement (DLM) Channel Type in the Associated Channel Header (ACH)."

- It should be specified that the message rate for LM and DM packets should be configurable from the operator on a MEP, separately for LM and DM.

- Add following recommended intervals: 

Recommended intervals for direct or inferred LM messages is: 100ms, 1s, 10s, 1 min, 10 min 

Recommended intervals for LM test messages is: 10ms, 100ms, 1s, 10s, 1 min

Recommended intervals for DM messages is: 1s, 10s, 1 min, 10 min

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Thu, 3 Mar 2011 16:32:38 +0100

Sorry, I'm posting the same message again with the right subject this time.
See below for a list of major and minor comments.

Thanks,
Marc

Major comments

- Section 2.7.9

- Section 3.4

- Section 3.5.1

Suggest adding sentence:

- Section 4.1.9

Minor comments

 

- Section 2.3

---

From: Dan Frost <[email-masked]>
Date: Fri, 4 Mar 2011 12:33:56 +0000

Hi Tom,

On Wed, Mar 02, 2011 at 04:46:03PM +0100, t.petch wrote:
> The choice of parameters here looks fine but the language that goes
> with it less so.
> 
> The protocol will still send the parameters in TLV but this I-D says
> that "When an LM session is externally configured, the values of
> several protocol parameters can be fixed in advance at the endpoints
> involved in the session, so that inspection or negotiation of these
> parameters is not required." " A simple implementation may assume that
> external configuration will ensure that both ends of the communication
> are using the default values for these parameters."
> 
> are followed, then the protocol will work, will produce values and
> those values will be a complete nonsense.  Ditto the other parameters
> and DM.
> 
> I do not think we should be recommending something which is open to
> such errors.  There have been a fair number of posts on the mpls-tp
> and that we need to be robust in the presence of it.  Here we seem to
> be digging a heffalump trap for mpls-tp to fall into.

Do you have some alternative text to propose that indicates the
desirability of common-sense sanity-checking without running afoul of,
for example, those who insist that they should not have to inspect
certain fields because an NMS will take care of everything?

-d

---

From: Ross Callon <[email-masked]>
Date: Wed, 9 Mar 2011 14:50:10 -0500

The WG last call on draft-ietf-mpls-tp-loss-delay-profile-02 has now ended.

Thanks to all for the useful comments received. 

Ross, Loa, and George
MPLS WG co-chairs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Sunday, February 06, 2011 10:33 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [mpls-tp] MPLS WG last call on draft-ietf-mpls-tp-loss-delay-profile-02

Working Group,

Ross, Loa, and George

MPLS WG co-chairs