Bidirectional Forwarding Detection (BFD) Multipoint Active Tails
draft-ietf-bfd-multipoint-active-tail-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-04-01
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-03-18
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-02-25
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2019-02-11
|
10 | (System) | RFC Editor state changed to REF from EDIT |
2018-12-27
|
10 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2018-12-27
|
10 | (System) | RFC Editor state changed to EDIT |
2018-12-27
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-12-27
|
10 | (System) | Announcement was received by RFC Editor |
2018-12-24
|
10 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2018-12-24
|
10 | (System) | IANA Action state changed to In Progress |
2018-12-24
|
10 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-12-24
|
10 | Amy Vezza | IESG has approved the document |
2018-12-24
|
10 | Amy Vezza | Closed "Approve" ballot |
2018-12-22
|
10 | Martin Vigoureux | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2018-12-22
|
10 | Martin Vigoureux | Ballot approval text was generated |
2018-12-05
|
10 | Ben Campbell | [Ballot comment] Thanks for addressing my DISCUSS point. |
2018-12-05
|
10 | Ben Campbell | [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from Discuss |
2018-11-28
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-11-28
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2018-11-28
|
10 | Greg Mirsky | New version available: draft-ietf-bfd-multipoint-active-tail-10.txt |
2018-11-28
|
10 | (System) | New version approved |
2018-11-28
|
10 | (System) | Request for posting confirmation emailed to previous authors: David Ward , Gregory Mirsky , Dave Katz , Juniper Networks |
2018-11-28
|
10 | Greg Mirsky | Uploaded new revision |
2018-07-05
|
09 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-07-05
|
09 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-07-04
|
09 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-07-04
|
09 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-07-04
|
09 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-07-03
|
09 | Eric Rescorla | [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3976 COMMENTS S 5.2.3. > (regardless of the state of the forward unicast path), the … [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3976 COMMENTS S 5.2.3. > (regardless of the state of the forward unicast path), the tail will > detect the failure but the head will remain unaware of this fact. > > The head will detect a BFD session failure to the tail but cannot > make a determination about the state of the tail's multipoint > connectivity. This seems to contradict the paragraph two above "If the multipoint path fails". Or am I misreading? S 5.2.3. > connectivity. > > If the forward unicast path fails but the reverse unicast path stays > up, the head will detect a BFD session failure to the tail if it > happens to send a unicast Poll sequence, but cannot make a > determination about the state of the tail's multipoint connectivity. This doesn't seem right if the multicast path works. S 6.4. > [I-D.ietf-bfd-multipoint], in which BFD Control packets flow only > from the head and no tracking is desired of tail state at the head, > is accomplished by setting bfd.ReportTailDown to 0 in the > MultipointHead session (Section 5.1). > > If the head wishes to know of active the tails, it sends multipoint This is ungrammatical. S 6.5. > 6.5. State Machine > > Though the state transitions for the state machine, as defined in > section 5.5 of [I-D.ietf-bfd-multipoint], for a session type > MultipointHead are only administratively driven, the state machine > for a session of type MultipointClient is same and the diagram is "is the same" |
2018-07-03
|
09 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-07-03
|
09 | Mirja Kühlewind | [Ballot 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. … [Ballot 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. 2) sec 6.8 and 6.10 and later on: s/Required Min Rx Interval/bfd.RequiredMinRxInterval/ ? 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. 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. 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)...? |
2018-07-03
|
09 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-07-03
|
09 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-07-03
|
09 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-07-02
|
09 | Adam Roach | [Ballot comment] I had the same question that Ben poses in his DISCUSS, and support untangling the question before continuing progression of the document. --------------------------------------------------------------------------- … [Ballot comment] I had the same question that Ben poses in his DISCUSS, and support untangling the question before continuing progression of the document. --------------------------------------------------------------------------- I've dug around some of the BFD documents but can't quite figure out how the tail knows which address to use when responding to a multipoint poll query. The reason I went looking is: if the head has some means of indicating to the tails where such responses should be sent, then it has the ability to coordinate a massive DDoS attack on a selected victim address. Is this possible? |
2018-07-02
|
09 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-07-02
|
09 | Ben Campbell | [Ballot discuss] This is a process discuss: If I read things correctly, this draft purports to update an _unpublished_ RFC (i.e., another draft.). If so, … [Ballot discuss] This is a process discuss: If I read things correctly, this draft purports to update an _unpublished_ RFC (i.e., another draft.). If so, can't we just correct that draft before publishing it? |
2018-07-02
|
09 | Ben Campbell | [Ballot comment] Assuming this progresses mostly as-is, please mention the update in the abstract, and put a sentence or two in the introduction to give … [Ballot comment] Assuming this progresses mostly as-is, please mention the update in the abstract, and put a sentence or two in the introduction to give a high level summary of what the update actually is. |
2018-07-02
|
09 | Ben Campbell | [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell |
2018-07-02
|
09 | Benjamin Kaduk | [Ballot comment] Thanks for the clear explanations throughout; they made this document pretty easy to read. When the head sends both a multipoint poll and … [Ballot comment] Thanks for the clear explanations throughout; they made this document pretty easy to read. When the head sends both a multipoint poll and a unicast poll, does the MultipointClient session have a way to tell whether a received reply is replying to the multipoint message or the unicast one? For variables that "MUST be initialized based on configuration", do we need to provide a default value? Section 4 A head may wish to be alerted to the tails' connectivity (or lack thereof), there are a number of options. This is a comma splice and should be reworded. Section 5.1 [...] This mode emulates the behavior described in [I-D.ietf-bfd-multipoint]. In this mode for bfd.SessionType is MultipointTail, variable bfd.SilentTail (see Section 6.3.1) MUST be set to 1. nit: I think the "for" is spurious (and could maybe even be replaced by a comma)? The existing comma could be replaced by a semicolon or "and" to avoid a comma splice. Section 5.2 o if bfd.SessionType is MultipointTail, variable bfd.SilentTail (see Section 6.3.1) MUST be set to 0; nit: "the variable" Section 6.3.1 Few state variables are added in support of Multipoint BFD active tail. nit: "A few" bfd.UnicastRcvd Set to 1 if a tail receives a unicast BFD Control packet from the head. This variable MUST be set to zero if the session transitions from Up state to some other state. Is there ambiguity about "the session" being MultipointHead/MultipointTail vs. MultipointClient/MultipointTail (i.e., multipoint or unicast)? Section 6.4 If the head wishes to request a notification from the tails when they lose connectivity, it sets bfd.ReportTailDown to 1 in either the MultipointHead session (if such notification is desired from all tails) or in the MultipointClient session (if notification is desired from a particular tail). Note that the setting of this variable in a MultipointClient session for a particular tail overrides the setting in the MultipointHead session. It seems like this property (MultipointClient overrides MultipointHead) is fairly general and would apply to other variables as well. Should it be stated in a more general location? Section 6.7 When the tails send BFD Control packets to the head from the MultipointTail session, the contents of Your Discr (the discriminator received from the head) will not be sufficient for the head to demultiplex the packet, since the same value will be received from all tails on the multicast tree. In this case, the head MUST demultiplex packets based on the source address and the value of Your Discr, which together uniquely identify the tail and the multipoint path. I just want to double-check my understanding: is My Discr used at all for BFD Control messages from the tail to the head? Section 6.8 The value of Required Min Rx Interval received by a tail in a unicast BFD Control packet, if any, always takes precedence over the value received in Multipoint BFD Control packets. Do we need to scope this down to the "associated" sessions? (If so, probably someone should review the whole draft with an eye for it, as I have not done so.) Section 6.9, 6.10 In "If the head wishes to [...] session MAY send [...]", the 2119 MAY does not seem especially appropriate? Section 6.13.1 [...] In addition to that, if tail tracking is desired by the head, below procedure MUST be applied. nit: "the following procedure" Section 6.13.2 Do we need to say if this "addition" happens at the beginning or end of the bfd-multipoint procedure, or is it supposed to replace part of it, or what? Section 6.13.3 If bfd.SessionType value is MultipointTail and periodic the transmission of BFD Control packets is just starting (due to Demand mode not being active on the remote system), the first packet to be transmitted MUST be delayed by a random amount of time between zero and (0.9 * bfd.RemoteMinRxInterval). Should "periodic the" be "the periodic"? Also, this seems like a situation where cryptographic randomness is not required; it may be appropriate to note this. [...] A system MAY limit the rate at which such packets are transmitted. If rate limiting is in effect, the advertised value of Desired Min TX Interval MUST be greater than or equal to the interval between transmitted packets imposed by the rate limiting function. How does this MUST get enforced? Is it a matter of a software implementation refusing to allow local configuration to effect such behavior, or is it a global property of the system (e.g., that would require the administrator to enforce the MUST)? Contents of transmitted packet MUST be as explained in section 5.13.3 of [I-D.ietf-bfd-multipoint]. nit: There's a singular/plural mismatch here between "Contents" (plural) and "transmitted packet" (singular). Section 9 "infinite" is, well, infinite. Implementations that create MultipointClient sessions on demand need to have more reasonable expectations on prevention (the listed points do a better job than this text would indicate). As the rtgdir early review, the risk of spoofed packets causing tail-->MultpointClient traffic (including creation of MultipointClient sessions based on the received traffic) should probably be called out more directly. It seems like an attacker that can insert spoofed multipoint traffic would be able to effect some level of traffic amplification over time, though the jitter makes it harder to create large spikes. (Even on-path attacks are still worth documenting, IMO.) I see there was some conversation about the other security related points raised by that review, but on a quick read it seemed like maybe there was still some room to add more text to the security considerations. |
2018-07-02
|
09 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2018-07-01
|
09 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-06-30
|
09 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-06-28
|
09 | Linda Dunbar | Request for Last Call review by GENART Completed: Ready. Reviewer: Linda Dunbar. Sent review to list. |
2018-06-19
|
09 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2018-06-19
|
09 | Amy Vezza | Placed on agenda for telechat - 2018-07-05 |
2018-06-19
|
09 | Martin Vigoureux | Ballot has been issued |
2018-06-19
|
09 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2018-06-19
|
09 | Martin Vigoureux | Created "Approve" ballot |
2018-06-19
|
09 | Martin Vigoureux | Ballot writeup was changed |
2018-06-19
|
09 | Martin Vigoureux | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-06-18
|
09 | Min Ye | Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Stig Venaas. |
2018-06-18
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2018-06-18
|
09 | Greg Mirsky | New version available: draft-ietf-bfd-multipoint-active-tail-09.txt |
2018-06-18
|
09 | (System) | New version approved |
2018-06-18
|
09 | (System) | Request for posting confirmation emailed to previous authors: David Ward , Gregory Mirsky , Dave Katz , Juniper Networks |
2018-06-18
|
09 | Greg Mirsky | Uploaded new revision |
2018-06-18
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-06-14
|
08 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2018-06-14
|
08 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-bfd-multipoint-active-tail-08, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-bfd-multipoint-active-tail-08, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-06-11
|
08 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Stig Venaas |
2018-06-11
|
08 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Stig Venaas |
2018-06-11
|
08 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Harish Sitaraman |
2018-06-11
|
08 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Harish Sitaraman |
2018-06-07
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Linda Dunbar |
2018-06-07
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Linda Dunbar |
2018-06-07
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to John Bradley |
2018-06-07
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to John Bradley |
2018-06-05
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tina Tsou |
2018-06-05
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tina Tsou |
2018-06-05
|
08 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Michael Richardson |
2018-06-05
|
08 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Michael Richardson |
2018-06-04
|
08 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2018-06-04
|
08 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-06-18): From: The IESG To: IETF-Announce CC: Reshad Rahman , rrahman@cisco.com, rtg-bfd@ietf.org, draft-ietf-bfd-multipoint-active-tail@ietf.org, … The following Last Call announcement was sent out (ends 2018-06-18): From: The IESG To: IETF-Announce CC: Reshad Rahman , rrahman@cisco.com, rtg-bfd@ietf.org, draft-ietf-bfd-multipoint-active-tail@ietf.org, martin.vigoureux@nokia.com, bfd-chairs@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (BFD Multipoint Active Tails.) to Proposed Standard The IESG has received a request from the Bidirectional Forwarding Detection WG (bfd) to consider the following document: - 'BFD Multipoint Active Tails.' as 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@ietf.org mailing lists by 2018-06-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes active tail extensions to and updates the Bidirectional Forwarding Detection (BFD) protocol for multipoint networks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-06-04
|
08 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2018-06-04
|
08 | Martin Vigoureux | Requested Early review by RTGDIR |
2018-06-04
|
08 | Martin Vigoureux | Last call was requested |
2018-06-04
|
08 | Martin Vigoureux | Ballot approval text was generated |
2018-06-04
|
08 | Martin Vigoureux | Ballot writeup was generated |
2018-06-04
|
08 | Martin Vigoureux | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2018-06-04
|
08 | Martin Vigoureux | Last call announcement was generated |
2018-06-04
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-06-04
|
08 | Greg Mirsky | New version available: draft-ietf-bfd-multipoint-active-tail-08.txt |
2018-06-04
|
08 | (System) | New version approved |
2018-06-04
|
08 | (System) | Request for posting confirmation emailed to previous authors: David Ward , Gregory Mirsky , Dave Katz , Juniper Networks |
2018-06-04
|
08 | Greg Mirsky | Uploaded new revision |
2018-05-18
|
07 | Martin Vigoureux | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-05-07
|
07 | Martin Vigoureux | IESG state changed to AD Evaluation from Publication Requested |
2018-03-21
|
07 | Amy Vezza | Shepherding AD changed to Martin Vigoureux |
2018-03-06
|
07 | Jeffrey Haas | Update on March 5th 2018 for draft-ietf-bfd-multipoint-active-tail-07: all the comments have been addressed as discussed on the BFD WG alias. ==================================== draft-ietf-bfd-multipoint-active-tail-06 shepherd write-up. … Update on March 5th 2018 for draft-ietf-bfd-multipoint-active-tail-07: all the comments have been addressed as discussed on the BFD WG alias. ==================================== draft-ietf-bfd-multipoint-active-tail-06 shepherd write-up. : As required by RFC 4858, this is the current template for the Document : Shepherd Write-Up. : : Changes are expected over time. This version is dated 24 February 2012. : : (1) What type of RFC is being requested (BCP, Proposed Standard, : Internet Standard, Informational, Experimental, or Historic)? Standards Track as indicated in title pager header. : Why is this the proper type of RFC? It is a normative reference in draft-ietf-trill-p2mp-bfd : Is this type of RFC indicated in the title page header? Yes : (2) The IESG approval announcement includes a Document Announcement : Write-Up. Please provide such a Document Announcement Write-Up. Recent : examples can be found in the "Action" announcements for approved : documents. The approval announcement contains the following sections: : Technical Summary This document describes active tail extensions to the Bidirectional Forwarding Detection (BFD) protocol for multipoint and multicast networks. : Working Group Summary The document was discussed multiple times with participation from multiple members of the BFD WG. The discussions on whether a separate draft (v/s move to appendix) was needed for active-tail went on for a while but consensus was reached. Most of the technical discussions took place in 2014/2015 when the active-tail functionality was still part of the multipoint draft (i.e. before the split). The technical discussions were mostly on the notification mechanisms to the head, whether they are all needed and how the operate. : Document Quality The document has been reviewed multiple times on the BFD WG mailing list. There is no known implementation of this draft. Huawei may implement draft-ietf-trill-p2mp-bfd (https://datatracker.ietf.org/doc/draft-ietf-trill-p2mp-bfd/shepherdwriteup/), if they do they will need to also implement this draft. : Personnel : : Who is the Document Shepherd? Reshad Rahman is the document shepherd, BFD WG co-chair. : Who is the Responsible Area Director? Alvaro Retana is the responsible AD. : (3) Briefly describe the review of this document that was performed by : the Document Shepherd. If this version of the document is not ready : for publication, please explain why the document is being forwarded to : the IESG. The shepherd has gone though all the email discussions on the BFD WG mail archive and has verified that the issues raised have been addressed appropriately from a technical view. The document will need a new version before being forwarded to the IESG. : (4) Does the document Shepherd have any concerns about the depth or : breadth of the reviews that have been performed? None. : (5) Do portions of the document need review from a particular or from : broader perspective, e.g., security, operational complexity, AAA, DNS, : DHCP, XML, or internationalization? If so, describe the review that : took place. No. : (6) Describe any specific concerns or issues that the Document Shepherd : has with this document that the Responsible Area Director and/or the : IESG should be aware of? For example, perhaps he or she is uncomfortable : with certain parts of the document, or has concerns whether there really : is a need for it. In any event, if the WG has discussed those issues and : has indicated that it still wishes to advance the document, detail those : concerns here. The shepherd believes that the document is not ready for publication yet (but close), there are a few nits to be fixed (see below). : (7) Has each author confirmed that any and all appropriate IPR : disclosures required for full conformance with the provisions of BCP 78 : and BCP 79 have already been filed. If not, explain why. Waiting for response from some authors. : (8) Has an IPR disclosure been filed that references this document? : If so, summarize any WG discussion and conclusion regarding the IPR : disclosures. Waiting for response from some authors. : (9) How solid is the WG consensus behind this document? Does it : represent the strong concurrence of a few individuals, with others : being silent, or does the WG as a whole understand and agree with it? Consensus is very solid. : (10) Has anyone threatened an appeal or otherwise indicated extreme : discontent? If so, please summarise the areas of conflict in separate : email messages to the Responsible Area Director. (It should be in a : separate email because this questionnaire is publicly available.) No. : (11) Identify any ID nits the Document Shepherd has found in this : document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts : Checklist). Boilerplate checks are not enough; this check needs to be : thorough. 1 warning about a later version (-12) exists of draft-ietf-bfd-multipoint-11 1 comment about the document date being 30 days in the past. : (12) Describe how the document meets any required formal review : criteria, such as the MIB Doctor, media type, and URI type reviews. N/A : (13) Have all references within this document been identified as : either normative or informative? Yes : (14) Are there normative references to documents that are not ready for : advancement or are otherwise in an unclear state? If such normative : references exist, what is the plan for their completion? None. : (15) Are there downward normative references references (see RFC 3967)? : If so, list these downward references to support the Area Director in : the Last Call procedure. None. :(16) Will publication of this document change the status of any : existing RFCs? Are those RFCs listed on the title page header, listed : in the abstract, and discussed in the introduction? If the RFCs are not : listed in the Abstract and Introduction, explain why, and point to the : part of the document where the relationship of this document to the : other RFCs is discussed. If this information is not in the document, : explain why the WG considers it unnecessary. This document will update RFCs 5880 and 7880. They are not in the title page header. : (17) Describe the Document Shepherd's review of the IANA considerations : section, especially with regard to its consistency with the body of the : document. Confirm that all protocol extensions that the document makes : are associated with the appropriate reservations in IANA registries. : Confirm that any referenced IANA registries have been clearly : identified. Confirm that newly created IANA registries include a : detailed specification of the initial contents for the registry, that : allocations procedures for future registrations are defined, and a : reasonable name for the new registry has been suggested (see RFC 5226). There are no protocol extensions which require a registry. : (18) List any new IANA registries that require Expert Review for future : allocations. Provide any public guidance that the IESG would find : useful in selecting the IANA Experts for these new registries. None. : (19) Describe reviews and automated checks performed by the Document : Shepherd to validate sections of the document written in a formal : language, such as XML code, BNF rules, MIB definitions, etc. None. NITS ==== - General. There are a few instances where singular is used instead of plural (e.g. for session, tail) and also where “a” or “the” is missing. I have tried to indicate all such occurrences below. - General. A few sentences have the period ‘.’ before the closing parenthesis instead of after, e.g. in Introduction “path as is feasible.)”. I have not called out all of them, search for “.)” - 1 Introduction. s/which allows tail/which allows tails/ - 1 Introduction. Clarifications/explanations are desirable on “it is preferable if unicast paths share as little fate with the multipoint path as is feasible.)” - 1 Introduction. s/Goal of this application/The goal of this application/ - 1 Introduction mentions “…state implosion towards the head”. Not sure implosion is the right term there, if it is the right term then clarification is needed. - 2 Overview. Change “Head may wish” to “A head may wish” or “Heads may wish” - 2 Overview. “…the head can direct the tails to transmit…”: add reference or explanation on how the head does that. Also s/direct/request/? - 2 Overview. 1st paragraph, I know it’s obvious when you read the draft but might be good to have 1 sentence to explain why this is unreliable. - 2 Overview. 3rd paragraph: s/as a unicast to the tail/as a unicast to that tail/? - 2 Overview. 3rd paragraph: “or the single reply thereto is lost”, rephrase that sentence e.g. to “or the single reply os also lost”? - 2 Overview. “If some tails are more equal than others…”. I know what you mean but plus change the wording. - 3 Protocol Details. s/This section is update/This section is an update/ - 3.2 Multipoint Client Session Failure. s/know the tail state/know the tail’s state/ - 3.3 State Variables. As discussed, bfd.SessionType should be in “new variable values” section and the others in “new variables” section. - 3.3.1 New State Variables. The paragraph on bfd.ReportTailDown says “If 0, the tail..”. Mention that the packets sent from the tail are in response to the head’s periodic BFD control packets? Also when set to 1, how do the tails know from the head that they need to notify the head? This paragraph needs some clarification. 3.3.2 State Variable Initialization and Maintenance. s/section 6.8.1 of the [RFC5880] needs/section 6.8.1 of [RFC5880] need/ - 3.4 Controlling Multipoint BFD Options. 2nd paragraph: add reference to section 5.1? - 3.4. 3rd paragraph : add reference to section 5.3? Also do we need a state variable which controls this behaviour (discovering tails)? - 3.4. Paragraph 5 should be after paragraph 3? - 3.4. Paragraph 6, regarding “initial delay”, add a reference to 3.13.3 which describes the delay. - 3.5 State Machine. s/State machine for/The state machine for/ - 3.8 Soliciting the Tails. “random delay”, add a reference to 3.13.3 which describes the delay. - 3.13. “in the base specification” refers to base BFD or base BFD multipoint? Add a reference. - 3.13.1. Should reception at head also be covered here? If not, add “at tail” to the title - 3.13.1. s/by head below procedure MUST be/by the head, the procedure below MUST be/ - 3.13.1 and 3.13.2. Both are adding to the procedures in draft-ietf-bfd-multipoint, specify where the addition is taking place (e.g. at the end). - 7 Security Considerations. Should we add at the beginning “The same security considerations as those described in [RFC5880] and [I-D.ietf-bfd-multipoint] apply to this document.”? |
2018-03-06
|
07 | Jeffrey Haas | Responsible AD changed to Alvaro Retana |
2018-03-06
|
07 | Jeffrey Haas | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-03-06
|
07 | Jeffrey Haas | IESG state changed to Publication Requested |
2018-03-06
|
07 | Jeffrey Haas | IESG process started in state Publication Requested |
2018-03-06
|
07 | Jeffrey Haas | Changed consensus to Yes from Unknown |
2018-03-06
|
07 | Jeffrey Haas | Intended Status changed to Proposed Standard from None |
2018-03-05
|
07 | Reshad Rahman | Changed document writeup |
2018-02-21
|
07 | Greg Mirsky | New version available: draft-ietf-bfd-multipoint-active-tail-07.txt |
2018-02-21
|
07 | (System) | New version approved |
2018-02-21
|
07 | (System) | Request for posting confirmation emailed to previous authors: David Ward , Gregory Mirsky , Dave Katz , Juniper Networks |
2018-02-21
|
07 | Greg Mirsky | Uploaded new revision |
2018-01-18
|
06 | Reshad Rahman | Changed document writeup |
2018-01-03
|
06 | Jeffrey Haas | Awaiting final resolution regarding a registry for the BFD session types. |
2018-01-03
|
06 | Jeffrey Haas | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2017-12-21
|
06 | Greg Mirsky | New version available: draft-ietf-bfd-multipoint-active-tail-06.txt |
2017-12-21
|
06 | (System) | Posted submission manually |
2017-12-19
|
05 | Jeffrey Haas | Notification list changed to Reshad Rahman <rrahman@cisco.com> |
2017-12-19
|
05 | Jeffrey Haas | Document shepherd changed to Reshad Rahman |
2017-12-11
|
05 | Santosh Pallagatti | New version available: draft-ietf-bfd-multipoint-active-tail-05.txt |
2017-12-11
|
05 | (System) | New version approved |
2017-12-11
|
05 | (System) | Request for posting confirmation emailed to previous authors: David Ward , Dave Katz , Juniper Networks |
2017-12-11
|
05 | Santosh Pallagatti | Uploaded new revision |
2017-10-27
|
04 | (System) | Document has expired |
2017-06-19
|
04 | Jeffrey Haas | IETF WG state changed to In WG Last Call from WG Document |
2017-04-25
|
04 | Santosh Pallagatti | New version available: draft-ietf-bfd-multipoint-active-tail-04.txt |
2017-04-25
|
04 | (System) | New version approved |
2017-04-25
|
04 | (System) | Request for posting confirmation emailed to previous authors: David Ward , Dave Katz , Juniper Networks , bfd-chairs@ietf.org |
2017-04-25
|
04 | Santosh Pallagatti | Uploaded new revision |
2017-04-16
|
03 | (System) | Document has expired |
2016-10-13
|
03 | Santosh Pallagatti | New version available: draft-ietf-bfd-multipoint-active-tail-03.txt |
2016-10-13
|
03 | (System) | New version approved |
2016-10-13
|
02 | (System) | Request for posting confirmation emailed to previous authors: "David Ward" , "Juniper Networks" , "Dave Katz" , bfd-chairs@ietf.org |
2016-10-13
|
02 | Santosh Pallagatti | Uploaded new revision |
2016-05-23
|
02 | Santosh Pallagatti | New version available: draft-ietf-bfd-multipoint-active-tail-02.txt |
2015-11-17
|
01 | Santosh Pallagatti | New version available: draft-ietf-bfd-multipoint-active-tail-01.txt |
2015-06-15
|
00 | Jeffrey Haas | This document now replaces draft-spallagatti-bfd-multipoint-active-tail instead of None |
2015-05-06
|
00 | Santosh Pallagatti | New version available: draft-ietf-bfd-multipoint-active-tail-00.txt |