Re: [mpls-tp] [mpls] poll on draft-frost-mpls-tp-loss-delay-02.txt

["Lam, Hing-Kam (Kam)" <[e-mail]>]

Hi,

The following comments on draft-frost-mpls-tp-loss-delay-02 need to be addressed

1) Section 3.1 second last paragraph (and section 4.1.4 second paragraph) and section 3.2 second last paragraph (and section 4.2.3 second paragraph):
Why move fields in the packet when generating the response. A node could easily understand where to write timestamps/packet counters based on the ACH channel type and the Q/R bit. More specifically:
-        On the LM procedure, justification/clarification is missing on the why node B has to move the values of A_TxP and B_RxP from counter fields 1 and 2 to 3 and 4. We see no reason for doing the moving and suggest let counter fields 1, 2, and 3 dedicated for A_TxP, B_RxP, and B_TxP respectively.
-        On the DM procedure, justification/clarification is missing on the why node B has to move the values of T1 and T2 from Timestamp fields 1 and 2 to 3 and 4. We see no reason for doing the moving and suggest let Timestamp fields 1, 2, and 3 dedicated for T1, T2, and T3 respectively.

2) Section 3.1, sequence number should be removed. In MPLS-TP (where ECMP is not used), packet misorderings are very rare events.

3) Post-processing of DM and LM
The post-processing of DM and LM is quite application specific and therefore the reference to RFC 3393 should be removed. Transport networks will not rely on RFC 3393 for PDV calculation.

4) Control (error) code
In case an errored Query message is received, the generation of a Response message with an error code must be optional. Also the processing of a Response message with an error code (including also the automatic suspension of the LM/DM operation) should be optional.

5) Section 4.1.7 LM packet loss
The considerations in section 4.1.7 about loss of LM packets are not 100% accurate. As long as the counters do not wrap past the last saved count, lost LM packets do not cause any issue. The loss is simply calculated over the longer interval.

6) Section 4.1.7 LM packet misorder
The document should mention that in MPLS-TP (where ECMP is not used), packet misorderings are very rare events.

7) Section 4.2.5 Timestamp format negotiation
The timestamp negotiation procedure in section 4.2.5 is a configuration issue and must not be piggybacked to the OAM packet. Piggybacking the negotiation procedure in the OAM packet creates the unnecessary burden at the querier and responder to process these fields in every message exchange.

8) Section 1.1.2 Requirements for DM:
Not clear to what type(s) of LSP the last phrase of section 1.1.2 ("but only to enable the quantification of the one-way delay") refers to, point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, point-to-multipoint (unidirectional) LSPs, or all?

9) Section 1.2 Protocol Summary
The sentence "The LM protocol provides perfect loss measurement if the necessary implementation support is available" needs clarification or justification.
The sentence "The LM and DM protocols are designed to be simple and to support efficient hardware processing" is judgmental and not a summary of the protocol.

10) LM and DM frame format:
Clarification is needed on why need the fourth LM counter (A_RxP) and the fourth DM timestamp (T4) of DM in the protocol messages given that they are not exchanged/shared between the nodes. If the reason is to simplify hardware implementations at the receiver equipment in node A, please explicitly clarify so.

11) Section 2.1 the last sentence
Suggest change the last sentence from "This alternative approach to LM is for further study and will be described in a companion document" to "Such alternative approach to LM is outside the scope of this document".

12) Section 2.2 the fourth paragraph
Define and explain the "response code" in the phrase "At this point, B inserts an appropriate response code into the message ...."

13) Section 2.3 the sixth paragraph
Define and explain the "response code" in the phrase "B inserts an appropriate response code ..."

14) Section 3.2 last paragraph Padding:
Need to give the rationale for the option of not copying padding to the Delay Measurement response.
Need to add text to note that in case where no padding in the Delay Measurement response, the Message Length field needs to match with the length of the response message.

15) Section 5.1 second paragraph
Why the support of per-traffic-class basis LM is SHOULD and not a MUST?
Also, LM frames MUST have the same traffic class as the service they measure else misordering is invited. This consideration makes the option of  LM conducted over multiple classes unattractive.



Regards,

Kam







> -----Original Message-----

> From: [e-mail] [mailto:[e-mail]] On Behalf Of

> Loa Andersson

> Sent: Wednesday, June 30, 2010 5:41 AM

> To: [e-mail]; [e-mail]; MPLS-TP ad hoc team

> Subject: [mpls] poll on draft-frost-mpls-tp-loss-delay-02.txt

>

> Working Group,

>

> this email is to start a poll to adopt

> draft-frost-mpls-tp-loss-delay-02.txt

> as an MPLS working group draft.

>

> After recent experience, the chairs would like to remind you all

> what it means to conduct a poll to adopt a draft as a working group

> draft.

>

> - Please recall that the IETF does not "vote." Polls of a working

>    group are to gather information to help the chairs make their

>    decisions. Voting is not part of the normal working methods of

>    an IETF working group.

>

> - The "rough consensus" process used in the working group assumes

>    that people expressing opinions are also participating in the

>    development of standards documents.

>

> - Subscription to the list specifically to express an opinion is

>    noticed by the chairs who has access to information on the new list

>    members. Such behavior is not part of the normal working methods.

>

> - The purpose of a poll for adoption is to help the chairs understand

>    the level of support for a document (i.e. who has read it, who

>    believes it is a good starting point for working group work, who

>    will contribute to the work) and whether there are any significant

>    technical issues. Statements of objection must be backed up by

>    proper technical reasons.

>

> So please respond to this poll indicating whether you support the

> adoption of this draft or stating your technical issues.

>

> This poll ends eob July 15.

>

>

> Loa and George

> mpls wg co-chairs

>

> --

>

>

> Loa Andersson                         email: [e-mail]

> Sr Strategy and Standards Manager            [e-mail]

> Ericsson Inc                          phone: [phone]

>                                               [phone]

> _______________________________________________

> mpls mailing list

> [e-mail]

> https://www.ietf.org/mailman/listinfo/mpls