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

From: [email-masked]
Date: Thu, 1 Jul 2010 15:14:02 +0800

Yes/Support

[email-masked] 写于 2010-06-30 17:40:42:

> 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: [email-masked]
> Sr Strategy and Standards Manager            [email-masked]
> Ericsson Inc                          phone: +46 10 717 52 13
>                                               +46 767 72 92 13
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 14 Jul 2010 09:04:27 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of

> Loa Andersson

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

> To: [email-masked]; [email-masked]; MPLS-TP ad hoc team

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

> mpls mailing list

> [email-masked]

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

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 14 Jul 2010 16:51:40 +0100

Kam

To pick up on a recurrent theme here, the concept is that the low level 
h/w can stamp the packet by simply (only) recognizing the ACH. It does 
not need to understand whether the msg is a request or a response, all 
that happens at another layer in the processing. So the packet format is 
marginally more complex at the higher layer, but as simple as possible 
at the lower layer.

Stewart

On 14/07/2010 15:04, Lam, Hing-Kam (Kam) wrote:
> 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.
>
> 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.
>
> 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.
>
> The document should mention that in MPLS-TP (where ECMP is not used), 
> packet misorderings are very rare events.
>
> 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.
>
> 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?
>
> 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.
>
> 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.
>
> 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/".
>
> Define and explain the "response code" in the phrase "At this point, B 
> inserts an appropriate response code into the message ...."
>
> 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.
>
> 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
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Loa Andersson <[email-masked]>
Date: Fri, 16 Jul 2010 13:26:11 +0200

Working Group,

this poll has ended.

We have a new working group document, could the authors please
re-publish the document as draft-ietf-mpls-tp-loss-delay-00.txt
without any other changes than the file name and dates.

/Loa

--