Re: Tsvart last call review of draft-ietf-bfd-vxlan-07
Greg Mirsky <gregimirsky@gmail.com> Mon, 17 June 2019 04:59 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 AC263120129; Sun, 16 Jun 2019 21:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.597
X-Spam-Level:
X-Spam-Status: No, score=-0.597 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] 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 Aj_fgET_LJeL; Sun, 16 Jun 2019 21:59:29 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 6A5AD120111; Sun, 16 Jun 2019 21:59:26 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id p24so5480258lfo.6; Sun, 16 Jun 2019 21:59:26 -0700 (PDT)
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=lfofZ0dnkqjksBu6GnFH5pPqNRIKY2xmc2s6+toWAuI=; b=m6hzKkoba0FQ8suNPMYZB9VGjmCdnbiFUtffahUxel7FuAW9nt8m0DZhvkCD+YtFiN BWkz+Aja9r58B/08jmUItbyeYE2ABQs1PHKImHvyR9HztW9JDKDB+5mpM9Mv5APX/iXF betLIfG/B9qULUoi+a55DvInTKNK6HTLndb4VHdqkoDWa/Ful8ngyy8h7EWW4fIHORr1 qovFJtDgrTxIG246Mku+oxaWPy241ne9kN+ZXGXZ9ytBA9UdaM+KXLUejbFB3oUhzokA BKdm9mfv7xDck/xW7Lfd7NEkxAQCuy2tWRybOeZapIh088ynMx32OhsnEkt/GmD6prlm ytdg==
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=lfofZ0dnkqjksBu6GnFH5pPqNRIKY2xmc2s6+toWAuI=; b=Wu+UChBdpln121uaeAC0iPdG9Pd7aE4JzrZmIhCoYL7kJ8OBzvINeqIJ2EfuA+XB/P A2VI9yxx2MXipZxJjC1Zp9zqkaeUucxuBxVC3RfjGBdHzMuUa017t+InwNPsEwPeQZl3 TeXXodnRbyoAIbUhfF7Q2vwlvhTjsJf5Nv9CcUBrKj7bXIY0tNrY87vtrR05UTgelF+6 Rx0twVwb40OLDtvg9C+/VTCFJv9CM8M0D+mKI6BkE6DODc5E2aqVPAOyDE6q9DSUTDVh V6lSpGOEkRue/1nnXMJhwjsDLrwlml4HaO+Zvoj4XnXnhtPTgZ3NLlXphwt3Eo6CEHU2 DW3w==
X-Gm-Message-State: APjAAAXg3NJ55h64v0F+cLcRClzTsrl8e+HPVvoKx53DYYyc321rhgY+ xKidKnptAmZ/BFGITLdJrgKzKtMFq6rATeiplFY=
X-Google-Smtp-Source: APXvYqzAgtSgE/B8apsGmwtuJAnXaVCpkgn1muFc294nzYDjVftXA9F50gfeGcjJ9cVlJiJ1wS/aVCj7RgIBn3A/gC4=
X-Received: by 2002:a05:6512:24a:: with SMTP id b10mr51615835lfo.37.1560747564565; Sun, 16 Jun 2019 21:59:24 -0700 (PDT)
MIME-Version: 1.0
References: <155933149484.6565.7386019489022348116@ietfa.amsl.com>
In-Reply-To: <155933149484.6565.7386019489022348116@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 17 Jun 2019 13:58:05 +0900
Message-ID: <CA+RyBmXu-F0cWDkBydE_aJaVpUv=k1otqUCc7NdRW4pnBK3tgA@mail.gmail.com>
Subject: Re: Tsvart last call review of draft-ietf-bfd-vxlan-07
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Cc: tsv-art@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>, draft-ietf-bfd-vxlan.all@ietf.org, IETF list <ietf@ietf.org>
Content-Type: multipart/mixed; boundary="0000000000002bb946058b7ddcb6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/yCJ3ItIjT5j5rSgrargnQM-Sx-0>
X-Mailman-Approved-At: Mon, 17 Jun 2019 05:34:48 -0700
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: Mon, 17 Jun 2019 04:59:34 -0000
Hi Oliver, thank you for your thorough review, clear and detailed questions. My apologies for the delay to respond. Please find my answers below in-line tagged GIM>>. Regards, Greg On Fri, May 31, 2019 at 12:38 PM Olivier Bonaventure via Datatracker < noreply@ietf.org> wrote: > Reviewer: Olivier Bonaventure > Review result: Ready with Issues > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the > document's > authors and WG to allow them to address any issues raised and also to the > IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please always CC > tsv-art@ietf.org if you reply to or forward this review. > > I have only limited knowledge of VXLAN and do not know all subtleties of > BFD. > This review is thus more from a generalist than a specialist in this topic. > > Major issues > > Section 4 requires that " Implementations SHOULD ensure that the BFD > packets follow the same lookup path as VXLAN data packets within the > sender system." > > Why is this requirement only relevant for the lookup path on the sender > system > ? What does this sentence really implies ? > GIM>> RFC 5880 set the scope of the fault detection of BFD protocol as ... the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves ... The requirement aimed to the forwarding engine of a BFD system that transmits BFD control packets over VXLAN tunnel. > > Is it a requirement that the BFD packets follow the same path as the data > packet for a given VXLAN ? I guess so. In this case, the document should > discuss how Equal Cost Multipath could affect this. > GIM>> I think that ECMP environment is more likely to be experienced by a transit node in the underlay. If the BFD session is used to monitor the specific underlay path, then, I agree, we should explain that using the VXLAN payload information to draw path entropy may cause data and BFD packets following different underlay routes. But, on the other hand, that is the case for OAM and fault detection in all overlay networks in general. > > Minor issues > > Section 1 > > You write "The asynchronous mode of BFD, as defined in [RFC5880], > can be used to monitor a p2p VXLAN tunnel." > > Why do you use the word can ? It is a possibility or a requirement ? > GIM>> In principle, BFD Demand mode may be used to monitor p2p paths as well, I agree, will re-word to more assertive: The asynchronous mode of BFD, as defined in [RFC5880], is used to monitor a p2p VXLAN tunnel. > > > NVE has not been defined before and is not in the terminology. > GIM>> Will add to the Terminology and expand as: NVE Network Virtualization Endpoint > > This entire section is not easy to read for an outsider. > > Section 3 > > VNI has not been defined > GIM>> Will add to the Terminology section: VNI VXLAN Network Identifier (or VXLAN Segment ID) > > Figure 1 could take less space > GIM>> Yes, can make it bit denser. Would the following be an improvement? +------------+-------------+ | Server 1 | | +----+----+ +----+----+ | | |VM1-1 | |VM1-2 | | | |VNI 100 | |VNI 200 | | | | | | | | | +---------+ +---------+ | | Hypervisor VTEP (IP1) | +--------------------------+ | | +-------------+ | | Layer 3 | +---| Network | +-------------+ | +-----------+ | +------------+-------------+ | Hypervisor VTEP (IP2) | | +----+----+ +----+----+ | | |VM2-1 | |VM2-2 | | | |VNI 100 | |VNI 200 | | | | | | | | | +---------+ +---------+ | | Server 2 | +--------------------------+ > Section 4 > > I do not see the benefits of having one paragraph in Section 4 followed by > only > Section 4.1 > GIM>> Will merge Section 4.1 into 4 with minor required re-wording: 4. BFD Packet Transmission over VXLAN Tunnel BFD packet MUST be encapsulated and sent to a remote VTEP as explained in this section. Implementations SHOULD ensure that the BFD packets follow the same lookup path as VXLAN data packets within the sender system. BFD packets are encapsulated in VXLAN as described below. The VXLAN packet format is defined in Section 5 of [RFC7348]. The Outer IP/UDP and VXLAN headers MUST be encoded by the sender as defined in [RFC7348]. > > Section 4.1 > > The document does not specify when a dedicated MAC address or the MAC > address > of the destination VTEP must be used. This could affect the > interoperability of > implementations. Should all implementations support both the dedicated MAC > address and the destination MAC address ? > GIM>> After further discussion, authors decided to remove the request for the dedicated MAC address allocation. Only the MAC address of the remote VTEP must be used as the destination MAC address in the inner Ethernet frame. Please check the attached diff between the -07 and the working versions or the working version of the draft. > > It is unclear from this section whether IPv4 inside IPv6 and the opposite > should be supported or not. > GIM>> Any combination of outer IPvX and inner IPvX is possible. > > Section 5. > > If the received packet does not match the dedicated MAC address nor the MAC > address of the VTEP, should the packet be silently discarded or treated > differently ? > GIM>> As I've mentioned earlier, authors have decided to remove the use of the dedicated MAC address for BFD over VXLAN. > > Section 5.1 > > Is this a modification to section 6.3 of RFC5880 ? This is not clear > GIM>> I think that this section is not modification but the definition of the application-specific procedure that is outside the scope of RFC 5880: The method of demultiplexing the initial packets (in which Your Discriminator is zero) is application dependent, and is thus outside the scope of this specification. > > Section 9 > > The sentence " Throttling MAY be relaxed for BFD packets > based on port number." is unclear. > GIM>> Yes, thank you for pointing to this. The updated text, in the whole paragraph, is as follows: NEW TEXT: The document requires setting the inner IP TTL to 1, which could be used as a DDoS attack vector. 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.
- Tsvart last call review of draft-ietf-bfd-vxlan-07 Olivier Bonaventure via Datatracker
- Re: Tsvart last call review of draft-ietf-bfd-vxl… Greg Mirsky
- Re: Tsvart last call review of draft-ietf-bfd-vxl… Greg Mirsky
- Re: Tsvart last call review of draft-ietf-bfd-vxl… Carlos Pignataro (cpignata)
- Re: Tsvart last call review of draft-ietf-bfd-vxl… Carlos Pignataro (cpignata)
- Re: Tsvart last call review of draft-ietf-bfd-vxl… Greg Mirsky
- Re: Tsvart last call review of draft-ietf-bfd-vxl… Carlos Pignataro (cpignata)
- Level of standardization of the Echo mode of BFD … Greg Mirsky
- Re: Level of standardization of the Echo mode of … Carlos Pignataro (cpignata)
- Re: Level of standardization of the Echo mode of … Greg Mirsky
- Re: Level of standardization of the Echo mode of … Carlos Pignataro (cpignata)
- Re: Level of standardization of the Echo mode of … Greg Mirsky
- Re: Tsvart last call review of draft-ietf-bfd-vxl… Jeffrey Haas
- Re: Level of standardization of the Echo mode of … Jeffrey Haas
- Re: Tsvart last call review of draft-ietf-bfd-vxl… Carlos Pignataro (cpignata)
- Re: Level of standardization of the Echo mode of … Carlos Pignataro (cpignata)
- Re: Level of standardization of the Echo mode of … Greg Mirsky
- Re: Level of standardization of the Echo mode of … Carlos Pignataro (cpignata)