Re: Opsdir telechat review of draft-ietf-bfd-vxlan-09

Greg Mirsky <> Tue, 17 December 2019 22:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C7051200FA; Tue, 17 Dec 2019 14:53:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.596
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PMfIzCWA8Kzd; Tue, 17 Dec 2019 14:53:51 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7391A1208D7; Tue, 17 Dec 2019 14:53:50 -0800 (PST)
Received: by with SMTP id r14so213541lfm.5; Tue, 17 Dec 2019 14:53:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DxbMc58ettIKA29z9bzUfUJKkxZA2W5a08VP3dj3fpU=; b=MJbEuq+0aqdQePbwa6DSyxPTFo4qPYSPstzqGNo7tCvPe/y4yerHksAYedwhnqns6W W40AurUmX589IXzdjW6fuM58v54ohV7iKqnx0BTaBpoqp1OhZygS3zSnSZbhr1K+SnvF QNMITYnsZ9q04lj0XlAT+NQ/egDuXTqa29jCbvLxE4wSb17OrTTUboqgCjFI3e+RDzmF VZ31muXkjWt3/xSbaCanzQdJb5ImRolUwA+g6YmUM5qzztU6emlDqYG1BDmKnNa9PIg8 j3UGsvOD1ysAW5aMHcMmLoQ0av4AuHIM/l2T6vw55OCRZ9u1ipPmHItZjNWEMDIcxtn0 yuEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DxbMc58ettIKA29z9bzUfUJKkxZA2W5a08VP3dj3fpU=; b=jMO6W55KZG/q7VjRhHMxLUcW7CNrmIETloVGIYvN8fFvDe004iF/8VotfeK8qG0GNK chxOzvvsh+5EFwJ+nkafOJMxAoUhaGY5ZiuY+n7nZy4713DXpf/vbduBEIUpiaCpAPZj Pkcb4LqWOZOjITC9CsSjOdgJ8SHMIKKJ8JMYYFu9/+bSXd6If7pKRGy84jW8jk+rdt6s 3f1FS+iQ/+NKqAyvpBdZyMbzTo2DrdPik6KZgaLcjEnlVlG70dmH6UFu7kytLRKP5cNu DKal1WkIheMZJB9bFMKWsmH1O1K0CG2xcoXTjQY0q+m5gJXz5U4cBO0t+NpH6BI0FyUQ 0jEQ==
X-Gm-Message-State: APjAAAXbjdxQA88VsQHNO8oBDv8XfP60aSVAEJBbtUmPDhlgHiulpaHN dAp+hcCiMRfPloSSldzVRseSuZfgyMzpPOWadM9OAq8j
X-Google-Smtp-Source: APXvYqzBKC+hieQ497D1JqY5UaJkIOWi5EBMBSDbYTHh48lbiD84kvILoX8Pp3ezmUA1PGm1+l5dVDzUCxpNuupICUE=
X-Received: by 2002:a19:ca59:: with SMTP id h25mr4211275lfj.27.1576623228593; Tue, 17 Dec 2019 14:53:48 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Tue, 17 Dec 2019 14:53:37 -0800
Message-ID: <>
Subject: Re: Opsdir telechat review of draft-ietf-bfd-vxlan-09
To: =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= <>
Cc:,, rtg-bfd WG <>,
Content-Type: multipart/mixed; boundary="0000000000007c4dc30599ee333b"
Archived-At: <>
X-Mailman-Approved-At: Wed, 18 Dec 2019 06:31:12 -0800
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Dec 2019 22:53:55 -0000

Hi Jurgen,
thank you for the review, questions, and suggestions to improve the
document. I've applied the changes to the working version of the draft. The
attached diff highlights the updates (including those suggested by Adam).
Please find my notes in-line tagged GIM>>,

Best regards,

On Tue, Dec 17, 2019 at 12:05 AM Jürgen Schönwälder via Datatracker <> wrote:

> Reviewer: Jürgen Schönwälder
> Review result: Has Nits
> I have only a limited understanding of VXLAN and BFD technology.
> Hence, some of my question may look odd to the insiders.
> - Never heard of this IPv6 loopback address space before. Is it OK to
>   allocate and use it this way?
GIM>> As Adam had explained, the correct wording for these addresses (and
that is what used in the working version) is "IPv4-mapped IPv4 loopback
addresses". Using an address from this range as the destination IP address
of an OAM packet encapsulated in a tunnel was, to the best of my knowledge,
first defined in RFC 4379 (now RFC 8029). Then RFC 5884 applied it to BFD
over MPLS LSP.

> - Why is echo BFD outside the scope of this document? Can I just turn
>   on echo mode or will extra specifications be needed?
GIM>> I believe that the support of the Echo mode of BFD has not been
requested by the BFD WG. I think that some amount of work to define the use
of Echo BFD over VXLAN may be needed.

> - Nits:
>   OLD
>     Ability to monitor path continuity
>   NEW
>     The ability to monitor path continuity
>   OLD
>     BFD packet MUST be encapsulated
>   NEW
>     BFD packets MUST be encapsulated