Update on March 5th 2018 for draft-ietf-bfd-multipoint-14: all the comments
have been addressed as discussed on the BFD WG alias.
====================================
draft-ietf-bfd-multipoint-12 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.
: Why is this the proper type of RFC?
It is the right type because there is 1 known implementation and the draft
updates the base BFD protocol RFC5880 and the Seamless-BFD base specification
RFC7880 (both standards track).
: 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 extensions to the Bidirectional Forwarding
Detection (BFD) protocol for its use in multipoint and multicast
networks.
: Working Group Summary
The document was discussed multiple times with participation from multiple
members of the BFD WG. Most of the discussions took place in 2014/2015 when
most of the work occurred, but there have been some recent discussions in
2017/18. The discussions were mostly on the following points: a) Packet
demultiplexing b) What do with the active-tail functionality. This was moved to
draft-ietf-bfd-multipoint-active-tail as per consensus (after many
discussions). c) Security Considerations c) BFD state variables
: Document Quality
The document has been reviewed multiple times on the BFD WG mailing list.
There is 1 known implementation from Alcatel/Nokia.
: 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 has concerns wrt security:
a) We should have the ability, e.g. via configuration, to prevent the number of
MultipointTail sessions from exceeding the number of expected streams.
Otherwise 1 misbehaving head could use up all the MultipointTail session
resources on a tail. b) A misbehaving head which changes My Discriminator for a
MultipointHead session will cause tails to create many MultipointTail sessions
(4.13.2). We should consider adding a check to see if we have a MultipointTail
session based on source address and the identify of the multipoint tree with a
different discriminator?
The other concern is whether we need a IANA registry for bfd.SessionType. This
has been brought up recently.
The shepherd believes that the document is not ready for publication yet (but
close) due to the security concerns above. Also, 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 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?
No.
: (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. However there have
been discussions on having a IANA registry for bfd.SessionType so that we’d
have a central location where all the values are defined. Right now some values
are in RFC7880, some are in this document and some are in
draft-ietf-bfd-multipoint-active-tail.
: (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, packet) 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 4.9 “(…
than it did previously.)”. I have not called out all of them, search for “.)” -
General. s/this protocol/Multipoint BFD/? - General. Use of term tree e.g.
multipoint tree. Should we use path instead? - Abstract. Remove “Comments on
this draft…” - 1 Introduction. “Details of tail notification…”. Add reference
to draft-ietf-bfd-multipoint-active-tail? - 1 Introduction. s/is not being used
in context/is not being used in the context/ - 1 Introduction. Add reference to
[RFC5880] after “… and adds to the base BFD specification.” - 1 Introduction.
Remove “It is the intention of the authors to fold…” - 2 Goals. Not sure about
“multicast or multipoint medium”, maybe “multipoint or multicast path”? - 2
Goals. “… multipoint paths with multiple heads” should that be
“multipoint-to-multipoint”? - 2 Goals. Remove “A final goal is to integrate
multipoint operation…”. If this is still relevant we need clarification on how
this is being done. May need to also explain what is meant by “relatively easy”
- 2 Goals. s/any tails/any tail/ - 2 Goals. s/It is a non-goal/It is not a
goal/? - 3 Overview. s/Details of how head keeps track/Details of how heads
keep track/. Add reference to draft-ietf-bfd-multipoint-active-tail after that
sentence? - 3 Overview. s/Head may wish/A head may wish/ - 3 Overview. s/it’s
connectivity/its connectivity/ - 4.1 Multipoint BFD Control Packets. Add
reference to [RFC5880] after “…via the setting of the M bit.” - 4.2 Session
Model. s/from the head over multicast path/from the head over the multicast
path/. - 4.2 Session Model. MultipointHead and MultipointTail: add reference
for each to section 4.4.1 where they are defined. - 4.4.1 New State Variables.
Already discussed splitting this into new variables and new values. - 4.4.1 New
State Variables. Already discussed taking bfd.SilentTail out of
draft-ietf-bfd-multipoint - 4.4.2 State Variable Initialization and
Maintenance. s/defined in section 6.8.1 of the [RFC5880] needs/defined in
section 6.8.1 of [RFC5880] need/ - 4.5 State Machine. s/Session of
type/Sessions of type/ - 4.5 State Machine. s/and must be ignored/and MUST be
ignored/ - 4.5 State Machine. Should there be a state machine for the head or
is it too simple since no packets are received from tail? e.g. if the
multipoint path goes down does the MultipointHead session go down? - 4.6
Session Establishment. s/Unlike Point-to-point/Unlike point-to-point/ - 4.6
Session Establishment. “Except when terminating BFD service…”, does terminating
mean shutting down (as in admin down)? - 4.6 Session establishment. Active and
passive roles: add reference to the appropriate section of [RFC5880]. - 4.7
Discriminators and Packet Demultiplexing. s/over the MultipointHead session
with/over the Multipoint path va the MultipointHead session with/ - 4.7.
s/PointToPoint/point-to-point/. PointToPoint is to be used only when referring
to bfd.SessionType. - 4.7. s/Bootstrapping BFD session to a multipoint
LSP/Bootstrapping a BFD session to multipoint MPLS LSP/ - 4.8 Packet
consumption on tails. s/for a multicast group/for an IP multicast group/ - 4.8.
s/For multipoint LSP/For multipoint LSPs/ - 4.8. s/encapsulation of BFD control
packet/encapsulation of BFD control packets/ - For IPv4/IPv6 address range, add
reference to [RFC5884]? - 4.8. s/Packet identified as BFD packet/Packets
identified as BFD packets/ - 4.8. s/used,/is used,/ - 4.10 Timer Manipulation.
s/However to indicate change in packet/However to indicate a change in the
packets, / - 4.10. s/MUST send packet with P bit/MUST send packets with P bit/
- 4.10/ s/MultipointHead MAY also/A MultipointHead session MAY also/ - 4.11
Detection times. s/Since the MultipointHead session never receives packets, it
does not/Since MultipointHead sessions never receive packets, they do not/ -
4.11 Detection times. s/the Detection Time/the detection time/ - 4.13 Base
Specification Text Replacement. Clarify here or in the introduction that
processing for point-to-point BFD does NOT change. - 4.13.1. Add reference to
[RFC5880] before mentioning section 6.7, e.g “under of rules of section 6.7 of
[RFC5880]” - 4.13.2 P14. If the State field is Init and bfd.SessionType is not
PointToPoint. Instead of checking “is not PointToPoint” should we check “is
MultipointTail”? Otherwise this has an impact on S-BFD? - 7 Security
Considerations. s/ex:/e.g./ - 7 Security Considerations. Should we add at the
beginning “The same security considerations as those described in [RFC5880]
apply to this document. Additionally …”?