Hi Martin, I've added references to 4.7 and 4.13.2. The new version -15 has been published. Thank you for your help and support.
Regards, Greg On Tue, Apr 17, 2018 at 12:31 PM, Martin Vigoureux <[email protected]> wrote: > Greg, > > I'm fine your proposal below. > Please post the final update whenever you can. > Thx > > -m > > > Le 2018-04-17 à 20:40, Greg Mirsky a écrit : >> >> Hi Martin, >> I have not ignored that comment but missed to ack its acceptance. Two >> other outstanding questions: >> >> * the text, that I've misinterpreted earlier, is in the Overview >> section: >> >> Although this document describes a single head and a >> set of tails >> spanned by a single multipoint path, the protocol is >> capable of >> supporting (and discriminating between) more than one >> multipoint >> path >> at both heads and tails. >> There is no text to describe how one could achieve that. >> Wouldn't it >> be worth adding some? >> >> GIM>> The question of applicability of this specification to >> mp2mp scenario came up at BIER WG meeting in London. Perhaps we >> can say the these questions are ouside the scope of this >> document and discuss whether there are interested to work on >> mp2mp case as a separete document? >> >> I don't read this part of the document as talking about mp2mp but >> rather as talking about multiple p2mp trees. >> >> Sections 4.7 and 4.13.2 provides details on demultiplexing BFD >> control packets at a MultipointTail. Would the reference to these >> sections be sufficient? >> * yes, moved the reference to Point-to-Point session to section 4.4.1 >> >> Attached please find the diff between -14 and the working version of the >> draft. Please let me know if the changes address your comments. Will upload >> the new version promptly. >> >> Regards, >> Greg >> >> On Tue, Apr 17, 2018 at 9:49 AM, Martin Vigoureux >> <[email protected] <mailto:[email protected]>> wrote: >> >> Greg, >> >> thanks. please see in-line. >> >> once I see the update published I will request IETF LC. >> >> -m >> >> Le 2018-04-17 à 18:34, Greg Mirsky a écrit : >> >> Hi Martin, >> thank you for your thorough review, thoughtful comments and kind >> words. >> Please find my answers to your questions in-line and tagged GIM>>. >> >> Regards, >> Greg >> >> On Tue, Apr 17, 2018 at 8:06 AM, Martin Vigoureux >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] >> >> <mailto:[email protected]>>> wrote: >> >> [resend, wrong bfd wg address in first attempt ...] >> >> Authors, WG, >> >> thank you for this document. It is clear and well written. >> I didn't find any technical comment to make so I've been >> nit picking :-) >> Please find those comments below. >> >> regards, >> martin >> >> --- >> Please check and address the nits: >> >> https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt >> >> <https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt> >> >> <https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt >> >> <https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-bfd-multipoint-14.txt>> >> >> On that aspect, does this document really update 7880 as >> the header >> says? The Introduction only refers to 5880 and it is not >> clear in >> the body of the Document what effectively impacts 7880. The >> only >> thing I saw is the addition of new session types but that >> does not >> require an update in my opinion. Could you clarify? >> GIM>> Yes, you'correct, the only connection to RFC 7880 are >> the new >> values of bfd.sessionType. The proposal to list RFC 7880 as >> updated >> by this specification was inteded to address Errata to RFC >> 7880 >> <https://www.rfc-editor.org/errata_search.php?rfc=7880 >> <https://www.rfc-editor.org/errata_search.php?rfc=7880>>. >> >> I am not sure how this document relates to or addresses the errata. >> So I still think it does not update 7880. >> >> >> i.e. existence of a path between the sender and the >> receiver. >> do you mean "forwarding path"? >> GIM>> Yes. Updated to >> >> i.e. existence of a forwarding path between the sender and >> the receiver >> >> thx >> >> >> Section 2. and Section 3. seem a bit redundant. They both >> state the >> same thing but from a different angle. Not critical. >> >> >> Although this document describes a single head and a >> set of tails >> spanned by a single multipoint path, the protocol is >> capable of >> supporting (and discriminating between) more than one >> multipoint >> path >> at both heads and tails. >> There is no text to describe how one could achieve that. >> Wouldn't it >> be worth adding some? >> >> GIM>> The question of applicability of this specification to >> mp2mp scenario came up at BIER WG meeting in London. Perhaps we >> can say the these questions are ouside the scope of this >> document and discuss whether there are interested to work on >> mp2mp case as a separete document? >> >> I don't read this part of the document as talking about mp2mp but >> rather as talking about multiple p2mp trees. >> >> >> >> >> Point-to-point sessions, as described in [RFC5880], are >> of type >> PointToPoint. >> Does this really fit in Section 4.2 which looks to be about >> the >> mpBFD session model. >> >> GIM>> I think that this short reminder is helpful to explain why >> this document adds value PointToPoint, section 4.4.1, to the >> defined in RFC 7880 bfd.sessionType variable. >> >> Well, I would move the text to 4.4.1 then, but not critical. >> >> >> >> >> Sessions of type MultipointHead MUST NOT send BFD >> control packets >> with the State field being set to INIT, and MUST be >> ignored on >> receipt. >> English is not my native language but I wonder if this >> really says >> what you want. It seems that "Sessions" is the subject of >> "MUST be >> ignored" while I think it's the packets which are the >> intended >> subject. So I'd write: >> and those packets MUST be ignored on receipt. >> >> You chose to ignore that one or simply missed it? >> >> >> >> Because there is no three-way handshake in Multipoint >> BFD, a newly >> started head (that does not have any previous state >> information >> available) SHOULD start with bfd.SessionState set to >> Down and with >> bfd.RequiredMinRxInterval set to zero in the >> MultipointHead session. >> >> To shut down a multipoint session a head MUST >> administratively set >> bfd.SessionState in the MultipointHead session to >> either Down or >> AdminDown and SHOULD set bfd.RequiredMinRxInterval to >> zero. The >> In both these paragraphs one could read that the head >> "SHOULD set >> bfd.RequiredMinRxInterval to zero" while 4.4.2 says MUST. >> Clarification needed? >> >> GIM>> Section 4.4.2 mandates initialization of >> bfd.RequiredMinRxInterval and, I think, applies to the first >> paragraph you've pointed. Would the following be clear and >> consistent: >> Because there is no three-way handshake in Multipoint BFD, >> a newly >> started head (that does not have any previous state >> information >> available) SHOULD start with bfd.SessionState set to Down and >> bfd.RequiredMinRxInterval _MUST be_ set to zero in the >> MultipointHead session. >> The second paragraph describes manipulation with the value of >> bfd.RequiredMinRxInterval which process, as noted in section >> 4.10, "is outside the scope of this document". That may be >> reason to use SHOULD and not MUST. >> >> Yes, i'd live with that. But then you might also want to clarify in >> 4.4.2. <http://4.4.2.>: >> OLD: >> This variable MUST be set to 0 for session type >> MultipointHead. >> NEW: >> This variable MUST be initialized to 0 for session type >> MultipointHead. >> >> >> >> >> >> >> s/M, P bit/M and P bits/ >> >> GIM>> Thanks, done. >> >> --- >> >> >> >
