Re: Éric Vyncke's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)

Greg Mirsky <gregimirsky@gmail.com> Thu, 19 December 2019 02:10 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6F6120BDB; Wed, 18 Dec 2019 18:10:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.596
X-Spam-Level:
X-Spam-Status: No, score=-0.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUxzipsQAQxf; Wed, 18 Dec 2019 18:10:07 -0800 (PST)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A211200D6; Wed, 18 Dec 2019 18:10:06 -0800 (PST)
Received: by mail-lj1-x229.google.com with SMTP id j26so4363171ljc.12; Wed, 18 Dec 2019 18:10:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Zs/Vli8t7NraVCxCoPbS19iUeeuwoJelATCdbZ8oRq4=; b=FMWb369KVSD9Ja+pISjCtPOsgPoMWh4Ar/ADbwbxSGIj/wAFRYweqTv/M7CjGS8Kba g1iQbTEkfG3FTJm3MqdRdKJibUn2RFezRfe/7pV7Ewpqgrus9l95JFoZyP+fp5oT6Bwe JAdnDgn34Gh/D6Cd4lktCCmWDUcsI1OPv39wGCm+j0l9NivJjeKvuOqUlII6tBVWmDJ1 pZDtn0c1qgfsjywJYgpWxFNAB3ygktedXWzRA1PdBz0/41c9capm4OUIjJYxpKVT270a 3iiQuHgGI340NWJBXnDBWeSGoimlwWKh2ni0yHVLMgbkHQUnQHbC/Gezq4eDjAj+hXrY St8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Zs/Vli8t7NraVCxCoPbS19iUeeuwoJelATCdbZ8oRq4=; b=QOueGNIzWjx0GGrMKLLc1VcAFc+rNCY04YvAD3vAfz+FJU2hitpyeg5ZIljAib3CrP Ao4I16UTkf7IOClYnqDBwUDKD8iwKWr/ZlwzL1RcEkqvO8EXEu/Pab+na4s11wkRucJN YkXCoiohE0Bb+hR1xlnIzvBuH/9tCmuiZZc11w+ddna1UuGHGjT0Sx8jJ0DE0q4esbHk GqRNCGU64OwtFRYiC/L8ul0Fx4jIVMMSRCGiQFUixi6XPTj9Z8Ru0j7LwRaq97CO5rSl 2LNl6U6UOcV5cNpqWqEFolhOIjyHoEYz+lvCgE2fxYM9eTmHgRbWb0+L+Sfr38LMoKih tocg==
X-Gm-Message-State: APjAAAWHxy3DEU/yUCdf707zdN+RhSPKpZOGMHfQsMJpMwpDi9LTNqZU BUoYnOBbUxXrsQB17s63IcpQO58fHAV88PvOWOq1MwsY
X-Google-Smtp-Source: APXvYqy3+s0+rHqgEcQwTarO3dp45GjLD5qkmW5Mm1Z6Wwvnz/8Zpmd/Ow32HBive/jsY8FofwVytGg12PIcyBDxwuc=
X-Received: by 2002:a2e:6c06:: with SMTP id h6mr3918550ljc.246.1576721404268; Wed, 18 Dec 2019 18:10:04 -0800 (PST)
MIME-Version: 1.0
References: <157657269782.26511.12421406428553874826.idtracker@ietfa.amsl.com>
In-Reply-To: <157657269782.26511.12421406428553874826.idtracker@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 18 Dec 2019 18:09:53 -0800
Message-ID: <CA+RyBmU4jh7FCdAYK9ydJUX6+Ddw2feFYEUYHKmpV9RyCSzohQ@mail.gmail.com>
Subject: =?UTF-8?Q?Re=3A_=C3=89ric_Vyncke=27s_Discuss_on_draft=2Dietf=2Dbfd=2Dvxlan=2D0?= =?UTF-8?Q?9=3A_=28with_DISCUSS_and_COMMENT=29?=
To: =?UTF-8?B?w4lyaWMgVnluY2tl?= <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-bfd-vxlan@ietf.org, Jeffrey Haas <jhaas@pfrc.org>, bfd-chairs@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>
Content-Type: multipart/mixed; boundary="0000000000003794bf059a050f53"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/McKKNJl4F33WrfQJXy0_ceqZeXg>
X-Mailman-Approved-At: Thu, 19 Dec 2019 02:56:56 -0800
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2019 02:10:14 -0000

Hi Eric,
thank you for your review, comments, and suggestions. Please find my
answers below under GIM>> tag. Also, attached is the diff to the working
version of the document that includes updates that Adam has suggested.

Best regards,
Greg


On Tue, Dec 17, 2019 at 12:51 AM Éric Vyncke via Datatracker <
noreply@ietf.org> wrote:

> Éric Vyncke 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:
> ----------------------------------------------------------------------
>
>
> Thank you for the work put into this document.
>
> I fully second Adam's COMMENT that should be fixed before publication (IMHO
> this is a DISCUSS).
>
GIM>> I've applied changes suggested by Adam to the working version of the
document.

>
> Answers to my COMMENTs below will be welcome, even if those COMMENTs are
> not
> blocking.
>
> As usual, an answer to the DISCUSS is required to clear my DISCUSS though.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == DISCUSS ==
>
> May be I am not familiar enough with BFD, but, RFC 5881 (the one defining
> BFD)
> specifies the use of TTL = Hop Limit = 255.. Why this document uses a
> value of
> 1 ?
>
GIM>> Jeff and Carlos are in a very detailed and insightful discussion.
I'll wait for its conclusion and follow on their agreement.


> -- Section 3 --
> IPv4-mapped IPv6 addresses are only to be used inside a host and should
> never
> be transmitted in real packets (including packets inside a tunnel) see
> section
> 4.2 of RFC 4038 (even if informational). As other IESG reviewers, I wonder
> why
> ::1/128 is not used?
>
GIM>> The mechanism of using an address from the loopback address range or
IPv4-mapped addresses of that range may be used to create entropy and
monitor ECMP paths in an IP/MPLS network (RFC 8029 and RFC 5884). This
specification uses the same mechanism for ECMP environment in the underlay
network.

>
> -- Section 8 --
> The document specifies no IANA actions while the shepherd write-up talks
> about
> a IANA action.
>
GIM>> RtgDir review from Joel Halpern and the extensive discussion on BFD
WG list lead to this change. As a result, the request to allocate a MAC
address to be used as the destination MAC address in the inner Ethernet
header was withdrawn and removed from the specification.

>
> -- Section 9 --
> This section is only about IPv4 (TTL and RFC 1812). Please address IPv6 as
> well.
>
GIM>> Added "or Hop Limit". Please let me know if you agree. As for a IPv6
relevant reference equivalent to RFC 1812, Adam Roach has noted that RFC
8504 does not have anything of the kind. At the same time, the use of
IPv4-mapped loopback address range has been mandated in RFC 8029 and RFC
5884.

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> == COMMENTS ==
>
> 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?
>
GIM>> There were several threads on encapsulation of BFD Control packet
over VXLAN that, in my estimation, gathered 150+ messages. As you've
noticed from the Shepherd write-up, the use of the dedicated MAC address
was proposed, discussed, and documented. But later the WG decided not to
use the dedicated MAC as the destination MAC in the inner Ethernet frame.
Similarly, we had an extended discussion, including valuable input from
implementors of BFD over VXLAN, on the selection of the destination IP
address in the inner IP header. And another set of issues was discovered
related to the selection of VXLAN VNI value when encapsulating  BFD control
packet. I hope we've analyzed all encapsulation issues and documented them
sufficiently for the benefit of future implementations.

>
> -- 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?
>
GIM>> I agree, detecting misconfiguration might be one of the reasons to
run BFD over some VXLAN VNIs. Would the following text be acceptable:

NEW TEXT:
   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.

>
> In "the inner destination IP address SHOULD" it is unclear whether it is
> in the
> all BFD packets, or only the request one or ... ?
>
GIM>> This is applicable to all BFD control packets transmitted over a
VXLAN tunnel. To clarify, I propose the following change:
OLD TEXT:
As per Section 4, the inner destination IP address SHOULD be set to ...
NEW TEXT:
   For BFD Control packets encapsulated in VXLAN
   (Figure 2), the inner destination IP address SHOULD be set to ...

>
> -- 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 ?
>
GIM>> Would s/FCS/Outer FCS/ be acceptable?

>
> 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.
>
GIM>> Based on the input from experts familar with existing
implementations, WG decided not to require the use of the specific MAC
address. I think that using the Source MAC as the Destination might be one
of the options an implementation will use.

>
> Please consider rewriting the section about TTL/Hop Limit as it is not
> easy to
> parse/read.
>
GIM>> Could you help me kindly and point to the problematic text?

>
> -- Section 9 --
> It is unclear to me (see also Ben's comment) what is the 'attack vector' of
> sending packets with TTL=1 ?
>
GIM>> Another input from experts familiar with VXLAN and its deployments
reflected in the following:
          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.