Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)
draft-ietf-bfd-v4v6-1hop-11

[Ballot comment]
I agree with Jari's discuss.

Although ports 3784 and 3785 have already been assigned by IANA, it
would be useful to say so in the IANA considerations section.

[Ballot discuss]
We moved forward with the -09 quite a bit! Thanks. Almost there...

However, Section 4.2 still needs further work. I had suggested a number
of changes in my tentative text proposal. The following ones I believe
at least are required:

- even the IPv6 side needs to talk about redirects (my version of the
  text moved some of the common topics to a new section, and this would
  have solved that issue)

- Stating a requirement about the address used would be necessary:
  "An address from another interface than the one on which Echo
  function is running MUST be used. For instance, an address from a
  loopback interface can be used." would be one way to say it.

- Implications for address resolution should be stated, e.g.,
  "As described earlier, these packets may require bypassing IP layer
  functionality on the sender. The above requirements ensure that
  neither the source or the destination addresses of the Echo packets
  are on-link on the interface used for the Echo function.
  This implies that no address resolution needs to be performed on
  them. However, the sender of the Echo packets MUST employ the
  currently determined next hop, if relevant for the type of an
  interface in question. This is necessary so that the Echo packets
  can reach the peer router to which connectivity is being tested."

[Ballot discuss]
First, I support Pasi's discuss and want to track its resolution.
Basically, without the extra information he asks this is not
implementable.

Second, I wonder how this can be made to work at all, except perhaps
in very special circumstances (such as between two routers and by
disabling all the usual ARP and ND functions, disabling redirect, not
having anything else on the link, no ingress filtering anywhere,
etc.).

I do realize that this does work out there in the field :-) so I think
the question is mostly about what the special conditions must be for
this to work. Or am I missing something obvious? If so, please
educate me.

There's two ways to look a this: (1) specify what
changes and special arrangements must exist for ARP/ND/IP in the
sending and receiving hosts. And (2) we need to discuss what the
applicability of this is in the general Internet, after those special
arrangements.

From quick analysis, it seems that one must access the interfaces
directly rather than talk to IP, because your IP layer will
immediately return the packet back to the same node (or make it go out
of another interface). Then this special non-IP access to the
interface needs to somehow bypass ARP and ND, yet it needs to use ARP
and ND to figure out the link layer address of the other side. On
point-to-point links this would be easier.

[Ballot comment]
The title page header should indicate that the intended status for
  this document: Proposed Standard.

  The Gen-ART Review by Christian Vogt and the SecDir Review by
  Radia Perlman both point out the need to clairify the second
  paragraph in section 2, whihc says:
  >
  > Each BFD session between a pair of systems MUST traverse a
  > separate path in both directions.
  >
  Please update this sentence before the document is published as
  an RFC.

[Ballot comment]
The Gen-ART Review by Christian Vogt and the SecDir Review by
  Radia Perlman both point out the need to clairify the second
  paragraph in section 2, whihc says:
  >
  > Each BFD session between a pair of systems MUST traverse a
  > separate path in both directions.
  >
  Please update this sentence before the document is published as
  an RFC.

[Ballot discuss]
First, I support Pasi's discuss and want to track its resolution.
Basically, without the extra information he asks this is not
implementable.

Second, I wonder how this can be made to work at all, except perhaps
in very special circumstances (such as between two routers and by
disabling all the usual ARP and ND functions, disabling redirect, not
having anything else on the link, no ingress filtering anywhere,
etc.).

I do realize that this does work out there in the field :-) so I think
the question is mostly about what the special conditions must be for
this to work. Or am I missing something obvious? If so, please
educate me.

There's two ways to look a this: (1) specify what
changes and special arrangements must exist for ARP/ND/IP in the
sending and receiving hosts. And (2) we need to discuss what the
applicability of this is in the general Internet, after those special
arrangements.

From quick analysis, it seems that one must access the interfaces
directly rather than talk to IP, because your IP layer will
immediately return the packet back to the same node (or make it go out
of another interface). Then this special non-IP access to the
interface needs to somehow bypass ARP and ND, yet it needs to use ARP
and ND to figure out the link layer address of the other side. On
point-to-point links this would be easier.

> In particular, the source address SHOULD NOT
> be part of the subnet bound to the interface over which the BFD Echo
> packet is being transmitted, unless it is known by other means that
> the remote system will not send Redirects.

This seems to be an insufficient condition. Lets assume the address A is
something which exists N hops behind the sending router (rx) in another
interface (if2). Now, if we send a packet to A using the first
interface (if1) towards the BFD peer (ry), the peer will think that
someone's using the wrong router, and sends a redirect from ry to rx.
But still, given that A is N hops away from rx, the address is not
bound to if2 or if1.

[Ballot discuss]
First, I support Pasi's discuss and want to track its resolution.
Basically, without the extra information he asks this is not
implementable.

Second, I wonder how this can be made to work at all, except perhaps
in very special circumstances (such as between two routers and by
disabling all the usual ARP and ND functions, disabling redirect, not
having anything else on the link, no ingress filtering anywhere,
etc.).

I do realize that this does work out there in the field :-) so I think
the question is mostly about what the special conditions must be for
this to work. Or am I missing something obvious? If so, please
educate me.

There's two ways to look a this: (1) specify what
changes and special arrangements must exist for ARP/ND/IP in the
sending and receiving hosts. And (2) we need to discuss what the
applicability of this is in the general Internet, after those special
arrangements.

From quick analysis, it seems that one must access the interfaces
directly rather than talk to IP, because your IP layer will
immediately return the packet back to the same node (or make it go out
of another interface). Then this special non-IP access to the
interface needs to somehow bypass ARP and ND, yet it needs to use ARP
and ND to figure out the link layer address of the other side. On
point-to-point links this would be easier.

> In particular, the source address SHOULD NOT
> be part of the subnet bound to the interface over which the BFD Echo
> packet is being transmitted, unless it is known by other means that
> the remote system will not send Redirects.

This is an insufficient condition. Lets assume the address A is
something which exists behind the sending router (rx) in another
interface (if2). Now, if we send a packet to A using the first
interface (if1) towards the BFD peer (ry), the peer will think that
someone's using the wrong router, and sends a redirect from ry to rx.

[Ballot discuss]
First, I support Pasi's discuss and want to track its resolution.
Basically, without the extra information he asks this is not
implementable.

Second, I wonder how this can be made to work at all, except perhaps
in very special circumstances (such as between two routers and by
disabling all the usual ARP and ND functions, disabling redirect, not
having anything else on the link, no ingress filtering anywhere,
etc.).

I do realize that this does work out there in the field :-) so I think
the question is mostly about what the special conditions must be for
this to work. There's two ways to look a this: (1) specify what
changes and special arrangements must exist for ARP/ND/IP in the
sending and receiving hosts. And (2) we need to discuss what the
applicability of this is in the general Internet, after those special
arrangements.

From quick analysis, it seems that one must access the interfaces
directly rather than talk to IP, because your IP layer will
immediately return the packet back to the same node (or make it go out
of another interface). Then this special non-IP access to the
interface needs to somehow bypass ARP and ND, yet it needs to use ARP
and ND to figure out the link layer address of the other side. On
point-to-point links this would be easier.

> In particular, the source address SHOULD NOT
> be part of the subnet bound to the interface over which the BFD Echo
> packet is being transmitted, unless it is known by other means that
> the remote system will not send Redirects.

This is an insufficient condition. Lets assume the address A is
something which exists behind the sending router (rx) in another
interface (if2). Now, if we send a packet to A using the first
interface (if1) towards the BFD peer (ry), the peer will think that
someone's using the wrong router, and sends a redirect from ry to rx.

[Ballot discuss]
Section 4.1., paragraph 2:
>    BFD Echo packets MUST be transmitted in UDP packets with destination
>    UDP port 3785 in an IPv4 packet.  The setting of the UDP source port
>    is outside the scope of this specification.

  DISCUSS: Source ports for control packets have earlier been defined to
  be in the range of 49152-65535. Instead of leaving this open for echo
  packets (which may mean implementations pick a reserved source port
  number), can the same rule be applied here? (The same applies for IPv6
  below.)

[Ballot comment]
Although ports 3784 and 3785 have already been assigned by IANA, it
would be useful to say so in the IANA considerations section.

From Hilarie Orman's SecDir review:

The sentence "Each BFD session between a pair of systems MUST traverse
a separate path in both directions" in Section 2 needs some
clarification.

[Ballot discuss]
Sections 4.1 and 4.2 need some more text about how BFD Echo packets
are actually sent. It seems you can't e.g. use UDP sockets for sending
them: since the destination address is local, they would be delivered
locally. Also, it seems the normal IPv4 ARP Cache or IPv6
Destination/Neighbor Caches won't work as is.

Section 4.1 talks about ICMP Redirects, but Section 4.2 does not
mention ND Redirects -- wouldn't they cause similar problems
in IPv6 as ICMP Redirects do in IPv4?

Proto writeup by Dave Ward (as WG co-chair and author):

1. Have the chairs personally reviewed this version of the Internet
    Draft (ID), and in particular, do they believe this ID is ready
    to forward to the IESG for publication?

    Yes


  2. Has the document had adequate review from both key WG members and
    key non-WG members?

    Yes. BT had brought together multiple vendors and implementors a year before publishing the docs to make sure every issue was cleared up and intention documented.


    Do you have any concerns about the depth or breadth of the reviews
    that have been performed?
   
    No.


3. Do you have concerns that the document needs more review from a
    particular (broader) perspective (e.g., security, operational
    complexity, someone familiar with AAA, etc.)?

    No


  4. Do you have any specific concerns/issues with this document that
    you believe the ADs and/or IESG should be aware of? For example,
    perhaps you are uncomfortable with certain parts of the document,
    or have concerns whether there really is a need for it. In any
    event, if your issues have been discussed in the WG and the WG has
    indicated it that it still wishes to advance the document, detail
    those concerns in the write-up.

    No concerns


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

It represents strong consensus of a large group of implementors.


6. Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict
    in separate email to the Responsible Area Director.

    No


  7. Have the chairs verified that the document adheres to all
    of the ID Checklist items ?

    Yes


8. Is the document split into normative and informative references?
    Are there normative references to IDs, where the IDs are not
    also ready for advancement or are otherwise in an unclear state?
    (note here that the RFC editor will not publish an RFC with 
    normative references to IDs, it will delay publication until all
    such IDs are also ready for publication as RFCs.)

    Yes, No


  9. What is the intended status of the document? (e.g., Proposed
    Standard, Informational?)

    Proposed Standard


10. For Standards Track and BCP documents, the IESG approval
    announcement includes a write-up section with the following 
    sections:

    * Technical Summary:

BFD and the corollary documents define a mechanism for layer 3 forwarding plane failure detection. There are multiple modes (async, echo, demand) for different circumstances. One interesting aspect of BFD is that it has adaptive timers thus, parameters can be modified without tearing down adjacencies. In addition, the amount of BW and overhead incurred by the network and network nodes is completely under the control of the operator.

  * Working Group Summary

There was no opposition to this document.

    * Protocol Quality

The protocol is widely implemented and deployed and has become part of default deployments on the internet. The drafts reflect the lessons learned from the deployed and operation.