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

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

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

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".

(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".

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.

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.

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.

Thanks for addressing my discuss.