Hi Robert, Thank you very much for your reply, and I am sorry for my late response.
See inline, marked with [HE]; > >________________________________________ >From: [email protected] [[email protected]] On Behalf Of >[email protected] [[email protected]] >Sent: Thursday, July 14, 2011 7:22 AM >To: [email protected]; [email protected] >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 >>[email protected] mailing lists by 2011-07-14. Exceptionally, comments may be >>sent to [email protected] 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 >>[email protected] >>https://www.ietf.org/mailman/listinfo/mpls >> >_______________________________________________ >mpls mailing list >[email protected] >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 [email protected] https://www.ietf.org/mailman/listinfo/ietf
