Bidirectional Forwarding Detection (BFD) for Multipoint Networks
draft-ietf-bfd-multipoint-19

[Ballot comment]
Thank you for addressing my Discuss points!  The original Comment portion
of my ballot is preserved below for posterity.

I am told that the normal usage of the bare term "BFD" has the connotation
of refering only to usages in an IP/UDP/MPLS encapsulation (exclusing
pseudowires and other more "exotic" encapsulations), so I am not including
this in my DISCUSS section.  However, it seems unusual to limit the scope
of a document in some "random" subsection (here, Section 5.8) with no
mention in the general Introduction or Abstract.  Is there an improvement
to make here?

Section 4

  [...] If no
  BFD Control packets are received by a tail for a detection time, the
  tail declares the path to having failed.  For some applications this
  is the only mechanism necessary; the head can remain ignorant of the
  tails.

It sounds like this might be better said as "the head can remain ignorant
of the status of connectivity to the tails"?  (That is, the head needs to
know at least something about the tails in order to send anything to them,
so it is not fully ignorant.)

  The head of a multipoint BFD session may wish to be alerted to the
  tails' connectivity (or lack thereof).  Details of how the head keeps
  track of tails and how tails alert their connectivity to the head are
  outside scope of this document and are discussed in
  [I-D.ietf-bfd-multipoint-active-tail].

nit: "outside the scope"

Section 5.7

It's a little unclear to me why tails must demultiplex on the identity of the
multipoint path; (that is, why My Discriminator isinsufficient).
Presumably this is just a failing on my end, of course.

  [...] Bootstrapping BFD session to multipoint MPLS LSP in
  case of penultimate hop popping may use control plane, e.g., as
  described in [I-D.ietf-bess-mvpn-fast-failover], and is outside the
  scope of this document.

nit: some articles are missing here; maybe "a BFD session", "in the case
of", and "the control plane".

Section 5.12.2

  MultipointTail sessions MAY be destroyed immediately upon leaving Up
  state, since tail will transmit no packets.

  Otherwise, MultipointTail sessions SHOULD be maintained as long as
  BFD Control packets are being received by it (which by definition
  will indicate that the head is not Up).

Would it be more clear to say "indicate that the head is not Up yet" to
distinguish from the case in the first paragraph (where a non-Up state
*transition*

Section 8

It may be appropriate to make stronger statements about the weakness of MD5
than were valid at the time of 5880's publication.  (SHA1 is also not doing
so great, but I won't block this work on updating the hash function
options.)

It would be good to either refer to the bit about shared keys in Section 6
or just move it to this section entirely.

[Ballot discuss]
This mechanism has the potentially to easily overload the network as there is no handshake and therefore also no feedback mechanism (as already noted by the TSV-ART review of Bob - Thanks!). Regarding the base spec in RFC5880, this mechanism can only be used under certain constrains which should be clearly stated in this doc, which are:

1) See sec 6.8.1 of RFC5880:
"bfd.DesiredMinTxInterval
      [...] The actual
      interval is negotiated between the two systems.  This MUST be
      initialized to a value of at least one second (1,000,000
      microseconds) according to the rules described in section 6.8.3."
As there no negotiation in this spec, bfd.DesiredMinTxInterval MUST always be at least one second. Actually RFC8085 even recommend 3 sec (see sec 3.1.3).

2) See sec 7 of RFC5880
"When BFD is used across multiple hops, a congestion control mechanism
  MUST be implemented, and when congestion is detected, the BFD
  implementation MUST reduce the amount of traffic it generates. "
As there is no feedback and therefore no congestion control, this spec can only be used for one-hop scenarios and the TTL or Hop Count MUST be set to one.

3) Also given the traffic load multipoint BFD generates depends on the number of active session, and there is no feedback mechanism, I recommend to also limit the number of active session of MultipointHead type to a small number (per link).

[Ballot comment]
(1) This document is marked as Updating rfc5880, buy §4.1 (in rfc5880), still has this text:

Multipoint (M)

  This bit is reserved for future point-to-multipoint extensions to
  BFD.  It MUST be zero on both transmit and receipt.

...which should also be addressed in this document.


(2) §5.3. (Session Failure Semantics): "If a MultipointTail session fails...the tail should take appropriate action."  What is an "appropriate action"?  I'm guessing that this has to do with I-D.ietf-bfd-multipoint-active-tail, but that only applies if a return path exists.  In the general case, should the tail take any action?  Please clarify.


(3) §5.7 and §5.13.2 talk about "the identity of the multipoint path" -- what is that?


(4) §5.13.2:

  If a session is not found, a new session of type
  MultipointTail MAY be created, or the packet MAY be
  discarded.  This choice MAY be controlled by the local
  policy, e.g. a maximum number of MultipointTail sessions and
  number of active MultipointTail sessions, and is outside the
  scope of this specification.

I think the last "MAY" above is out of place (s/MAY/may): if local policy doesn't exist, what is the option?  The text says that this topic is outside the scope...but I'm not sure if that means the local policy or the choice itself.  §8 (Security Considerations) offers some more insight...but it doesn't explicitly specify a limit to the number of MultipointTail sessions -- should one exist?

The text above also calls out the "number of active MultipointTail sessions" as if it were something different (from simply the number of MultipointTail sessions), but this difference is not explained or mentioned anywhere else.  Is there a difference?  Is there a need to call this out?


(5) Nit:  Please don't abbreviate to "My Discr" and "Your Discr".

[Ballot comment]
Firstly, thank you for writing this - I've never needed this functionality, but can see where it would be useful.

I fully support Mirja's DISCUSS - there should to be more text not just around congesting links, but also not shooting yourself in the foot with too many / too frequent packets.
Ben's DISCUSS is also needs to be addressed.

Comments:
1: "All other information MAY be determined dynamically."
I don't think that a 2119-style MAY works here - I'd suggest "All other information can be determined dynamically." (or even just a lowercase may)

2: Section 5.7:
"Bootstrapping BFD session to multipoint MPLS LSP in case of penultimate hop popping may use control plane, e.g., as described in [I-D.ietf-bess-mvpn-fast-failover], and is outside the scope of this document."
"may use control plane" doesn't parse for me. Perhaps "may use *the* control plane"? I'm actually not sure what you are trying to say here, so that might not fix it.


I also have some nits:
Section 1:
O:  Term "connectivity" in this document
P: The  term "connectivity" in this document

[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3589


It's not entirely clear to me what the relationship is between this
document and RFC5880. Can you clarify?

How does this handle duplicate/reordered packets? If I am reading RFC
5880 correctly, you only get that if you have authentication?

COMMENTS
S 1.
> 
>      As multipoint transmissions are inherently unidirectional, this
>      mechanism purports only to verify this unidirectional connectivity.
>      Although this seems in conflict with the "Bidirectional" in BFD, the
>      protocol is capable of supporting this use case.  Use of BFD in
>      Demand mode enables a tail monitor availability of a multipoint path

enables a tail monitor -> allows a tail to monitor?

If not, I am confused


S 5.13.1.
>        If the Detect Mult field is zero, the packet MUST be discarded.
> 
>        If the My Discriminator field is zero, the packet MUST be
>        discarded.
> 
>        Demultiplex the packet to a session according to Section 5.13.2

This is a bit confusing because it applies to the section here and not
in 5880.


S 5.13.2.
>              PointToPoint MAY be created, or the packet MAY be discarded.
>              This choice MAY be controlled by a local policy and is
>              outside the scope of this specification.
> 
>            If the State field is Init and bfd.SessionType is not
>            PointToPoint, the packet MUST be discarded.

Is this material just duplicative of 5880?


S 6.
>      from the viewpoint of any other tail.  For this reason, using shared
>      keys to authenticate BFD Control packets in multipoint scenarios is a
>      significant security exposure unless all tails can be trusted not to
>      spoof the head.  Otherwise, asymmetric message authentication would
>      be needed, e.g., protocols that use Timed Efficient Stream Loss-
>      Tolerant Authentication (TESLA) as described in [RFC4082].

As Ben's review implies, digital signatures would be an appropriate
thing to use here.

[Ballot discuss]
This mechanism has the potentially to easily overload the network as there is no handshake and therefore also no feedback mechanism (as already noted by the TSV-ART review of Bob - Thanks!). Regarding the base spec in RFC5880, this mechanism can only be used under certain constrains which should be clearly stated in this doc, which are:

1) See sec 6.8.1 of RFC5880:
"bfd.DesiredMinTxInterval
      [...] The actual
      interval is negotiated between the two systems.  This MUST be
      initialized to a value of at least one second (1,000,000
      microseconds) according to the rules described in section 6.8.3."
As there no negotiation in this spec, bfd.DesiredMinTxInterval MUST always be at least one second. Actually RFC8085 even recommend 3 sec (see sec 3.1.3).

2) See sec 7 of RFC 8085
"When BFD is used across multiple hops, a congestion control mechanism
  MUST be implemented, and when congestion is detected, the BFD
  implementation MUST reduce the amount of traffic it generates. "
As there is no feedback and therefore no congestion control, this spec can only be used for one-hop scenarios and the TTL or Hop Count MUST be set to one.

3) Also given the traffic load multipoint BFD generates depends on the number of active session, and there is no feedback mechanism, I recommend to also limit the number of active session of MultipointHead type to a small number (per link).

[Ballot comment]

The text in §5.1 says that MultipointHead sessions send packets with the M bit
set. It probably bears mention that this is an explicit update to the RFC 5880
requirement that "It MUST be zero on both transmit and receipt."

---------------------------------------------------------------------------

Nit (from id-nits):

  -- The draft header indicates that this document updates RFC5880, but the
    abstract doesn't seem to mention this, which it should.

---------------------------------------------------------------------------

§4:

>  If no
>  BFD Control packets are received by a tail for a detection time, the
>  tail declares the path to having failed.

Nit: "...to have failed."

---------------------------------------------------------------------------

§5.6:

>  A session of type MultipointHead is created for each multipoint path
>  over which the head wishes to run BFD.  This session runs in the
>  Active role , per section 6.1 [RFC5880].  Except when

Nit: extra space before comma

[Ballot comment]
Please mention the fact this updates 5880 in the abstract. Also, in the introduction where you do mention the update, please add a sentence or two that give a satellite view summary of what the update actually is.

[Ballot discuss]
Section 5.13('s subsections) of this document replace sections 6.8.6 and
6.8.7 of RFC 5880.  I extracted the relevant text and performed a diff, and
think some discussion is needed of some portions present in RFC 5880 that
are not present in these new texts.  (The separation of the demultiplexing
procedure to a separate subsection is fine, though it does make the diff a
little nosier to read.)

In particular, from RFC 5880 Section 6.8.6, the paragraph:

%      If the Poll (P) bit is set, send a BFD Control packet to the
%      remote system with the Poll (P) bit clear, and the Final (F) bit
%      set (see section 6.8.7).

Does not appear to have any corresponding text in this document.

From RFC 5880 Section 6.8.7, the first four paragraphs (too long for me to
include here) do not appear to have their substance covered in this
document, either (largely discussion about the pacing of BFD Control
packets and jitter in their scheduling).

Section 5.13.3's text now only covers how to set Min Echo Rx Interval
for MultipointHead and MultiplintTail sessions, which seems to remove
guidance on how to set it for other session types.

While it is permissible for a document that Updates another document to
perform this sort of deprecation of behavior, it is potentially confusing
for implementors to do so without mentioning the change in behavior.


Separately, I wonder if it is appropriate to Update RFC 7880 as well as
5880, given (e.g.) Section 5.4.1.

I also think that Section 6 should describe more clearly how asymmetric
message authentication relates to this work (i.e., whether it is entirely
incompatible with BFD or does it merely require additional specification).

[Ballot comment]
I am told that the normal usage of the bare term "BFD" has the connotation
of refering only to usages in an IP/UDP/MPLS encapsulation (exclusing
pseudowires and other more "exotic" encapsulations), so I am not including
this in my DISCUSS section.  However, it seems unusual to limit the scope
of a document in some "random" subsection (here, Section 5.8) with no
mention in the general Introduction or Abstract.  Is there an improvement
to make here?

Section 4

  [...] If no
  BFD Control packets are received by a tail for a detection time, the
  tail declares the path to having failed.  For some applications this
  is the only mechanism necessary; the head can remain ignorant of the
  tails.

It sounds like this might be better said as "the head can remain ignorant
of the status of connectivity to the tails"?  (That is, the head needs to
know at least something about the tails in order to send anything to them,
so it is not fully ignorant.)

  The head of a multipoint BFD session may wish to be alerted to the
  tails' connectivity (or lack thereof).  Details of how the head keeps
  track of tails and how tails alert their connectivity to the head are
  outside scope of this document and are discussed in
  [I-D.ietf-bfd-multipoint-active-tail].

nit: "outside the scope"

Section 5.7

It's a little unclear to me why tails must demultiplex on the identity of the
multipoint path; (that is, why My Discriminator isinsufficient).
Presumably this is just a failing on my end, of course.

  [...] Bootstrapping BFD session to multipoint MPLS LSP in
  case of penultimate hop popping may use control plane, e.g., as
  described in [I-D.ietf-bess-mvpn-fast-failover], and is outside the
  scope of this document.

nit: some articles are missing here; maybe "a BFD session", "in the case
of", and "the control plane".

Section 5.12.2

  MultipointTail sessions MAY be destroyed immediately upon leaving Up
  state, since tail will transmit no packets.

  Otherwise, MultipointTail sessions SHOULD be maintained as long as
  BFD Control packets are being received by it (which by definition
  will indicate that the head is not Up).

Would it be more clear to say "indicate that the head is not Up yet" to
distinguish from the case in the first paragraph (where a non-Up state
*transition*

Section 8

It may be appropriate to make stronger statements about the weakness of MD5
than were valid at the time of 5880's publication.  (SHA1 is also not doing
so great, but I won't block this work on updating the hash function
options.)

It would be good to either refer to the bit about shared keys in Section 6
or just move it to this section entirely.

[Ballot comment]
This is a very readable document, so thank you for that. One small nit:

In Section 5.6, last sentence of the first paragraph says:

  All other information MAY be  determined dynamically.

This is not correct use of RFC 2119 MAY, because it doesn't look like an implementation choice. I suggest you change it to lowercase "may" or "can".

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-bfd-multipoint-16, 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

The following Last Call announcement was sent out (ends 2018-05-21):

From: The IESG
To: IETF-Announce
CC: Reshad Rahman , rrahman@cisco.com, draft-ietf-bfd-multipoint@ietf.org, rtg-bfd@ietf.org, martin.vigoureux@nokia.com, bfd-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (BFD for Multipoint Networks) to Proposed Standard


The IESG has received a request from the Bidirectional Forwarding Detection
WG (bfd) to consider the following document: - 'BFD for Multipoint Networks'
  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-05-21. 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 extensions to the Bidirectional Forwarding
  Detection (BFD) protocol for its use in multipoint and multicast
  networks.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ballot/


No IPR declarations have been submitted directly on this I-D.

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 …”?