Hi Robert, Thank you very much for your reply, and I am sorry for my late response. See inline, marked with [HE]; > >________________________________________ >From: mpls-bounces@xxxxxxxx [mpls-bounces@xxxxxxxx] On Behalf Of hideki.endo.es@xxxxxxxxxxx [hideki.endo.es@xxxxxxxxxxx] >Sent: Thursday, July 14, 2011 7:22 AM >To: ietf@xxxxxxx; mpls@xxxxxxxx >Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivit > >>The changes in this version have massive impact for CC/CV/RDI implementation. >>We, venders, have kept making efforts on interoperability test again and again. >>These changes spoil this effort. > >>Especially, revival of Poll/Final sequence doesn't make sense. >>Originally, in my understanding, Poll/Final sequence was excluded from this draft >>to avoid making HW implementation difficult. > >[RR] preventing a peer from modifying the rate once the initial target rate was achieved i.e arbitrary re-negotiation was and is excluded, that was the "problem" the group consensus was to solve. > > >However P/F is needed to get from the initial 1 per second default rate to the desired rate. This and the rational for an initial P/F were discussed in detail back in March /April. [HE]My understanding is far from yours. The cc-cv-rdi-03 said "Poll/final discipline can only used for VCCV and UDP/IP encapsulated BFD.". In my understanding, this meant that Poll/Final Sequence MUST NOT be used for GAL/G-ACh. In other words, GAL/G-ACh MUST work well without Poll/Final Sequence in the case of getting from initial state. I think this was the group consensus. If the consensus was only for re-negotiation, why was P/F excluded from GAL/G-ACh? > > >>Even though it was difficult to change CC interval arbitrary, >>the problem should be solved by defining how to transit DOWN/INIT state to UP state. > >[RR] There is no problem in defining how to transit from Down/Init to UP state, it's covered in the existing state machine and is not changed. [HE]Sorry for lack of explanation. I meant the interval change timing should be defined in the case of transition DOWN/INIT to UP state without P/F sequence for GAL/G-ACh. BR, Hideki > >Cheers > >Rob > > >>The direction which reached consensus once should NOT be changed easily >>in order to respond to the market requirements. > >>IMO, such major changes should NOT be added right before becoming RFC. > >>I found at least four major/minor changes as follows; >>1)Revival of Poll/Final sequence >>2)Change of MEP ID formats >>3)Change of Diag. Code >>4)Change of CV interleaved definition > >BR, >Hideki > > >> >>The IESG has received a request from the Multiprotocol Label Switching WG >>(mpls) to consider the following document: >>- 'Proactive Connectivity Verification, Continuity Check and Remote >> Defect indication for MPLS Transport Profile' >> <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> as a Proposed Standard >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action. Please send substantive comments to the >>ietf@xxxxxxxx mailing lists by 2011-07-14. Exceptionally, comments may be >>sent to iesg@xxxxxxxx instead. In either case, please retain the >>beginning of the Subject line to allow automated sorting. >> >>Abstract >> >> Continuity Check, Proactive Connectivity Verification and Remote >> Defect Indication functionalities are required for MPLS-TP OAM. >> >> Continuity Check monitors the integrity of the continuity of the >> label switched path for any loss of continuity defect. Connectivity >> verification monitors the integrity of the routing of the label >> switched path between sink and source for any connectivity issues. >> Remote defect indication enables an End Point to report, to its >> associated End Point, a fault or defect condition that it detects on >> a pseudo wire, label switched path or Section. >> >> This document specifies methods for proactive continuity check, >> continuity verification, and remote defect indication for MPLS-TP >> label switched paths, pseudo wires and Sections using Bidirectional >> Forwarding Detection. >> >> >>The file can be obtained via >>http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >> >>IESG discussion can be tracked via >>http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/ >> >> >>No IPR declarations have been submitted directly on this I-D. >>_______________________________________________ >>mpls mailing list >>mpls@xxxxxxxx >>https://www.ietf.org/mailman/listinfo/mpls >> >_______________________________________________ >mpls mailing list >mpls@xxxxxxxx >https://www.ietf.org/mailman/listinfo/mpls > > >This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf