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?
