Skip to main content

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

Yes

(Martin Vigoureux)

No Objection

(Alexey Melnikov)
(Alissa Cooper)
(Deborah Brungard)
(Magnus Westerlund)

Abstain


Note: This ballot was opened for revision 09 and is now closed.

Alvaro Retana (was Discuss) No Objection

Comment (2020-06-17 for -12)
[Thank you for addressing my DISCUSS.]

Robert Wilton No Objection

Comment (2020-10-02 for -15)
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

Roman Danyliw No Objection

Comment (2019-12-16 for -09)
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/

Warren Kumari No Objection

Comment (2019-12-17 for -09)
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.

Erik Kline Abstain

Comment (2020-10-03 for -15)
doc{draft-ietf-bfd-vxlan-15}
ballot{Abstain}


[[ comments ]]

I was tempted to ballot Discuss, but I'm not sure about re-opening old
discussions into which I've no insight (it all happened before my tenure).


[ sections 3,5 ]

* I agree with Eric Vyncke's concerns about the use of ::ffff:127.0.0.0/104
  space.  This is not especially well-motivated, nor do I think the use of
  127.0.0.0/8 is particularly well-motivated.

  In IPv6, 2001::/23 is reserved for IETF protocol assignments and in my
  opinion this is an example of where that should be used.

  There is also still plenty of space to carve out from 192.0.0.0/24 for
  internal tunnel uses like this.

  Alternatively, a better approach might be for each VTEP to allocate their
  own IPv4 and/or IPv6 link-local addresses and uses these addresses for
  whatever traffic is to be sent within the data plane.  If the VTEPs use
  inner Ethernet headers for this traffic, then this would seem to make
  more sense to me.

[ section 9 ]

* It's not clear that the security of a prohibition on routers is sufficiently
  motivating securit when the packet is logically "switched" because it's on
  the same (effectively) VLAN.  The same router forwarding prohibition applies
  to link-local IP addresses and these could be used instead.

* What prevents a machine like VM1-1 from crafting a packet with the magic
  destination MAC and src & dst IPs from the magic range?  Should there be
  text about not forwarding any packets from VMs toward the magic dst MAC?

Éric Vyncke (was Discuss) Abstain

Comment (2020-07-22 for -13)
Thank you for the work put into this document and its update. I have cleared one of my DISCUSS point about TTL = Hop Limit not being 255. 

But, the authors and I are in an impasse about the use of IPv4-mapped IPv6 addresses but I do not want to block the document. I change my ballot to "ABSTAIN" in the sense of "I oppose this document but understand that others differ and am not going to stand in the way of the others".

BTW, I understood that the use a prefix rather than /32 or /128 was to allow for entropy (to explore multiple ECMP/LAG paths). 
BTW2, the right wording is "IPv4-mapped IPv6 address" and not "IPv4-mapped IPv4 address" as written twice in the document.

Did you (or actually the authors) also investigate the use of the:
- ::/0 : unspecified address
- 100::/8 the discard prefix used for RTBH RFC 6666
- or even requesting a block out of the 2001::/23 (reserved for IETF special use)

Previous COMMENTs for archive as they were on revision -09

RFC 5881 (BFD) states that it applies to IPv4/IPv6 tunnels, may I infer that this document is only required to address the Ethernet encapsulation ? I.e. specifying the Ethernet MAC addresses?

-- Section 3 --
At first sight, I was surprized by having a BFD session per VXLAN VNI as it will create some scalability issue, but, I assume that this is to detect misconfiguration as well. If so, perhaps worth mentionnig the reasoning behind?

In "the inner destination IP address SHOULD" it is unclear whether it is in the all BFD packets, or only the request one or ... ?
	
-- Section 4 --
While probably defined in RFC7348, should "FCS" be renamed as "Outer Ethernet FCS" for consistency with the "Outer Ethernet Header" in figure 2 ?

Why not using the Source MAC address as the Destination MAC address ? This would ensure that there is no conflict at the expense of "forcing" the transmission of the frame even if addressed to itself.

Please consider rewriting the section about TTL/Hop Limit as it is not easy to parse/read.

-- Section 9 --

This section is mainly about IPv4 (RFC 1812). Please address IPv6 as well in the explanation of packet not being forwarding when addressed to 127/8

(Martin Vigoureux; former steering group member) Yes

Yes (for -09)

                            

(Adam Roach; former steering group member) No Objection

No Objection (2019-12-16 for -09)
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.

(Alexey Melnikov; former steering group member) No Objection

No Objection (for -09)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -09)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2019-12-16 for -09)
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].”

(Benjamin Kaduk; former steering group member) (was Discuss) No Objection

No Objection (2020-09-29 for -14)
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.)

(Deborah Brungard; former steering group member) No Objection

No Objection (for -09)

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection (for -09)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2019-12-10 for -09)
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.

(Suresh Krishnan; former steering group member) No Objection

No Objection (2019-12-19 for -09)
Support Eric's DISCUSS on the IPv6 destination address and would like to see this clarified and resolved.