RE: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP

John E Drake <jdrake@juniper.net> Tue, 22 October 2019 19:15 UTC

Return-Path: <jdrake@juniper.net>
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 8650E12085C; Tue, 22 Oct 2019 12:15:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 n3_obMUUqtic; Tue, 22 Oct 2019 12:15:47 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE061208B7; Tue, 22 Oct 2019 12:15:45 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9MJ6iub006927; Tue, 22 Oct 2019 12:15:40 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=+xsoJg0kV5WjS5E36dq2HZOPonUR7McFhAnbjwMqnDw=; b=gJVZCVN2xLrbipJPvWHIcUVXklnd59e6+uA4izwHBOAnRT+nKGYWsR93fYoyu9Ovc/M6 l5uCdfxOUWwrqK8FoS80aFCBZR95zQnC/Lv8H+Bn25DGI7Vd8uGb8WdPcwEqKi1vjg3D pBX7PJ4ufeDvZggNuzzkUdQkGseWgLRc7m0I0+NEwdMyDRs53FcPTB1+NmlWDK8/Bomo xwXZ9c/YcrlPwrnOTFBllxUf1aFQEUVqkawUNxj1pmNFTv5guWoXhcFDXv/gbsYPO238 taAbecoG5VdEqPMSxKCK7naNsngc0Hbl0ukQbCx/nQM1L+MKg++HAqugAqmsiNIjvqIu gQ==
Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp2050.outbound.protection.outlook.com [104.47.41.50]) by mx0b-00273201.pphosted.com with ESMTP id 2vsqfthp93-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 22 Oct 2019 12:15:40 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bOA5ApmzphYGVMEVAkDtOGYinhD1s1rcOs/eRaBcX44fO6GedAskL3I6N8SToVQJr2TSTL4H6hopvIbrrjRsHjFqN4r/CwaB+T8eYWGCJVGU6iQ83GImFXRz/2wJtK/GHRrbS3GF+GOn47SNIuBZ+9gOJKnx7JSpjBtEYdTp9C9A4aZ/MOXQFMZ65XODpElNzMnME9q6Wf9OFNzIYzA5Hd18KsDdGqwL0JaNLcA/q8at3i7Y/Hy7dY9eYtezm22+5iEQoK06ospaR23X6ujliLEonYEWtq1bZaKvHhek/dkNwKMTduZISitnXNzWj056Z0ZSmBViwztJbguu2MU3mg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+xsoJg0kV5WjS5E36dq2HZOPonUR7McFhAnbjwMqnDw=; b=dr+fEdyGMC5N8InzVyGKZbydVY6y24bO0QdVUz7dGe5oRxmFtb5uadxtaTP1JLxogUXGjPN/YuXzEztrC72zDUmjHPSwW6JY+LABJGNnqnokYlwB6N2WtYCMleg8rhUyI5z3Yk/dFIdqznTC7vdg6vxAMmwFSmZXC2tr10QE5jSHZn1X6YvRwUBg631M9MXR+FyXlM72Yp082jJoIvrEzKrgbwT1/s0ixzGzY6rjg9K83LDEbuquISViv/V/k7su7Yl1p6Jd5GtLMvniBzuctmBfAwlruT0AKF1CSEuarUzndndGq/nPfUxFPYconsz/g7BW2ogFRNmx8m9G8ht6Ng==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
Received: from CH2PR05MB7078.namprd05.prod.outlook.com (10.186.149.216) by CH2PR05MB7125.namprd05.prod.outlook.com (10.186.148.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.13; Tue, 22 Oct 2019 19:15:37 +0000
Received: from CH2PR05MB7078.namprd05.prod.outlook.com ([fe80::e8a0:7432:4f5c:2fea]) by CH2PR05MB7078.namprd05.prod.outlook.com ([fe80::e8a0:7432:4f5c:2fea%3]) with mapi id 15.20.2387.016; Tue, 22 Oct 2019 19:15:37 +0000
From: John E Drake <jdrake@juniper.net>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Greg Mirsky <gregimirsky@gmail.com>, Anoop Ghanwani <anoop@alumni.duke.edu>
CC: Dinesh Dutt <didutt@gmail.com>, "draft-ietf-bfd-vxlan@ietf.org" <draft-ietf-bfd-vxlan@ietf.org>, NVO3 <nvo3@ietf.org>, Santosh P K <santosh.pallagatti@gmail.com>, Jeffrey Haas <jhaas@pfrc.org>, rtg-bfd WG <rtg-bfd@ietf.org>, "T. Sridhar" <tsridhar@vmware.com>, "xiao.min2@zte.com.cn" <xiao.min2@zte.com.cn>
Subject: RE: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Thread-Topic: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Thread-Index: AQHVefXS4eyCOBU6a0uaC7s/Q49HKqdls0cAgAELsQCAAFSxgIAAAloAgAANtICAAAJBoA==
Content-Class:
Date: Tue, 22 Oct 2019 19:15:36 +0000
Message-ID: <CH2PR05MB707878C5F84A4D6BD74E75CCC7680@CH2PR05MB7078.namprd05.prod.outlook.com>
References: <CACi9rdu8PKsLW_Pq4ww5DEwLL8Bs6Hq1Je_jmAjES4LKBuE8MQ@mail.gmail.com> <201909251039413767352@zte.com.cn> <CACi9rdv-760M8WgZ1mOOOa=yoJqQFP=vdc3xJKLe7wCR18NSvA@mail.gmail.com> <20191021210752.GA8916@pfrc.org> <0e99a541-b2ca-85d4-4a8f-1165cf7ac01e@joelhalpern.com> <CA+-tSzziDc+Tk8AYfOr5-Xn6oO_uqW2C1dRA9LLOBBVmzVhWEQ@mail.gmail.com> <CA+RyBmVcBgeoGc2z5Gv0grv8OY34tyw+T-T-W2vn1O3AxCSQ9Q@mail.gmail.com> <0b45df12-a7c5-3b5c-db59-5a57c8dfd1b7@joelhalpern.com>
In-Reply-To: <0b45df12-a7c5-3b5c-db59-5a57c8dfd1b7@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=jdrake@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-10-22T19:15:34.1619980Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=9154187d-261a-4b97-9135-fa01c9b52fd2; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic
dlp-product: dlpe-windows
dlp-version: 11.2.0.14
dlp-reaction: no-action
x-originating-ip: [71.112.174.114]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: b38530fc-0028-44cb-5f49-08d75724384c
x-ms-traffictypediagnostic: CH2PR05MB7125:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <CH2PR05MB7125A558F6A2ABA0125F94D6C7680@CH2PR05MB7125.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01986AE76B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(136003)(376002)(396003)(346002)(13464003)(199004)(189003)(45074003)(25786009)(66066001)(9686003)(26005)(476003)(76176011)(229853002)(6246003)(19627235002)(99286004)(6506007)(2171002)(11346002)(256004)(486006)(478600001)(6436002)(4326008)(446003)(55016002)(53546011)(7696005)(102836004)(186003)(6306002)(76116006)(66556008)(316002)(8936002)(71200400001)(8676002)(74316002)(3846002)(81156014)(110136005)(81166006)(71190400001)(54906003)(14454004)(2906002)(86362001)(966005)(33656002)(52536014)(6116002)(64756008)(5660300002)(7736002)(7416002)(66446008)(66476007)(66946007)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR05MB7125; H:CH2PR05MB7078.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: iGpcDqMjZ56Wlte71QP8Gvjs5d1wy1/2O4QMtGHPsn4ilsJu7/YGgaiPVuWKczFfdZTIVABvkcNCnilrS8eLdSXySEuk6GmvEqk9gPyQTOegDXBFzHu+pNhBOxyvfJuEqPVMibMwPfQ3UL+Mm8emRLvilSBhRl/6Pd/gHwzSjYux/5JxsPdJOdUQpkhNKEsHphyzV0PcW3PHBgfZ3uTWQIiUe2mqyg15It+Rl2V8eQ5vJ9aOfl3xMuKLpbCxBKBkQaB4i73Isddd/9I732TZhAHyHZuac3dwoZz4xbtHvLSk6q4+HrIjZMi04n8pmU/USQFNjAtg+GnkfgekYpIkVUwK95Fpbv1NX+UGMJxoGuWEwu2JxJQbqiJnCsILwv+Fuu7IoIzzIbhnf4LF6IpH4kbniWUC8WsivYLuRVHNdRUvGzCwhOAmtBHUeWN/NsqTOe7KJhfAOxbIyavRj6opeoo9cG7tV3kbeVHM4Pn63+4=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: b38530fc-0028-44cb-5f49-08d75724384c
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2019 19:15:36.4007 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: nG6pZuKPRyzs+sgepRpMVH9mI8Z7zUiX/+xL+yW4m3Gt2O6Lcz/o5tMmDUKW8nvvFWm4FakMZJGMgKHzTdbi6w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR05MB7125
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-22_03:2019-10-22,2019-10-22 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 mlxlogscore=999 lowpriorityscore=0 priorityscore=1501 mlxscore=0 adultscore=0 malwarescore=0 suspectscore=0 phishscore=0 spamscore=0 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910220160
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/XIuC9zUe96UFfyHywUHikxRoIpI>
X-Mailman-Approved-At: Tue, 22 Oct 2019 14:45:07 -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: Tue, 22 Oct 2019 19:15:50 -0000

Hi,

What is the marginal utility of either 2 or 3?

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: nvo3 <nvo3-bounces@ietf.org> On Behalf Of Joel M. Halpern
> Sent: Tuesday, October 22, 2019 3:07 PM
> To: Greg Mirsky <gregimirsky@gmail.com>om>; Anoop Ghanwani
> <anoop@alumni.duke.edu>
> Cc: Dinesh Dutt <didutt@gmail.com>om>; draft-ietf-bfd-vxlan@ietf.org; NVO3
> <nvo3@ietf.org>rg>; Santosh P K <santosh.pallagatti@gmail.com>om>; Jeffrey Haas
> <jhaas@pfrc.org>rg>; rtg-bfd WG <rtg-bfd@ietf.org>rg>; T. Sridhar
> <tsridhar@vmware.com>om>; xiao.min2@zte.com.cn
> Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
> 
> I do not understand the value of option 2.
> Which is why I asked in my initial review to move to option 1.
> 
> And option 2 requires stealing MAC addresses from the users, which seems to
> me to be a very bad thing that option 1 avoids.
> 
> Yours,
> Joel
> 
> On 10/22/2019 2:17 PM, Greg Mirsky wrote:
> > Hi Anoop, et al.,
> > I agree with your understanding of what is being defined in the
> > current version of the BFD over VxLAN specification. But, as I
> > understand, the WG is discussing the scope before the WGLC is closed.
> > I believe there are three options:
> >
> >  1. single BFD session between two VTEPs  2. single BFD session per
> > VNI between two VTEPs  3. multiple BFD sessions per VNI between two
> > VTEPs
> >
> > The current text reflects #2. Is WG accepts this scope? If not, which
> > option WG would accept?
> >
> > Regards,
> > Greg
> >
> > On Tue, Oct 22, 2019 at 2:09 PM Anoop Ghanwani <anoop@alumni.duke.edu
> > <mailto:anoop@alumni.duke.edu>> wrote:
> >
> >     I concur with Joel's assessment with the following clarifications.
> >
> >     The current document is already capable of monitoring multiple VNIs
> >     between VTEPs.
> >
> >     The issue under discussion was how do we use BFD to monitor multiple
> >     VAPs that use the same VNI between a pair of VTEPs.  The use case
> >     for this is not clear to me, as from my understanding, we cannot
> >     have a situation with multiple VAPs using the same VNI--there is 1:1
> >     mapping between VAP and VNI.
> >
> >     Anoop
> >
> >     On Tue, Oct 22, 2019 at 6:06 AM Joel M. Halpern <jmh@joelhalpern.com
> >     <mailto:jmh@joelhalpern.com>> wrote:
> >
> >           From what I can tell, there are two separate problems.
> >         The document we have is a VTEP-VTEP monitoring document.  There
> >         is no
> >         need for that document to handle the multiple VNI case.
> >         If folks want a protocol for doing BFD monitoring of things
> >         behind the
> >         VTEPs (multiple VNIs), then do that as a separate document.   The
> >         encoding will be a tenant encoding, and thus sesparate from what is
> >         defined in this document.
> >
> >         Yours,
> >         Joel
> >
> >         On 10/21/2019 5:07 PM, Jeffrey Haas wrote:
> >          > Santosh and others,
> >          >
> >          > On Thu, Oct 03, 2019 at 07:50:20PM +0530, Santosh P K wrote:
> >          >>     Thanks for your explanation. This helps a lot. I would
> >         wait for more
> >          >> comments from others to see if this what we need in this
> >         draft to be
> >          >> supported based on that we can provide appropriate sections
> >         in the draft.
> >          >
> >          > The threads on the list have spidered to the point where it
> >         is challenging
> >          > to follow what the current status of the draft is, or should
> >         be.  :-)
> >          >
> >          > However, if I've followed things properly, the question below
> >         is really the
> >          > hinge point on what our encapsulation for BFD over vxlan
> >         should look like.
> >          > Correct?
> >          >
> >          > Essentially, do we or do we not require the ability to permit
> >         multiple BFD
> >          > sessions between distinct VAPs?
> >          >
> >          > If this is so, do we have a sense as to how we should proceed?
> >          >
> >          > -- Jeff
> >          >
> >          > [context preserved below...]
> >          >
> >          >> Santosh P K
> >          >>
> >          >> On Wed, Sep 25, 2019 at 8:10 AM <xiao.min2@zte.com.cn
> >         <mailto:xiao.min2@zte.com.cn>> wrote:
> >          >>
> >          >>> Hi Santosh,
> >          >>>
> >          >>>
> >          >>> With regard to the question whether we should allow
> >         multiple BFD sessions
> >          >>> for the same VNI or not, IMHO we should allow it, more
> >         explanation as
> >          >>> follows.
> >          >>>
> >          >>> Below is a figure derived from figure 2 of RFC8014 (An
> >         Architecture for
> >          >>> Data-Center Network Virtualization over Layer 3 (NVO3)).
> >          >>>
> >          >>>                      |         Data Center Network (IP)
> >              |
> >          >>>                      |
> >             |
> >          >>>
> >         +-----------------------------------------+
> >          >>>                           |                           |
> >          >>>                           |       Tunnel Overlay      |
> >          >>>              +------------+---------+
> >           +---------+------------+
> >          >>>              | +----------+-------+ |       |
> >         +-------+----------+ |
> >          >>>              | |  Overlay Module  | |       | |  Overlay
> >         Module  | |
> >          >>>              | +---------+--------+ |       |
> >         +---------+--------+ |
> >          >>>              |           |          |       |           |
> >                  |
> >          >>>       NVE1   |           |          |       |           |
> >                  | NVE2
> >          >>>              |  +--------+-------+  |       |
> >         +--------+-------+  |
> >          >>>              |  |VNI1 VNI2  VNI1 |  |       |  | VNI1 VNI2
> >         VNI1 |  |
> >          >>>              |  +-+-----+----+---+  |       |
> >         +-+-----+-----+--+  |
> >          >>>              |VAP1| VAP2|    | VAP3 |       |VAP1| VAP2|
> >           | VAP3|
> >          >>>              +----+-----+----+------+
> >           +----+-----+-----+-----+
> >          >>>                   |     |    |                   |     |     |
> >          >>>                   |     |    |                   |     |     |
> >          >>>                   |     |    |                   |     |     |
> >          >>>
> >         -------+-----+----+-------------------+-----+-----+-------
> >          >>>                   |     |    |     Tenant        |     |     |
> >          >>>              TSI1 | TSI2|    | TSI3          TSI1| TSI2|
> >           |TSI3
> >          >>>                  +---+ +---+ +---+             +---+ +---+
> >           +---+
> >          >>>                  |TS1| |TS2| |TS3|             |TS4| |TS5|
> >           |TS6|
> >          >>>                  +---+ +---+ +---+             +---+ +---+
> >           +---+
> >          >>>
> >          >>> To my understanding, the BFD sessions between NVE1 and NVE2
> >         are actually
> >          >>> initiated and terminated at VAP of NVE.
> >          >>>
> >          >>> If the network operator want to set up one BFD session
> >         between VAP1 of
> >          >>> NVE1 and VAP1of NVE2, at the same time another BFD session
> >         between VAP3 of
> >          >>> NVE1 and VAP3 of NVE2, although the two BFD sessions are
> >         for the same
> >          >>> VNI1, I believe it's reasonable, so that's why I think we
> >         should allow it
> >
> >         _______________________________________________
> >         nvo3 mailing list
> >         nvo3@ietf.org <mailto:nvo3@ietf.org>
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/nvo3
> > __;!8WoA6RjC81c!TqBnCBob-
> mGlRIth01cY0gBaFxq5GzSZjQh6CW4FENMMATOR6aryer
> > Pnf__xrJY$
> >
> 
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/nvo3__;!8
> WoA6RjC81c!TqBnCBob-
> mGlRIth01cY0gBaFxq5GzSZjQh6CW4FENMMATOR6aryerPnf__xrJY$