Bidirectional Forwarding Detection
draft-katz-ward-bfd-02

Comments from Pekka Savola:

Hi,

(Cc:ing Alex, as he's watching according to the I-D tracker :-)

I got around to reviewing both the Bidirectional Forwarding Documents
(BFD) drafts.  I believe this is important work, and we have already
deployed some software which supports this and intend to test and
enable it soon.

What's the plan for progressing the work?  Individual submissions,
existing WG(s), or starting a new WG?

The drafts state Category as Informational, but I think this
definitely should be Standards Track!

I also note that there is an IPR claim in the document, but the claim
has not been recorded in IETF IPR database (should fix ASAP).  Which
part of the specification(s) does this IPR pertain to?

Ok, down to the comments...

draft-katz-ward-bfd-01.txt:
===========================

==> I personally fail to see a lot of usefulness for the "new
and shiny features", Polling and (especially) Demand mode.  This seems
to add a lot of complexity.  Could you elaborate why these are useful
(apart for dial up/down links which is IMO something that shouldn't be
forced down the throat all the vendors)

==> ToC needed

==> you don't have any references in the document, at least [KEYWORDS] is
used but not added.

  Pure asynchronous mode is advantageous in that it requires half as
  many packets to achieve a particular detection time as does the Echo
  function.  It is also used when the Echo function cannot be supported
  for some reason.

  The Echo function has the advantage of truly testing only the
  forwarding path on the remote system, which may reduce round-trip
  jitter and thus allow more aggressive detection times, as well as
  potentially detecting some classes of failure that might not
  otherwise be detected.

==> It seems that there is a conflict here, "pure asynch .. requires
half as many packets" and "echo function.. may allow more aggressive
detection times".

By definition, with half as many packets, you will always be able to
use more aggressive detection times that with double the number of
packets!

...

      A diagnostic code specifying the local system's reason for the
      last transition of the session from Up to some other state.
      Values are:

        0 -- No Diagnostic
        1 -- Control Detection Time Expired
        2 -- Echo Function Failed
        3 -- Neighbor Signaled Session Down
        4 -- Forwarding Plane Reset
        5 -- Path Down
        6 -- Concatenated Path Down
        7 -- Administratively Down

==> 8-15 are still free, right?
==> should one add "15 -- Other Reason" ?

(This also may need some reorganization, as commented earlier, as
"Echo Function Failed" seems to lose the diagnostics and valueble
information if you're using echo function.)

  Poll (P)

      If set, the transmitting system requesting verification of
      connectivity, or of a parameter change.

==> these flags should also describe the trivial case of flags being
unset.  Applies to many flags.

==> s/requesting/is requesting/?

  Length

      Length of the BFD Control packet, in bytes.

==> Wouldn't it be nicer to use the units of 8 bytes (due to
alignment, and to reduce the number of unnecessary info)?  With the
current Length, using the units of 64 bits would allow one to specify
longer lengths (up to 2040), which might help if you want to, at some
point, send e.g. extra data along with the packets (e.g., to notice if
longer packets fail even if the shorter ones work). 

However, I'm not 100% sure this is needed, as you could accomplish the
same with setting the size of Echo packets, if needed.

...

  If the session goes down, the transmission of Echo packets (if any)
  ceases, and the transmission of Control packets goes back to the slow
  rate.

  Once a session has been declared down, it cannot come back up until
  the remote end first signals that it is down (by setting its outgoing
  I Hear You field to zero), thus implementing a three-way handshake.

==> Doesn't this cause problems if the other end is in Passive
mode?

  Once the remote end echos back the local discriminator, all further

==> s/echos/echoes/

  When a system is using the Echo function, it is advantageous to
  choose a sedate transmission rate for Control packets, since the job
  of detection is being handled by the Echo packets.  This can be

==> s/sedate/slow/ (if you want to use simpler language, doesn't
matter to me :)
==> s/the job of detection/the liveness detection/ (a bit more formal
language :-)

  When a system is said to have "the Echo function active," it refers
  to that system sending BFD Echo packets (and thus implies that the
  session is Up and the other system has signalled its willingness to
  loop back Echo packets.)

==> reword this to be similar as "Demand active", below, like:

  When a system is said to have "the Echo function active," it means
  the system is sending BFD Echo packets, implying that the
  session is Up and the other system has signalled its willingness to
  loop back Echo packets.

...

  If bfd.DetectMult is equal to 1, the interval between transmitted BFD
  Control packets MUST be no more than 90% of the negotiated
  transmission interval, and MUST be no less than 75% of the negotiated
  transmission interval.  This is to ensure that, on the remote system,
  the calculated DetectTime does not pass prior to the receipt of the
  next BFD Control packet.

==> I do not understand why "no less than 75%" rule exists there, this
doesn't seem to have anything to do with the above DetectTime
reasoning? (of course, it might make sense otherwise.)

(1,000,000 microseconds.)  This is intended to ensure that the
  bandwidth consumed by down BFD sessions is negligible, particularly
 
==> s/by down/by downed/ (or BFP sessions that are down)

  system, multiplied by the agreed transmit interval (the greater of
  bfd.RequiredMinRxInterval and the last received Desired Min TX
  Interval.)  The Detect Mult value is (roughly speaking, due to

==> You mix the bfd.XXXX and "spelled out" terms ("Desired Min TX
Interval").  Use just one of them, e.g. by replacing the latter one by
bfd.DesiredMinTxInterval. (The same happens elsewhere as well.)

6.5.5. Detecting Failures with the Echo Function

  When the Echo function is active and a sufficient number of Echo
  packets have not arrived as they should, the session has gone
  down--the local system MUST set bfd.SessionState to Failing,
  bfd.RemoteHeard to zero, and bfd.LocalDiag to 2 (The Echo Function
  Failed.)

==> I do not believe there has been an explicit specification how what
the sufficient number of Echo packets is.  Note that the previous
section used MinTX/MinRX Intervals, and as there is a separate Echo
interval -- so it doesn't apply as is at least.

==> wouldn't it be useful to use the similar diagnostic codes for Echo
failures than control packet failures?  It seems you'll lose
information about the possible causes of the loss of connectivity if
you use Echo function?

6.5.6. Reception of BFD Control Packets

  When a BFD Control packet is received, the following procedure MUST
  be followed, in the order specified:

      If the version number is not correct (0), the packet MUST be
      discarded.

==> What is the proposed backward compatibility mechanism?  Run each
version of BFD on all the links, and try to connect starting from the
highest supported version, etc. ?

      If the version number is not correct (0), the packet MUST be
      discarded.

==> should it be spelled out that s/discard/silently discard/ ?

      If the value of bfd.RemoteDiscr is zero, set it to the value of My
      Discriminator.

      If the Required Min Echo RX Interval field is zero, the
      transmission of Echo packets, if any, MUST cease.

==> please unify the style, as commented previously..

Security Considerations

  When BFD is run over network layer protocols, a significant denial-
  of-service risk is created, as BFD packets may be trivial to spoof.
  When the session is directly connected across a single link, the TTL
  MUST be set to the maximum on transmit, and checked to be equal to
  the maximum value on reception (and the packet dropped if this is not
  the case.)

==> this is fine (though you should spell out that this also applies
to Hop Limit if IPv6 is used)

==> You should clarify what you refer to with the "more difficult" 
BFD.  MPLS network?  Network with tunnels?  A BFD-using protocol which
establishes adjacencies over multiple hops (e.g. IBGP, even though
that's a bad example)?

  If BFD is run across multiple hops, some alternative
  mechanism MUST be used.  One option would be to ensure that the
  network addresses used for BFD are not routable outside of the
  infrastructure in which BFD is running (and assuming there are no
  users connected within that network.) 

==> I strongly object to that proposition.  First, this seems like a
recommendation to use private addresses.  If it's not, you're assuming
that the operators would use specific addresses for these purposes and
block them at the border.  But that would hinder the other uses of the
interface addresses (i.e., it's operationally impossible), and more
importantly, the BFD mechanism has not way to ensure that this
checking has in fact been configured by the operator.

                                                Another option would be to
  filter all packets carrying BFD's UDP ports at the edges of the
  network. 

==> This is bad as well, because it could hinder the transited
traffic.  However, if this was coupled by edge-based access-lists w/
IP addresses and ports, the tradeoffs might be acceptable.  However
this still has a number of problems, as discussed above.

> Still another option would be to use cryptographic methods,
> though this is not likely to allow for very short detection times.

==> Too bad! :-)













draft-katz-ward-bfd-v4v6-1hop-00.txt:
=====================================

==> you should include the support for static routing.  That would
likely be extremely useful (as you can't run an IGP between the
operator and the customer, and the link is very often an Ethernet
variant, which doesn't provide good link state change notifications). 
I've already worked out some details in my head, and this should be
rather simple.

==> You don't discuss the case what happens if you run IS-IS for IPv4
only, and OSPFv3 -- or IS-IS for IPv6 only and OSPFv2 on the same
links, as dual-stack infrastructure. What about OSPFv2+OSPFv3 for that
matter?  These are common deployment scenarios, and we run one of
these as well.  Would you have two sessions between the nodes on each
link (one for each network-layer protocol used) or one?

Abstract

  This document describes the use of the Bidirectional Forwarding
  Detection protocol [BFD] over IPv4 and IPv6 for single IP hops.  It
  further describes the use of BFD with OSPFv2 [OSPFv2], OSPFv3
  [OSPFv3], and ISIS [ISIS].

==> please don't put references in the abstract!

==> btw, use "IS-IS" rather than "ISIS" :-)

1. Introduction

  One very desirable application for BFD is to track IPv4 and IPv6
  connectivity between directly-connected systems.  This could be used
  to supplant the detection mechanisms in ISIS and OSPF, or to monitor
  router-host connectivity, among other applications.

==> note that the BFD document explicitly discusses it as a mechanism
between "forwarding engines", which seems to exlude router-host
connectivity (which could be useful).  Maybe the main BFD document
could use a bit of rewording?

The source address MUST be
  chosen in such a way as to preclude the remote system from generating
  ICMP Redirect messages (in particular, the source address MUST NOT be
  part of the subnet bound to the interface over which the BFD Echo
  packet is being transmitted.)

==> the last sentence is not clear -- does the MUST NOT apply to what
must not be done (i.e., cause the generation of ICMP redirects) or
what must be done? :-).  When you think about it, it's obvious but the
wording is crap :-).

4.1. BFD for IPv4
4.2. BFD for IPv6

==> there seems to be no need to restate the same things twice. 
Combine these in one section, and state the differences where
applicable.

5. TTL Issues

==> with IPv6 this is called Hop Limit.

  On an unnumbered point-to-point link, the source address of a BFD
  Control packet MUST NOT be used to identify the session.  This means
  that the initial BFD packet MUST be accepted with any source address,
  and that subsequent BFD packets MUST be demultiplexed solely by the
  My Discriminator field (as is always the case.)  This allows the
  source address to change if necessary.

==> this has security issues, especially if TTL=255 check was not in
place. Why this is not serious in this specific scenario should be
described in the security considerations.