Hi Mirja, thank you for the review and comments. Please find my answers in-line tagged GIM>>.
Regards, Greg On Tue, Jul 3, 2018 at 2:40 PM, Mirja Kühlewind <i...@kuehlewind.net> wrote: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-bfd-multipoint-active-tail-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1) I guess it makes sense to have section 6.2 before 6.1 as > MultipointClient is > discussed in 6.1 but introduced in 6.2 currently. > GIM>> This specification introduces the nex type of BFD session - MultipointClient. The first three references are in section 5 while section 6 defines the new session type in details. Would adding more specifics to the first paragraph of the Introduction section make the flow more logical: This application of BFD is an extension to Multipoint BFD [I-D.ietf-bfd-multipoint], which allows tails to notify the head of the lack of multipoint connectivity. As a further option, heads can request a notification from the tails by means of a polling mechanism. Notification to the head can be enabled for all tails, or for only a subset of the tails. In order to achieve that, among several updates to [I-D.ietf-bfd-multipoint], the new state variables and new values for existing variables, e.g., the new session type MultipointClient, has been added. > > 2) sec 6.8 and 6.10 and later on: s/Required Min Rx > Interval/bfd.RequiredMinRxInterval/ ? > GIM>> These were defined in RFC 5880: - Required Min Rx Interval is the field in BFD Control message - bfd.RequiredMinRxInterval - BFD local variable > 3) sec 6.9: > "The decision as to when to send a multipoint Poll is outside the > scope of this specification. However, it must never be sent more > often than the regular multipoint BFD Control packet." > I think the doc should say more as when to send a poll. Also this should > be an > upper case MUST. However, even sending it as often as the regular packets > would > double the load and is therefore not desirable. I would like to see even > stricter requirements here. > GIM>> Would the following be right use of the RFC 2119: However, it MUST NOT be sent more often than the regular multipoint BFD Control packet. I believe that the text further in the paragraph suggests that because multipoint poll messages are treated as regular BFD Control messages, the former may be sent instead of non-poll: Since the tail will treat a multipoint Poll like any other multipoint BFD Control packet, Polls may be sent in lieu of non-Poll packets. Intelligent implementation, I expect, will follow this note and thus avoid duplication of BFD control packets on the wire. > > 4) In sec 6.10: > "This value can potentially be set much lower than in the multipoint > case, in order to speed up a notification to the head, since the > value will be used only by the single tail. This value (and the lack > of delay) are "sticky", in that once the tail receives it, it will > continue to use it indefinitely. " > Given this value cannot be changed after initial sending, I would like to > see a > minimum value of 1 sec to be specified. > GIM>> The paragraph describes how the value of the Required Min RX Interval field in the unicast Poll takes precedence over the value in the muticast message. Because this value is used to determine the detection time, setting it in the unicast Poll message to the lower value will result in the shorter detection time for the particular tail. But this can be changed to the value calculated based on multicast BFD packet by setting the value of the Required Min RX Interval field in the unicast Poll the same as in the multicast packet. Here's the text from the document: Therefore, if the head no longer wishes to single out the tail, it SHOULD reset the timer to the default by sending a Poll Sequence with the same value of Required Min Rx Interval as is carried in the multipoint packets, or it MAY reset the tail session by sending a Poll Sequence with state AdminDown (after the completion of which the session will come back up). > 5) 6.12: > "If the MultipointHead session is going down (which only happens > administratively), all associated MultipointClient sessions SHOULD be > destroyed as they are superfluous." > Not sure I understand why this requirement is normative. Also how does tail > know that the head was shut down (compared to connectivity is broken)...? > GIM>> I agree that "going down" is confusing. The text should be clear and reference to Down/AdminDown state that the MultipointHead signals in BFD Control packet. Please consider the new text: If the MultipointHead session is in Down/AdminDown state (which only happens administratively), all associated MultipointClient sessions SHOULD be destroyed as they are superfluous.
