Erik Kline's Abstain on draft-ietf-bfd-vxlan-15: (with COMMENT)

Erik Kline via Datatracker <noreply@ietf.org> Sat, 03 October 2020 23:08 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Erik Kline via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bfd-vxlan@ietf.org, bfd-chairs@ietf.org, rtg-bfd@ietf.org, Jeffrey Haas <jhaas@pfrc.org>, jhaas@pfrc.org
Subject: Erik Kline's Abstain on draft-ietf-bfd-vxlan-15: (with COMMENT)
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Erik Kline <ek.ietf@gmail.com>
Message-ID: <160176649979.20342.10526224494715706558@ietfa.amsl.com>
Date: Sat, 03 Oct 2020 16:08:20 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/9vqAt6EnHyYJHeH0GYqv_4lIIvk>

Erik Kline has entered the following ballot position for
draft-ietf-bfd-vxlan-15: Abstain

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/



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

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?

Erik Kline's Abstain on draft-ietf-bfd-vxlan-15: … Erik Kline via Datatracker