Subject: Re: Comments on the BFD drafts

From: Alex Zinin <[email-masked]>
Date: Tue, 20 Jan 2004 15:41:09 -0800

Thanks Pekka!

  CC'ing [email-masked] for archival purposes. I will also put
  them in the tracker.

  Dave's, could you guys please put a line in the abstract of
  all BFD-related docs asking to send comments to the above address?

  Peka, some answers inline below, leaving the rest to the authors.

Saturday, January 10, 2004, 11:42:12 AM, Pekka Savola wrote:
> 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 option of a separate WG has been discussed. At this point we don't
see nearly enough activity on the mailing list to warrant one. The
work will most likely progress as individual.

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

Agreed,

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

Yes, this should be fixed. Dave's, please ask your companies to submit
statements to the IETF secretariat.

Thanks.

Alex

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

---

From: Dave Katz <[email-masked]>
Date: Wed, 21 Jan 2004 02:27:11 -0700

First, thanks for doing such a thorough review.  We haven't had very 
many of those.

> definitely should be Standards Track!

If we can find a way to progress the work without it being bogged down 
forever, and without it becoming watered down by the legions of folks 
that would like to change it, I don't have any objection.  My 
experience over the years does not give me a lot of hope.  I'm leaving 
the sociopolitical aspects to dward (I quit going to the IETF some time 
ago, too many years of committees...)

> part of the specification(s) does this IPR pertain to?

I'll get this straightened out soon.  I would expect cheap and 
nondiscriminatory licensing, since the authors really would like 
everyone to play.

> ==> I personally fail to see a lot of usefulness for the "new

Polling is necessary for correctness when the time constants are being 
changed (in particular, when one end decides to start transmitting less 
often than it had been previously.)  Think about what would happen 
otherwise if the round trip time was greater than the detection time.

Demand mode is useful if you're using Echo mode in both directions, but 
its primary purpose is to address the needs of mass fan-in devices.  In 
particular, the IPSec folks had their own liveness proposal on the 
table that was particular to IPSec, and which included this feature (as 
apparently there are large fan-in IPSec gateways) and so this feature 
is included in order to attempt to avoid Yet Another Hello Protocol for 
IPSec.  Note that the implementation of Demand mode is not mandatory;  
you simply never advertise the D bit and the other side cannot tell 
whether you don't have the code or you simply don't feel like doing it 
for some reason.  This may limit the places a particular implementation 
can be used, but that's just product differentiation.  I'm not sure 
what you're referring to about forcing anything down anybody's throat...

> ==> ToC needed

Noted.

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

Not sure what we should be referencing;  suggestions are welcome.

> ==> It seems that there is a conflict here, "pure asynch .. requires

Apples and oranges.  Pure async requires half the packets as 
(symmetric) echo mode for the same detection time.  The point about 
echo mode is that, because it may decrease jitter, more aggressive 
packet rates could be used without falsely declaring a link failure.  
It is certainly *not* the case "by definition" that you will "always" 
be able to be more aggressive, because the two operational modes may be 
very different in their processing.

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

Yes, they're still free;  however I don't see any semantic distinction 
between "No Diagnostic" and "Other Reason";  either way the session 
went down, so there's definitely some reason that is not in the list of 
well defined reasons.

> information if you're using echo function.)

The intent is that "Echo Function Failed" is equivalent to "Control 
Detection Time Expired" so the semantic content should be the same.

> ==> these flags should also describe the trivial case of flags being

Fair enough.

>
> ==> s/requesting/is requesting/?

Yep.

> ==> Wouldn't it be nicer to use the units of 8 bytes (due to

This was purposeful;  one of the goals of the protocol is to keep the 
packets short and simple.  We're resisting efforts to add extra stuff, 
the urge for which seems to be almost universal.

In any case, trying to detect packet length-dependent problems in a 
link is not a goal (and there are fewer and fewer media that even have 
this characteristic.)  We're trying to keep this protocol universal and 
media-type independent.

If it ever really has to get longer, we can always bump the version 
number.

> same with setting the size of Echo packets, if needed.

True, if Echo packets are supported and sensible in the application 
(LAN switches are very careful *not* to echo packets, so you can't use 
Echo mode in that case.)

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

No, because the remote discriminator is not cleared, only the H bit.  
The Passive role is specifically to deal with the case where there may 
be multiple sessions and the remote discriminator isn't yet known (so 
the incoming packets can't be demuxed to the right session.)

> ==> s/echos/echoes/

Thanks.

> ==> s/sedate/slow/ (if you want to use simpler language, doesn't
> matter to me :)

I rather like "sedate" as it has broader connotations (relaxed, 
unhurried.)

> ==> s/the job of detection/the liveness detection/ (a bit more formal
> language :-)

Fair enough.

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

OK.

> ==> I do not understand why "no less than 75%" rule exists there, this

This is the 25% jitter;  normal packets must be sent at no more than 
100% nor less than 75% of the negotiated interval.

> ==> s/by down/by downed/ (or BFP sessions that are down)

OK.

> ==> You mix the bfd.XXXX and "spelled out" terms ("Desired Min TX

No, these are not the same things.  The bfd.XXX references refer to the 
contents of the state block.  The "spelled out" terms refer to the 
fields in a received packet, which may or may not have been copied into 
the state block.

> ==> I do not believe there has been an explicit specification how what

No, there is very specifically *no* specification as to how the Echo 
function works, as this is a purely local matter.  The system may count 
packets, it might track time, it might look at sequence numbers, or 
anything else that might be dreamt up by an implementor.

>
> ==> wouldn't it be useful to use the similar diagnostic codes for Echo

There is only one diagnostic code that denotes the fact that control 
packets stopped coming, so the Echo function is the same in this 
respect.  The other diagnostics are either informational about the 
sending system, or are part of the BFD state machine and are invariant 
with respect to the use or non-use of Echo.  (For instance, if one 
system detects a failure by the lack of either type of packet and tears 
down the session, the other system will respond with "Neighbor Signaled 
Session Down."

> ==> What is the proposed backward compatibility mechanism?  Run each

It's outside of the scope of this spec.  If we ever end up bumping the 
version number, we could include verbiage in that document that spells 
it out, but the only real correctness issue is to make sure that you 
don't end up running two sessions (one per version) that represents the 
same link.  There would be no requirement for backward compatibility 
(though it certainly would not be precluded) as supporting multiple 
versions is a vendor choice.  If the previous version has a large 
deployed base, it would be in a vendor's best interest to do so, but I 
am generally against requiring anything in a protocol unless it is 
*really* necessary.  (My experience is that, counterintuitively, more 
MUSTs make interoperability harder.)

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

As opposed to what?  There is no mechanism in the protocol for 
announcing this event to the world, and an implementation may indeed 
want to complain loudly to network management or something.

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

I'll try.

> ==> this is fine (though you should spell out that this also applies

Fair enough.

>
> ==> You should clarify what you refer to with the "more difficult"

I'm not sure what you're referring to here.  If you are referring to 
the conditions for which the TTL hack won't work, it's the converse of 
the case where it does work--anything where BFD traverses more than a 
single network layer hop.

> ==> I strongly object to that proposition.  First, this seems like a

There is nothing to stop an operator from assigning both public and 
private addresses to interfaces and only accepting BFD packets 
addressed to the private address space, for instance.  In any case, 
this language is not normative; it's just attempting to list 
alternatives other than cryptographic methods.  However, if an operator 
really wanted to use private addressing internally to their network, 
they're free to do so.

Furthermore, it is not possible in any protocol to guarantee that the 
operator hasn't misconfigured their network.  Guarantees of operational 
correctness are *way* outside the scope of the specification.

> ==> This is bad as well, because it could hinder the transited

See above.  These are viable choices (from the perspective of BFD 
security) if someone wishes to use them.  If using them would hose 
their networks in some other way, then perhaps the operators might not 
want to use them.  There's plenty of this sort of thing happening now 
in brute-force attempts to deal with viruses, for instance.  (Having 
said all that, I agree that this probably isn't the best way to attack 
the problem, and is unnecessary if operators are vigilant about edge 
filtering for packets destined to internal addresses, which they really 
ought to be already or they're in a whole lot of danger.)

> ==> Too bad! :-)

Yeah, this gets at the heart of the problem, at least until crypto 
stuff gets cheap enough and fast enough to put in simple hardware.  At 
this point, there is a tension between fast detection and crypto, at 
least for boxes cheaper than ours.  ;-)

> ==> you should include the support for static routing.  That would

Yep, there's a lot of call for this, I'll add something, though it will 
require some careful wordsmithing to get across the point without 
referring to specific system implementations.  Keep in mind that this 
is not really subject to standardization, since it's purely an internal 
matter.

>
> ==> You don't discuss the case what happens if you run IS-IS for IPv4

The base spec is clear (or it should be) that there is one session per 
data protocol at the layer at which it is running (so in the network 
layer case, one for v4 and one for v6.)  A little bit of language in 
this spec should make that clearer.

There should be a bit of language saying that the interaction between 
BFD and adjacencies should be based on the data protocol (so a v4 BFD 
failure should shoot down OSPFv2 and ISIS-for-v4 adjacencies, etc.)  If 
I recall the v6 extensions for ISIS (I implemented them, but it's been 
a long time) we'll have to do a bit more weasel wording, to the effect 
that if, say a v4 BFD session fails, the routing protocol shouldn't 
advertise adjacency for that data protocol.  This should hold for v4 in 
OSPFv3, if anybody ever bothers to do that.

We also need language talking about the interaction with graceless 
restart in both protocols.

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

OK.

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

At least I didn't say "Intermediate System to Intermediate System 
Intradomain Routeing Protocol."

> ==> note that the BFD document explicitly discusses it as a mechanism

Yeah, a few more weasel words would help.

> ==> the last sentence is not clear -- does the MUST NOT apply to what

I think the wording is unambiguous, given the parentheses.  You're more 
than welcome to suggest alternative text, however.  "Crap," hrmph.  I 
like to think of the words as "pearls."  ;-)

>
> 4.1. BFD for IPv4
> 4.2. BFD for IPv6
>
> ==> there seems to be no need to restate the same things twice.

I get paid by the word.  ;-)

I don't think it would make it any clearer to combine them.

>
> 5. TTL Issues
>
> ==> with IPv6 this is called Hop Limit.

Thanks.  I guess they didn't subscribe to the IETF tradition of 
preserving our investment in terminology.  ;-)

> ==> this has security issues, especially if TTL=255 check was not in

There are no additional security issues caused by this, since the 
source address can be spoofed if you can just get the packet there.  
Since this document is for the single hop case (and explicitly calls 
out the TTL hack), what happens in the multihop case is not relevant 
here.

Thanks again for your extensive comments and thorough reading.

--Dave

---

From: Pekka Savola <[email-masked]>
Date: Wed, 21 Jan 2004 23:08:45 +0200 (EET)

Hi,

Responses inline.

> ago, too many years of committees...)

I don't think there is a significant difference of the pass-through 
time whether it's Standards Track or Informational.  It *is* still 
possible to push through standards track documents in 6 months :-).

The kitchen sink effect should be avoided, of course.  However, it 
takes some insight to see the "required changes" from "non-essential 
extensions".

> nondiscriminatory licensing, since the authors really would like 

I'd like RF licensing because that's cleanest, but if that's not an 
option...
 
> otherwise if the round trip time was greater than the detection time.

OK; I had low-latency links in mind, but I guess something like this 
would be useful in e.g. trans-{atlantic,pacific} and other links where 
the RTT is a lot higher than the desired detection interval.
 
> IPSec.  

Right.

> Note that the implementation of Demand mode is not mandatory;  

Maybe you have a more pragmatic approach at the standards, so that the 
vendors only implement parts of a spec which interest them (and their 
customers).  I guess this is mostly the case.  However, I'd rather see 
that the specs are split into digestible pieces (like, "BFD On-Demand 
Signalling") and the vendors should implement the base protocol, and 
those which are interested in Foo functionality, can then implement 
the extensions specified separately.

For those which don't think they need Demand mode, could more easily 
leave it out (or come back at it at phase 2 of the implementation, or 
whatever).

Being modular (within reason, of course), also specification-wise, is
a good thing :-).

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

You refer to RFC 2119 with [KEYWORDS], so you should at least 
reference RFC 2119 :-).

You could add a normative reference to GSTM, which was already 
approved, as this seems to depend heavily on its security.

You could add an informational reference to the IPsec demand more 
spec.

But well.. I guess I can't figure out much else at the moment :-)

> very different in their processing.

Maybe the distinction should be spelled out a bit more?  I assume with
"jitter reduction" you're referring to the cost of processing the BFD
packets on CPU, leading to potential jitter and delays if the CPU is
overloaded (assuming bfd control function is implemented in CPU but
echo function might also be implemented in hardware).  Or are you just 
referring to the simplicity of the BFD echo function (and the 
associated processing)?

> Yes, they're still free;  

Might not hurt to state that explicitly.

> however I don't see any semantic distinction 

I guess I view the distinction mainly as that the box implements.  
For example, if you didn't bother to implement (or report) Diagnostic
codes even if you were able to dig them up you could report "No
Diagnostic".  However, if there was some weird error (currently
unspecified, maybe), and one implemented all the reasons, one could 
use like "Other Reason".

I don't feel strongly about this but operationally I'd like to be able 
to distinguish "no, I don't want to tell you any diagnostics or I 
don't support that" from "whoops -- something really weird happened".

> Detection Time Expired" so the semantic content should be the same.

One related section:
----
      Specific diagnostic codes are provided for two scenarios.

      If signalling is received from outside BFD that the underlying path
      has failed, an implementation MAY adminstratively disable the session
      with the diagnostic Path Down.

      If the path being monitored by BFD is concatenated with other paths,
      it may be desirable to administratively bring down the BFD session
      when a concatenated path fails (as a way of propagating the
      failure indication.)  In this case, an implementation MAY
      administratively disable the BFD session with the diagnostic
      Concatenated Path Down.
 
      Other scenarios MAY use the diagnostic Administratively Down.
----

.. do these diagnostics refer to the *local* errors only?  That is,
you don't signal them to your BFD peer? (Naturally, there will
probably be a huge problem of actually delivering the diagnostic
through :-).

So, if the only way to disable a link is either through Echo function 
failure or Control Det. Time Expired, there is no problem, except 
maybe in the case where a link is malfunctioning in one direction but 
working in the other (in which case the BFD peer could signal, "hey, 
I haven't heard anything from you in a while!).

> If it ever really has to get longer, we can always bump the version 

I can agree with this.  Our ATM interfaces (which have multiple times 
shown this misbehaviour -- small packets work but larger ones fail) 
are getting scarce anyway.

OK.

> 100% nor less than 75% of the negotiated interval.

Right, I see that.  But my point was that there doesn't seem to be any 
technical reason to forbid processing the received packets if they 
happened to be sent a little bit faster than agreed to.

Or do you want to ensure that both parties conform to the values which 
have been agreed to, and don't just modify them on their own?  If so, 
maybe this needs to be spelled out a bit more.

> fields in a received packet, which may or may not have been copied into 

Ok, obviously I missed the point about the difference, and got very 
confused.

Maybe this is something that could be clarified a bit more?

> anything else that might be dreamt up by an implementor.

If Echo function could really be looking at the packets, tracking time 
or looking at sequence numbers, it's seems like a huge misnomer -- I 
got the impression that you send a packet, the peer reflects it and 
you receive it back.  How the reflection is done is left unspecified 
which is probably fine.

I guess this is something that needs significant clarification -- 
anything that is left unspecified has to be specified in some detail 
that people understand what's being left unspecified :-)

[[ EDIT: ]] After reading through to section 4.1 and 4.2 of the 
v4v6-1hop BFD document, I start to realize which kind of "echo" 
service you had in mind: I associate echo with "UDP echo" service, you 
as sending a packet in such a fashion that it gets forwarded back at 
you.  This requires a lot of clarification, I think.

This kind of "forward-back" routing might break the very common
ingress filtering mechanisms, though -- e.g., if a customer has put in
a filter "discard all incoming packets from the ISP which use my
addresses" (well, maybe not necessarily, depends of thr strictness of
the filter, if the P-t-P address is from the ISP's address block)
unless there is an exception, correct?  This warrants a special
mention, I think?

OK.

> MUSTs make interoperability harder.)

Yep, I wouldn't want to require anything at this stage -- just add a
cautionary paragraph about the consequences of versioning scheme.

> want to complain loudly to network management or something.

The term "silently discard" is often used to refer to dropping the
packet without an ICMP message (but taking no stance on what's
reported internally).  Kind of like spelling out the obvious
difference between "discard" and "reject with an ICMP message".

Not sure whether it makes worth spelling out here, though.. but I'm 
pretty sure this issue will come up later in the review as this is 
kind of a "check-list item".

> single network layer hop.

You use the terms, "network-layer" and "a signle link" -- how do these 
relate in a network where something employing virtual topologies like 
MPLS or tunneled networks?

Not probably a huge issue, but just something that struct me as being 
slightly ambiguous.

> really wanted to use private addressing internally to their network, 

Right, but this seems to hint at a recommendation for the private 
addressing use, which has significant drawbacks which should be 
spelled out more.
 
> correctness are *way* outside the scope of the specification.

Of course, but it would be desirable that protocols would default to a
mode (unless explicitly configured otherwise) which includes the
guarantees (e.g., require the TTL=255).

In the security considerations, it would also seem to be appropriate 
spell out which measures must be taken by the operator to secure the 
protocol usage, and which measures are (or can be taken) by the 
protocol itself to ensure the security.

> ought to be already or they're in a whole lot of danger.)

Yep -- I think we agree in principle, but I'd like to see longer 
discussion of those options, because one could interpret them as an 
advice (which you certainly don't want it to be).

Maybe I could try to cook up some text if we agree about the rest and 
I understand what you mean with the network-layer/single-link 
scenarios..

> least for boxes cheaper than ours.  ;-)

Right; what I was trying to say was, if you need to deploy this in the 
scenario where you need heavy crypto, the very short detection times 
are probably NOT your number one concern :-)

> is not really subject to standardization, since it's purely an internal 

Yep, this very likely requires some serious thinking wrt. wording.

However, I'm not 100% sure this does not require standardization as 
such.  To make the "static-route BFD" mechanisms work, there seems to 
be a requirement to specify at least certain details of the way it 
works (e.g., how it picks the addresses, where does it expect a 
response from, how it deals with IPv6 route pointing to a global 
address if the BFD packet would come from a link-local and not global, 
etc.) -- if for nothing else, to ensure this stuff interoperates.

Yep.
 
> failure should shoot down OSPFv2 and ISIS-for-v4 adjacencies, etc.)  

Yep, this seems like the intended result :-)

> If 

Yes, this is a slight problem.  I think IS-IS is basically 
IP-independent at the network-layer, as the adjacencies aren't between 
IP addresses but CLNS addresses representing a node.  But should be 
doable.

Of course -- it might also be attractive, with congruent v4/v6 
dual-stack topologies -- that if you only use one protocol (e.g., 
IS-IS) for both v4 and v6, BFD would only check one of them and not 
both.  But fiddling that may not be worth the trouble.
 
> restart in both protocols.

Yes.

> Intradomain Routeing Protocol."

;-)

> Yeah, a few more weasel words would help.

Yep :-)

> like to think of the words as "pearls."  ;-)

Sure.  See below.

> I get paid by the word.  ;-)

I hope that doesn't also apply to the code ;-)
 
> I don't think it would make it any clearer to combine them.

Hmm.. I disagree a bit.  I had an immediate reaction "so, what's the 
difference of these protocols?" and didn't get an immediate answer.   
Let me suggest:

4.1. BFD for IPv4 or IPv6

   The use of BFD is identical whether it is encapsulated in an IPv4
   or IPv6 datagram.

   Within an IP packet, BFD Control packets MUST be transmitted in UDP
   packets with destination port 3784.  The
   source port MUST be in the range 49152 through 65535.  The same UDP
   source port number MUST be used for all BFD Control packets
   associated with a particular session.  The source port number SHOULD
   be unique among all BFD sessions on the system.  If more than 16384
   BFD sessions are simultaneously active, UDP source port numbers MAY
   be reused on multiple sessions, but the number of distinct uses of
   the same UDP source port number SHOULD be minimized.  An
   implementation MAY use the UDP port source number to aid in
   demultiplexing incoming BFD Control packets, but ultimately the
   mechanisms in [BFD] MUST be used to demultiplex incoming packets to
   the proper session.

   BFD Echo packets are transmitted in UDP packets with destination UDP
   port 3785 in an IP packet.  The setting of the UDP source port is
   outside the scope of this specification.  The source and destination
   addresses MUST both be associated with the local system. The destination
   address
   MUST be chosen in such a way as to cause the remote system to forward
   the packet back to the local system.  The source address MUST be
   chosen in such a way (e.g., by using an address of the on-link subnet)
   that the remote system will not generate ICMP Redirect messages.

There was one sentence which was missing in v6 and one in v4.  I don't 
think that was intentional, but not sure..

> preserving our investment in terminology.  ;-)

Right.  The folks wanted to get remembered _somehow_ I think ;-)

> out the TTL hack), what happens in the multihop case is not relevant 

Well, I'd still try to do something about it, in case some poor fool 
copies this document over to multihop, e.g. add to the end:

                                            (Note that this kind of 
    model allowing the source address to change could be dangerous
    in a multihop scenario or if the TTL=255 check was not used.)

(or something similar in the sec cons) -- it just shows one has 
considered the issue, and spelling security considerations out is 
always a good way to speed up a draft in the IETF process ;-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings