Skip to main content

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