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

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Wed, 19 December 2018 13:19 UTC

Return-Path: <rrahman@cisco.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F46128766; Wed, 19 Dec 2018 05:19:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.566
X-Spam-Level:
X-Spam-Status: No, score=-14.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 dB1p37OesNO2; Wed, 19 Dec 2018 05:19:01 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBED4126CB6; Wed, 19 Dec 2018 05:19:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6474; q=dns/txt; s=iport; t=1545225541; x=1546435141; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ckrOaCd/aw5fGx2SF2azkQJCfWcD8ivXrMMl4q+jYSM=; b=XkvBa8bLgQgP2lSroeLSu75hzDqjhUY/yLKRNUD7OsltEKEvQBfqcaLg gq+o/haB5XaWBRIhX2eFMbfauL72i8C7EyjT/g49FnIcogMBiJBEA3Bmy bV69uzu3V+PfOicjoAevA1VxXdYW9QV/DtOUJkc2bH2XDHWlVJx/Yt2Yb M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAAAyRBpc/4ENJK1kDgsBAQEBAQEBAQEBAQEHAQEBAQEBgVEEAQEBAQELAYIDZoECJwqDc4gZi3yCDYkVjkiBewsBARgLhEkCF4JSIjQJDQEDAQECAQECbRwMhT0BAQEDAQEhETcDCxACAQgYAgImAgICHwYLFRACBAENBYMiAYFpAxUPp1GBL4QxAoENgkUNghgFgQuLNBeBQD+BEScfgkyCV0cBAQOBXheCcTGCJgKhATMJAocOhyGDMRiBXo97iUiBBYN0gROKBwIRFIEnHziBVnAVOyoBgkGLHIUEO0ExjUiBHwEB
X-IronPort-AV: E=Sophos;i="5.56,372,1539648000"; d="scan'208";a="215372905"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2018 13:18:59 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id wBJDIxxm019653 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Dec 2018 13:18:59 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 19 Dec 2018 07:18:58 -0600
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Wed, 19 Dec 2018 07:18:59 -0600
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Anoop Ghanwani <anoop@alumni.duke.edu>, Greg Mirsky <gregimirsky@gmail.com>
CC: rtg-bfd WG <rtg-bfd@ietf.org>, BESS <bess@ietf.org>
Thread-Topic: [bess] BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited
Thread-Index: AQHUkiOST4L9fHttUESm2QYbnfiVh6WFOaKAgAAj7oCAALH0AIAAF8QA
Date: Wed, 19 Dec 2018 13:18:59 +0000
Message-ID: <B5C4CB21-0BD1-4A05-ACC2-D4F45ACBCD03@cisco.com>
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>
In-Reply-To: <CA+-tSzy+A9414GXeCYNvsDwS4j85mLum0ObKU6o3gMASHtSNDg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.4.181110
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.242.49]
Content-Type: text/plain; charset="utf-8"
Content-ID: <4B10B94606BAAC45AC9A87D14B3A16F6@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/2U-9icbGRgws09fZvENONlnj9HU>
Subject: Re: [bess] BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Dec 2018 13:19:04 -0000

+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