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

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 28 October 2019 17:46 UTC

Return-Path: <jmh@joelhalpern.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 A1DBE1208E7; Mon, 28 Oct 2019 10:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 gpSRA32frDr1; Mon, 28 Oct 2019 10:46:18 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 A06AE12080C; Mon, 28 Oct 2019 10:46:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4722Fk3tyqzdjLj; Mon, 28 Oct 2019 10:46:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1572284778; bh=HZPNqmPT5HuCAb/PqNdyNkMuNZTBlUKt4jS6uq5n3kM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=MGNRzWaxAPcsVx6LjLbv8aFPDrw18zQ6Q/f4lIHYGnw4hdZraG7Nn87CIdFDCu20k uACpiRatXpAj7dqiOgZuSY7Fes8k2CgL3soc7iysmvuYCxVsY85+cRLykG1RBggKm/ tVHt05TOd4WUgaPD0DdGoARy/38/gBT3zwXkLZQs=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4722Fj0JJJzdjLg; Mon, 28 Oct 2019 10:46:16 -0700 (PDT)
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Anoop Ghanwani <anoop@alumni.duke.edu>
Cc: Santosh P K <santosh.pallagatti@gmail.com>, Dinesh Dutt <didutt@gmail.com>, Greg Mirsky <gregimirsky@gmail.com>, Jeffrey Haas <jhaas@pfrc.org>, NVO3 <nvo3@ietf.org>, draft-ietf-bfd-vxlan@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>, "T. Sridhar" <tsridhar@vmware.com>, xiao.min2@zte.com.cn
References: <CACi9rdu8PKsLW_Pq4ww5DEwLL8Bs6Hq1Je_jmAjES4LKBuE8MQ@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> <CA+-tSzyHgspKBfLWZ3C69EBb+-k-POqJ7vG7VoN=g077+qzGBA@mail.gmail.com> <1571795542.10436.5@smtp.gmail.com> <CA+RyBmXkyQMumeCDxM6OSzdn=DCL=aeyQ+tJmUiyEg0VZuUpRg@mail.gmail.com> <1571798869.2855.1@smtp.gmail.com> <CACi9rduyvhweJd_aNx6miiUGyu-nCeqnNHGbPjyCfswHx1RD5A@mail.gmail.com> <CA+RyBmXLBLARxhA4MUvD6DE8vvY1oDP0opkxDqiPA4zYw9Jpug@mail.gmail.com> <1571860470.2855.11@smtp.gmail.com> <CACi9rdtwiuH2VjuUkzeg3+PhwcFMSqFepbcM0tgmRxSbcR3AQQ@mail.gmail.com> <CA+-tSzyi=uDdqSDq4u7kytAucX136mO2XtPtR=DG+KKAC5PjCQ@mail.gmail.com> <88a1320e-093a-a101-d8a6-6ae6d7648466@joelhalpern.com> <CA+-tSzxCpLOmhpBXP1k5vLY20qA5db9nbq4qEiH00jo=EH+w8g@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <d7b25f3a-5f1e-30da-8a41-0d11e3c2d04c@joelhalpern.com>
Date: Mon, 28 Oct 2019 13:46:15 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CA+-tSzxCpLOmhpBXP1k5vLY20qA5db9nbq4qEiH00jo=EH+w8g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/DFTfljNDHxd2cO3kr8eL96-lboU>
X-Mailman-Approved-At: Mon, 28 Oct 2019 11:38:17 -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, 28 Oct 2019 17:46:31 -0000

I can live with saying that you SHOULD use loopback, and MAY instead use 
an IP address in the customer space known to be owned by the VTEP device 
when such exists.

Yours,
Joel

On 10/28/2019 1:32 PM, Anoop Ghanwani wrote:
> Hi Joel,
> 
> Perhaps we need to say use of an address owned by the device containing 
> the VTEP.
> 
> Or are you suggesting that the use of the loopback address space is a MUST?
> 
> Anoop
> 
> On Mon, Oct 28, 2019 at 10:22 AM Joel M. Halpern <jmh@joelhalpern.com 
> <mailto:jmh@joelhalpern.com>> wrote:
> 
>     There is something I am missing in your assumption about IRB.
> 
>     As I understand VxLAN, the VTEP is under the control of the operator.
>     As such, it is a pure bridge.  If you run IRB behind it, that is fine.
>     Yes, an operator may offer IRB.  But as I understand it,  conceptually,
>     in terms of the VxLAN architecture the IRB is an entity behind the
>     VTEP,
>     not part of the VTEP.
> 
>     Yours,
>     Joel
> 
>     On 10/28/2019 12:23 PM, Anoop Ghanwani wrote:
>      > Santosh,
>      >
>      > Does it have to be a MUST?  What if I am running IRB and there
>     are IP
>      > addresses per VNI assigned to the VTEPs?  Why can the operator not
>      > choose to use those?
>      >
>      > Anoop
>      >
>      > On Mon, Oct 28, 2019 at 7:51 AM Santosh P K
>      > <santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>
>     <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>>> wrote:
>      >
>      >     Dinesh, Anoop et all,
>      >           Lets us know if this text works for 127/8 address range?
>      >
>      >     [proposed text for firewall]
>      >
>      >     "As per section 4 inner destination IP address MUST be set to
>     127/8
>      >     address. There may be firewall configured on VTEP to block 127/8
>      >     address range if set as destination IP in inner IP header. It is
>      >     recommended to allow 127/8 range address through firewall only if
>      >     127/8 IP address is set as destination address in inner IP
>     header."
>      >
>      >
>      >     In section 4 we are talking about using 127/8 and not really
>     giving
>      >     reason why. I think we should have text as RFC 5884 has mentioned
>      >     with below text.
>      >
>      >     [From RFC 5884]
>      >     "The motivation for using the address range 127/8 is the same as
>      >     specified in Section 2.1 of [RFC4379]
>      >     <https://tools.ietf.org/html/rfc4379#section-2.1>. This is an
>      >     exception to the behavior defined in [RFC1122
>      >     <https://tools.ietf.org/html/rfc1122>]."
>      >
>      >
>      >
>      >     Thanks
>      >     Santosh P K
>      >
>      >
>      >
>      >     On Thu, Oct 24, 2019 at 1:24 AM Dinesh Dutt <didutt@gmail.com
>     <mailto:didutt@gmail.com>
>      >     <mailto:didutt@gmail.com <mailto:didutt@gmail.com>>> wrote:
>      >
>      >         Looks good to me Greg. I see that the text around the use
>     of the
>      >         inner IP address as also quite acceptable. Will you add any
>      >         words about the firewall?
>      >
>      >         Dinesh
>      >
>      >         On Wed, Oct 23, 2019 at 8:36 PM, Greg Mirsky
>      >         <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
>     <mailto:gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>> wrote:
>      >>         Hi Dinesh, et al.,
>      >>         please check the updated version that removed the
>     reference to
>      >>         Hypervisor in the text and Figure 1.
>      >>
>      >>         Regards,
>      >>         Greg
>      >>
>      >>         On Wed, Oct 23, 2019 at 10:47 AM Santosh P K
>      >>         <santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>
>      >>         <mailto:santosh.pallagatti@gmail.com
>     <mailto:santosh.pallagatti@gmail.com>>> wrote:
>      >>
>      >>             Dinesh,
>      >>                  Please see my inline comments [SPK]
>      >>
>      >>
>      >>                 - In section 3, there's a sentence that is: "BFD
>      >>                 packets intended for a Hypervisor VTEP MUST
>     NOT..". I
>      >>                 recommend getting rid of the word "Hypervisor" ashe
>      >>                 logic applies to any VTEP.
>      >>
>      >>             [SPK] Thanks for comments. We will change this.
>      >>
>      >>                 - You already explained the precedence of the use of
>      >>                 127/8 address in the inner header in MPLS. I have no
>      >>                 specific comments in that area. I have only two
>      >>                 questions:
>      >>                    - Has anybody verified that the use of 127/8
>      >>                 address (and the right MAC) works with existing
>      >>                 implementations, including the silicon ones? If this
>      >>                 doesn't work there, is it worth adding the
>     possibilit
>      >>                 y of another address, one that is owned by the
>     VTEP node?
>      >>
>      >>                    - Do we know if Firewalls stop such VXLAN
>     packets?
>      >>                 I ask this because VXLAN has an IP header and I
>     don't
>      >>                 know if firewalls stop packets with 127/8 in the
>     inner
>      >>                 header. If not, is it worth adding a sentence to say
>      >>                 that firewalls  allow such packets? The use of a
>      >>                 non-127/8 address may alleviate this case as well.
>      >>
>      >>             [SPK] I think we may need to add the text about firewall
>      >>             as some checks in firewall will be there if they are not
>      >>             already using MPLS OAM which has inner IP header with
>      >>             127/8 address range.
>      >>
>      >>
>      >>                 The rest of the draft looks good to me,
>      >>
>      >>                 Dinesh
>      >>
>      >>                 On Wed, Oct 23, 2019 at 7:58 AM, Greg Mirsky
>      >>                 <gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com> <mailto:gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com>>>
>      >>                 wrote:
>      >>>                 Hi Dinesh,
>      >>>                 I greatly appreciate your comments. Please heave a
>      >>>                 look at the attached copy of the working
>     version and
>      >>>                 its diff to -07 (latest in the datatracker).
>      >>>
>      >>>                 Regards,
>      >>>                 Greg
>      >>>
>      >>>                 On Tue, Oct 22, 2019 at 9:52 PM Dinesh Dutt
>      >>>                 <didutt@gmail.com <mailto:didutt@gmail.com>
>     <mailto:didutt@gmail.com <mailto:didutt@gmail.com>>> wrote:
>      >>>
>      >>>                     I have the same feeling as Anoop. Greg, can you
>      >>>                     please point me to the latest draft so that
>     I can
>      >>>                     quickly glance through it to be doubly sure,
>      >>>
>      >>>                     Dinesh
>      >>>
>      >>>                     On Wed, Oct 23, 2019 at 4:35 AM, Anoop Ghanwani
>      >>>                     <anoop@alumni.duke.edu
>     <mailto:anoop@alumni.duke.edu>
>      >>>                     <mailto:anoop@alumni.duke.edu
>     <mailto:anoop@alumni.duke.edu>>> wrote:
>      >>>>                     Greg,
>      >>>>
>      >>>>                     I think the draft is fine as is.
>      >>>>
>      >>>>                     I discussion with Xiao Min was about #3 and I
>      >>>>                     see that as unnecessary until we have a draft
>      >>>>                     that explains why that is needed in the
>     context
>      >>>>                     of the NVO3 architecture.
>      >>>>
>      >>>>                     Anoop
>      >>>>
>      >>>>                     On Tue, Oct 22, 2019 at 11:17 AM Greg Mirsky
>      >>>>                     <gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com>
>      >>>>                     <mailto:gregimirsky@gmail.com
>     <mailto:gregimirsky@gmail.com>>> 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>
>      >>>>                         <mailto: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>
>      >>>>                             <mailto: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>
>      >>>>                                 <mailto: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> <mailto:nvo3@ietf.org
>     <mailto:nvo3@ietf.org>>
>      >>>> https://www.ietf.org/mailman/listinfo/nvo3
>      >>>>
>