Alvaro Retana's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)

[Alvaro Retana via Datatracker <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-bfd-vxlan-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Eric's DISCUSS point about the TTL, but I want to go a step further
because this document contradicts rfc5881, which is clear about the TTL setting
(from §5):

   If BFD authentication is not in use on a session, all BFD Control
   packets for the session MUST be sent with a Time to Live (TTL) or Hop
   Limit value of 255.  All received BFD Control packets that are
   demultiplexed to the session MUST be discarded if the received TTL or
   Hop Limit is not equal to 255.  A discussion of this mechanism can be
   found in [GTSM].

   If BFD authentication is in use on a session, all BFD Control packets
   MUST be sent with a TTL or Hop Limit value of 255.  All received BFD
   Control packets that are demultiplexed to the session MAY be
   discarded if the received TTL or Hop Limit is not equal to 255.  If
   the TTL/Hop Limit check is made, it MAY be done before any
   cryptographic authentication takes place if this will avoid
   unnecessary calculation that would be detrimental to the receiving
   system.

OTOH, Section 4 of this document specifies:

     TTL or Hop Limit: MUST be set to 1 to ensure that the BFD
     packet is not routed within the Layer 3 underlay network.  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.

Not wanting the packet to be routed in the underlay sounds like a reasonable
justification -- but I couldn't find the specification in rfc7348 about "a
router in underlay which removes the VXLAN header".  Maybe I missed it...

Independent of VXLAN, the conflict with rfc5881 remains -- given the text
above, it seems to me that it would be ok if the TTL was set to 1 if
authentication is is use, but this document doesn't talk about requiring
authentication.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I also support Ben's DISCUSS.

Non-blocking comments:

(1) §3: "...a service layer BFD session may be used between the tenants of
VTEPs IP1 and IP2..."   Just to be clear, the use of BFD in a "service layer
session" is out of scope of this document, right?  It might be nice to say so.

(2) §3: "As per Section 4, the inner destination IP address SHOULD be..."  If
the specification is already in Section 4, then there doesn't seem to be a need
to repeat it.  It might make more sense to put the text about a potential
firewall there.

(3) §4: "...SHOULD ensure that the BFD packets follow the same lookup path as
VXLAN data packets within the sender system."  What is a "lookup path"?  When
would it be ok to not ensure it?  BTW, a better Normative statement might me
(something like): MUST follow the same lookup path...

(4) §4: "The MAC address MAY be configured, or it MAY be learned via a control
plane protocol. The details of how the MAC address is obtained are outside the
scope of this document."  The Normative MAYs are really just stating a fact,
and out of scope any way.  s/MAY/may

(5) §5: "If the Destination MAC of the inner Ethernet frame doesn't match any
of VTEP's MAC addresses, then the processing of the received VXLAN packet MUST
follow the procedures described in Section 4.1 [RFC7348]."  §4.1 of rfc7348 is
about Unicast VM-to-VM Communication -- which makes me think that if the
procedures from that section are followed then the BFD packet may be forwarded
to a VM, which seems to be in contradiction with this statement (from §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."  What am I missing?

(6) Related to the last point, the following sentences also mention that BFD
packets MUST NOT be forwarded to VMs...but with qualifications:

§5: "If the BFD session is using the Management VNI (Section 6), BFD Control
packets with unknown MAC address MUST NOT be forwarded to VMs."

§6: "All VXLAN packets received on the Management VNI MUST be processed locally
and MUST NOT be forwarded to a tenant."

The difference between these 2 statements and the one from §3 is that they seem
to be intended only when using the Management VNI...but it would seem that the
general statement applies there too, right?  IOW, the specific statements about
the Management VNIs are simply affirming what was already said more generally
in §3, right?

(7) Nits:

s/of VXLAN gateway and there is a router in underlay/of the VXLAN gateway and
there is a router in the underlay

s/VTEP MUST validate/the VTEP MUST validate

s/then BFD session/then the BFD session