Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN)
draft-ietf-bfd-vxlan-16

I support Ben Kaduk’s DISCUSS position.

* Section 9. Per “The document requires setting the inner IP TTL to 1, which could be used as a DDoS attack vector”, could you please clarify what part(s) of the notional architecture would be impacted (e.g., physical, virtual; and how)?

* Section 9. Per:
   Thus the implementation MUST have
   throttling in place to control the rate of BFD Control packets sent
   to the control plane.  On the other hand, over-aggressive throttling
   of BFD Control packets may become the cause of the inability to form
   and maintain BFD session at scale.  Hence, throttling of BFD Control
   packets SHOULD be adjusted to permit BFD to work according to its
   procedures.

I’m having difficulty parsing the guidance above – it points out the need to throttle and the ramifications of doing so.  Per the last sentence, could you please clarify how the throttling should be calibrated.

* Section 9.  Per “this specification does not raise any additional security issues beyond those of the specifications referred to in the list of normative references”, I recommend being clearer which references you mean (i.e., I’m assuming you don’t mean RFC2119, RFC8174, etc.)

* Editorial Nits:
- Abstract. s/forming up/used to form/

- Section 9. s/such address/such an address/

I support Benjamin and Eric's DISCUSSES - I considered holding a DISCUSS on the "loopback address" terminology and formatting (which was also noted in the excellent OpsDir review by Jürgen Schönwälder), but think that Eric can carry it.

In addition, like Jurgen, I think it would be helpful to have pointers to where terms are defined - the "Terminology" section isn't really terminology, but rather just an acronym expansion section.

Thanks for the work that everyone has put into this document. I have
a couple of relatively important, related comments that should be
taken into account prior to publication.

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

§3:

>  As per Section 4, the inner destination IP address SHOULD be set to
>  one of the loopback addresses (127/8 range for IPv4 and
>  0:0:0:0:0:FFFF:7F00:0/104 range for IPv6).

Please consider reformatting this IPv6 address according to the recommendations
of RFC 5952 (paying particular attention to sections 4.2.1, 4.3, and 5):

::ffff:127.0.0.0/104

It's also worth noting that, as a practical matter, modern operating systems do
not seem to bind to anything in the IPv4-mapped range assigned to IPv4 loopback:

Linux:

  ~$ ping6 ::ffff:127.0.0.1
  PING ::ffff:127.0.0.1(::ffff:127.0.0.1) 56 data bytes
  ^C
  --- ::ffff:127.0.0.1 ping statistics ---
  14 packets transmitted, 0 received, 100% packet loss, time 13316ms

MacOS:

  ~$ ping6 ::ffff:127.0.0.1
  PING6(56=40+8+8 bytes) ::ffff:127.0.0.1 --> ::ffff:127.0.0.1
  ping6: sendmsg: Invalid argument
  ping6: wrote ::ffff:127.0.0.1 16 chars, ret=-1


It is not clear to me whether this poses an issue for your intended usage.

In any case, please do not refer to ::ffff:127.0.0.0/104 as "loopback
addresses": IPv6 has only one loopback address defined (::1). The range
you cite is best described as "IPv4-mapped IPv4 loopback addresses."
Alternately -- and this is probably better -- use "::1/128" instead of
"::ffff:127.0.0.0/104" for the inner IP header destination address.

As an aside, I share Benjamin's unease around the use of loopback addresses
in this fashion. It may be worth noting that IETF protocols can reserve
addresses in the 192.0.0.0/24 and 2001::/23 blocks if necessary, and such
reserved addresses won't ever correspond to a valid destination.

(There is corresponding text in section 4 that all of the preceding pertains
to as well)

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

§9:

>  This document recommends using an address from the Internal host
>  loopback addresses (127/8 range for IPv4 and
>  0:0:0:0:0:FFFF:7F00:0/104 range for IPv6) as the destination IP
>  address in the inner IP header.  Using such address prevents the
>  forwarding of the encapsulated BFD control message by a transient
>  node in case the VXLAN tunnel is broken as according to [RFC1812]:
>
>     A router SHOULD NOT forward, except over a loopback interface, any
>     packet that has a destination address on network 127.  A router
>     MAY have a switch that allows the network manager to disable these
>     checks.  If such a switch is provided, it MUST default to
>     performing the checks.

In addition to the comments above about IPv6 address formatting, the
improper use of "loopback" terminology as it applies to IPv6, and
concerns about using localhost: it's worth noting that this text in
RFC 1812 refers to IPv4 routers -- RFC 8504 has no equivalent language,
and so the use of ::ffff:127.0.0.0/104 implies no special router handling.
::1 *probably* does, at least as a practical matter.

[Thank you for addressing my DISCUSS.]

I support Ben’s DISCUSS.  In addition, I have a number of editorial comments.

General: there are a lot of missing or incorrect articles, making the document harder to read than it should be.  It would be good to fix that.  If you let the RFC Editor fix it, it will require careful review during AUTH48 to make sure it’s correct.

— Abstract —
The phrase “forming up” is odd; I suggest just “forming”.

— Section 3 —

   BFD packets intended for a VTEP MUST
   NOT be forwarded to a VM as a VM may drop BFD packets leading to a
   false negative.

This needs two commas: one before “as” and one before “leading”.  And what does “leading to a false negative” mean here?  I don’t understand.

   It is RECOMMENDED to allow
   addresses from the loopback range through a firewall only if it is
   used as the destination IP address in the inner IP header, and the
   destination UDP port is set to 3784 [RFC5881].

I THINK the antecedent for “it” is meant to be “addresses from the loopback range”, though because of the number mismatch it looks like the antecedent is “a firewall”.  One fix is to change “addresses” to “an address”, correcting the number error, but that leaves the ambiguity.  Maybe betterto make it “only if they are used as destination IP addresses”.  Also, remove the comma.

That fixes the sentence as written, but I also agree with Ben’s comment that this might need more significant rewording.

— Section 4 —

   BFD packet MUST be encapsulated and sent to a remote VTEP as
   explained in this section.

This needs to be either “A BFD packet” or “BFD packets” and “VTEPs”.

         The MAC address MAY be
         configured, or it MAY be learned via a control plane protocol.

Are those the only two choices?  As both “MAY” are optional, as written it allows for others.  I suggest not using BCP 14 key words here, and instead saying, “The MAC address is either configured or learned via a control plane protocol.”

         This
         addresses the scenario when the inner IP destination address is
         of VXLAN gateway and there is a router in underlay which
         removes the VXLAN header, then it is possible to route the
         packet as VXLAN  gateway address is routable address.

This sentence is too fractured for me to make any sense of it, so I can’t suggest a fix.  Please fix it.  It looks like Ben made more sense of it than I could, so maybe his suggestion will work.

— Section 5 —

   received VXLAN packet MUST follow the procedures described in
   Section 4.1 [RFC7348].

This needs to say “Section 4.1 of [RFC7348].”

Thank you for the discussions around my discuss point, and the ensuing changes
resulting from the discussions!  My apologies that I was tardy in re-reviewing after
the updates were made.

I think the core issues have been resolved, but do have a couple comments on the -14:

Section 3 says:

                  Separate BFD sessions can be established between the
   VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100
   and 200).  Using a BFD session to monitor a set of VXLAN VNIs between
   the same pair of VTEPs might help to detect and localize problems
   caused by misconfiguration.  An implementation that supports this
   specification MUST be able to control the number of BFD sessions that
   can be created between the same pair of VTEPs.  [...]
 
While the first two sentences are probably true, they are arguably out 
of scope for this document, since Section 6 says that BFD control
packets on non-management VNI is outside the scope of this
specification.  The third sentence is quite surprising in the context of 
this document only defining BFD for the management VNI, since multiple 
BFD sessions on the same VNI seem redundant.

Section 5

         Destination MAC: A Management VNI, which does not have any
         tenants, will have no dedicated MAC address for decapsulated
         traffic.  The value [TBD1] SHOULD be used in this field.

While this normative language seems like the appropriate level of 
stringency, I do find myself wondering what other value might be used 
and why.  (This, of course, need not be answered in the document, though
it could be if the answer is known and useful.)

UPDATE: I didn't not see a reply to the original issue raised by the TSV-ART review (Thanks Olivier!). Please have a lock and provide a response. I don't think this raises discuss level but I think some clarifications would be good!


This document describes the use of BFD in VXLAN, however, it does not specify any new protocol elements or extension. Therefore I would expect such a document to be informational. The shepherd write-up doesn't give any additional information about why this doc is PS.

Hi,

This document seems pretty straight forward to me.  A few, non blocking, comments:

Assigning a single unicast MAC address seems slightly odd in that it isn't globally unique, but I can't think of any good alternative.

   At the same time, a service layer BFD session may be used between the
   tenants of VTEPs IP1 and IP2 to provide end-to-end fault management
   (this use case is outside the scope of this document).  In such a
   case, for VTEPs BFD Control packets of that session are
   indistinguishable from data packets.
   
"for VTEPs BFD Control" => "for VTEPS, the BFD Control" 

         Ethernet Header:

         Destination MAC: A Management VNI, which does not have any
         tenants, will have no dedicated MAC address for decapsulated
         traffic.  The value (TBD1) SHOULD be used in this field.

         Source MAC: MAC address associated with the originating VTEP.
         

Should the TypeOrLen field in the Ethernet header also be specified (presumably set to IPv4 or IPv6)?

Regards,
Rob

Support Eric's DISCUSS on the IPv6 destination address and would like to see this clarified and resolved.