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

[Stewart Bryant <[e-mail]>]

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


-- 
For corporate legal information go to:

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