Re: [bess] BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited

Greg Mirsky <gregimirsky@gmail.com> Wed, 19 December 2018 15:01 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 134AF126C7E; Wed, 19 Dec 2018 07:01:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 v_mboutvuA-4; Wed, 19 Dec 2018 07:01:34 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 84CAF124BE5; Wed, 19 Dec 2018 07:01:33 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id g11-v6so17686559ljk.3; Wed, 19 Dec 2018 07:01:33 -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=njeLZ7oswIvMtQQNu6M4ILi9Uqd3xqz+FCwDxNZeLK0=; b=fexThNLMB0r062ouI2KzVVYEtuaUUSr8ULJoOy9O8b1z/hXrtle6RXmO/46RoSNXO0 wRsCjMEsezsYkilkRwo1aO3y+PsOiMYMKfd6gEQjyRfxiq1EO6YFH5Q/u9y2oNmq90F3 5wxSXdNdXUJwZ9uJgHXOqse4UoBkLW72wOJe+2Gbx0svVZ7GCSvSACwGbbgWSwg2M9Fa +5n0NvCqIqul/g5a6Sxq7aJNOeUKaRb0JgQdiAYvoo4HpzEZV1k4AglmS+QsUReirAxK LY8t8Ei6fY8KKEe3rSkE69CqklKjT05GzUchxkANc+TF0MTc4EH3rC7M0qSPAb38pBkM cujg==
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=njeLZ7oswIvMtQQNu6M4ILi9Uqd3xqz+FCwDxNZeLK0=; b=C8pzF4MlKVT66SH1EQWLWpjxqN+T2Mm4+YUn2IkS1m8J73z6gUUd+USRNYJnM+HMTq aHlPfE04oQUT61nIJD/VATz6bM4XS3V81J+oZHvAvrXtaH0+gTUGETI6ANQ6KFDS7Ui/ NtxC22rVrcQu1fnoSi7rZrFwppWlN4X+6XZ8NEbTMn2qikQ2nKyWshFan+44dn8nPY8I B6ZYbNnym8qGc9TTULdvesvctD9/TisMVm3gzCocppAQ+bgJYKpSSMgbtk0XjaQL4Xqh mzlcIEVSHFrUxExVMk4XghkdLTfTSTrFj7DwlyfwPZDq/0O6VDvAz+pk8JNxMv84ISF4 8aWg==
X-Gm-Message-State: AA+aEWblCJhTvyH8XefSzk5orAFkwR55jqQFgYFpDypD1fJ0lKuT1rpV ejx5myEFIXNxXVTghU4X7Z/HeKnUQswK6nzjScE=
X-Google-Smtp-Source: AFSGD/WRCMH4sbbMANGLqsuPaSzIj/n/PsKi8o2dHZa1VUI1Fz9qpUlFEDKWxhgZiMBMy9vvqBAI7xe/JukY136pRl8=
X-Received: by 2002:a2e:5109:: with SMTP id f9-v6mr4316301ljb.52.1545231691463; Wed, 19 Dec 2018 07:01:31 -0800 (PST)
MIME-Version: 1.0
References: <20181212140145.GA22828@pfrc.org> <CA+-tSzzLZ2e_JA3Z3-iP4btjzLd0gmUwmBUh-ae7p1Kc+0c3gg@mail.gmail.com> <CA+RyBmUw7cm70CwQDiGDijvQ8GZUMt1a0Q_j1WvRXNfJUtUopQ@mail.gmail.com> <CA+-tSzy+A9414GXeCYNvsDwS4j85mLum0ObKU6o3gMASHtSNDg@mail.gmail.com> <B5C4CB21-0BD1-4A05-ACC2-D4F45ACBCD03@cisco.com> <CA+RyBmVboORC3VtU_hTS9QO4Am4Xskdtdofn_+HpdFjNNTKRFQ@mail.gmail.com>
In-Reply-To: <CA+RyBmVboORC3VtU_hTS9QO4Am4Xskdtdofn_+HpdFjNNTKRFQ@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 19 Dec 2018 07:01:20 -0800
Message-ID: <CA+RyBmUFArdMxwW-5Hk6mK7EVJj5PM4HAua6YGN=jrbn4m1HUw@mail.gmail.com>
Subject: Re: [bess] BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Cc: Anoop Ghanwani <anoop@alumni.duke.edu>, rtg-bfd WG <rtg-bfd@ietf.org>, BESS <bess@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000010c291057d614a4b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/g5xxuHcvXTa6XHwX-CK6eGhbtwY>
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: Wed, 19 Dec 2018 15:01:37 -0000

Hi Anoop, et al.,
appreciate your check of the final version of the update to the draft.
Below is the new text as in the working version:
   One use of VXLAN is in data centers interconnecting VMs of a tenant.
   VXLAN addresses requirements of the Layer 2 and Layer 3 data center
   network infrastructure in the presence of VMs in a multi-tenant
   environment, discussed in section 3 [RFC7348], by providing Layer 2
   overlay scheme on a Layer 3 network.  Another use is as an
   encapsulation for Ethernet VPN [RFC8365].

   This document is written assuming the use of VXLAN for virtualized
   hosts and refers to VMs and VTEPs in hypervisors.  However, the
   concepts are equally applicable to non-virtualized hosts attached to
   VTEPs in switches.

Kind regards,
Greg

On Wed, Dec 19, 2018 at 6:28 AM Greg Mirsky <gregimirsky@gmail.com> wrote:

> Hi Anoop,
> thank you for the great text you've contributed. Accepted. I'll update the
> working text and publish later today.
>
> Kind regards,
> Greg
>
> On Wed, Dec 19, 2018 at 5:19 AM Reshad Rahman (rrahman) <rrahman@cisco.com>
> wrote:
>
>> +1 to Anoop's comments. I've made similar comment to Greg privately, and
>> Anoop's proposed text clears things up.
>>
>> Regards,
>> Reshad (no hat).
>>
>> On 2018-12-19, 1:54 AM, "Rtg-bfd on behalf of Anoop Ghanwani" <
>> rtg-bfd-bounces@ietf.org on behalf of anoop@alumni.duke.edu> wrote:
>>
>>     Hi Greg,
>>
>>     Yes this captures what I was trying to get added.
>>
>>     Perhaps the last sentence can be changed to:
>>
>>     "This document is written assuming the use of VXLAN for virtualized
>>     hosts and refers to VMs and VTEPs in hypervisors.  However, the
>>     concepts are equally applicable to non-virtualized hosts attached to
>>     VTEPs in switches."
>>
>>     Thanks,
>>     Anoop
>>
>>     On Tue, Dec 18, 2018 at 12:17 PM Greg Mirsky <gregimirsky@gmail.com>
>> wrote:
>>     >
>>     > Hi Anoop,
>>     > thank you for your comments and the suggested text. To clarify the
>> extent of the update, would the following accurately reflect the change in
>> Introduction you're proposing:
>>     > OLD TEXT:
>>     >    VXLAN is typically deployed in data centers interconnecting
>>     >    virtualized hosts of a tenant.  VXLAN addresses requirements of
>> the
>>     >    Layer 2 and Layer 3 data center network infrastructure in the
>>     >    presence of VMs in a multi-tenant environment, discussed in
>> section 3
>>     >    [RFC7348], by providing Layer 2 overlay scheme on a Layer 3
>> network.
>>     > NEW TEXT:
>>     >   One use of VXLAN is in data centers interconnecting
>>     >   VMs of a tenant.  VXLAN addresses requirements of the
>>     >    Layer 2 and Layer 3 data center network infrastructure in the
>>     >    presence of VMs in a multi-tenant environment, discussed in
>> section 3
>>     >    of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3
>> network.
>>     >    Another use is as an encapsulation for EVPN [RFC 8365].
>>     >
>>     >   In the remainder of this document the terms VM and End Station
>>     >   are used interchangeably.
>>     >
>>     > If my understanding of the proposed update is correct, I'd be glad
>> to use it (adding RFC 8365 as Informational reference).  Should note that
>> in the draft we never used "End Station". Perhaps the last sentence is not
>> required.
>>     >
>>     > What do you think?
>>     >
>>     > Regards,
>>     > Greg
>>     >
>>     > On Tue, Dec 18, 2018 at 10:08 AM Anoop Ghanwani <
>> anoop@alumni.duke.edu> wrote:
>>     >>
>>     >> I would change the introduction to the following to mention the
>> use of
>>     >> VXLAN by BGP EVPN.
>>     >>
>>     >> Thanks,
>>     >> Anoop
>>     >>
>>     >> ==
>>     >>
>>     >>    "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348]
>> provides
>>     >>    an encapsulation scheme that allows building an overlay network
>> by
>>     >>    decoupling the address space of the attached virtual hosts from
>> that
>>     >>    of the network.
>>     >>
>>     >>   One use of VXLAN is in data centers interconnecting
>>     >>   VMs of a tenant.  VXLAN addresses requirements of the
>>     >>    Layer 2 and Layer 3 data center network infrastructure in the
>>     >>    presence of VMs in a multi-tenant environment, discussed in
>> section 3
>>     >>    of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3
>> network.
>>     >>    Another use is as an encapsulation for EVPN [RFC 8365].
>>     >>
>>     >>   In the remainder of this document the terms VM and End Station
>>     >>   are used interchangeably.
>>     >>
>>     >>    In the absence of a router in the overlay, a VM can communicate
>> with
>>     >>    another VM only if they are on the same VXLAN segment.  VMs are
>>     >>    unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a
>> VXLAN
>>     >>    Tunnel End Point (VTEP) (hypervisor/TOR).  VTEPs
>> (hypervisor/TOR) are
>>     >>    responsible for encapsulating and decapsulating frames exchanged
>>     >>    among VMs.
>>     >>
>>     >> On Wed, Dec 12, 2018 at 6:02 AM Jeffrey Haas <jhaas@pfrc.org>
>> wrote:
>>     >> >
>>     >> > BESS Working Group members,
>>     >> >
>>     >> > https://tools.ietf.org/html/draft-ietf-bfd-vxlan-04
>>     >> >
>>     >> > BFD has finished working group last call on BFD for Vxlan and is
>> about ready
>>     >> > to request publication as an RFC.  A last minute comment
>> suggested that we
>>     >> > should consider inviting comment from your working group for
>> expertise.
>>     >> >
>>     >> > We will be leaving the last call open until December 21 to leave
>> time for
>>     >> > final comments.
>>     >> >
>>     >> > -- Jeff (for BFD)
>>     >> >
>>     >> > _______________________________________________
>>     >> > BESS mailing list
>>     >> > BESS@ietf.org
>>     >> > https://www.ietf.org/mailman/listinfo/bess
>>     >>
>>     >> _______________________________________________
>>     >> BESS mailing list
>>     >> BESS@ietf.org
>>     >> https://www.ietf.org/mailman/listinfo/bess
>>
>>
>>
>>