Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
Santosh P K <santosh.pallagatti@gmail.com> Thu, 03 October 2019 14:21 UTC
Return-Path: <santosh.pallagatti@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 C30BC1209A0; Thu, 3 Oct 2019 07:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, 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 kbYl2F7Mh9NW; Thu, 3 Oct 2019 07:21:08 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 0466C120977; Thu, 3 Oct 2019 07:21:07 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id r134so1964915lff.12; Thu, 03 Oct 2019 07:21:06 -0700 (PDT)
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=j3GJN6tkZLdYcpgi2xDymML2l8ciAt4Kk8QyZC0aap0=; b=rjsHqevc5IZzJzfminSM/bB8UMVlt8fR/8WXAW56T1z9urE0NIj8+SxeLbEhGQgwwX 0TfRbMRC3XUY5MZJT1F6MNYlUjS20xs7rAsPf5Mlr/xvUXB+LILitL9wIZ9sNHnOP/Co bSWGj7eJ2n9AH7vqF7PHipaI46Tz8cxGYctZrUuZbVmXGhai7ww+aJcEa8hcbQO2SKtu 0DCIlG0I3YKPg2QSNHWEKcm5aMup65513LHRQVwZe7dqHwhJKN+f5oS/MLaqofmh9wPR gmqKbfdzIKMOOn8rbEg+nj8NDjPDVpukaLk8sJPc/Ig2jmKb5L6vLMYTITAgtGYreQLw Qb7w==
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=j3GJN6tkZLdYcpgi2xDymML2l8ciAt4Kk8QyZC0aap0=; b=rSFTPrUpJbAifiPrZpWHtcQnFRHeoQRfFqgPNbJgqNmdCScCeBwpH2SbPtCIdIp1Dd ZB7GZvnmIJa9EaRhHp9AaJRTZ+oohag0l6Qvv3M/nXrlJVsYDRsfqmsR/n2IKavfpgtD Hj/DPNMHqU7ti1RTq33otUHKE1OAXfPuGlhfzyQzpcsIgwZNXymoRLg4TGTSe3haoNCx D8X4D5GUOkfh4ajOJLDH8CO1qrnqXQrgFABwCFOZ2OR4ZPaB241qz8V4zh4yCS7MnPCv DieQJ/Uktbj4bF1QFy0BOGkiBefmfcFOpHJ/5paJYGglTf/g3SG9LtHOGhqu1KNTa2iM RXmg==
X-Gm-Message-State: APjAAAXIKz9hl4DcJXfxQ61kzyBbvf+LrVQBS8DzI/81Yf/BcQbFWUGe UuE+0B5HYlba9HdLXhZjnuVFz+AOgDsDpdCXlrM=
X-Google-Smtp-Source: APXvYqwf6MWnOEE0/N78S+gr65jvM249scdLLosSBOgVBkrQIP9C/GfiI1IMBBLQ0eMPFtIv+tEsJgoHdIzeE8muTNI=
X-Received: by 2002:a19:22cd:: with SMTP id i196mr5767683lfi.160.1570112464872; Thu, 03 Oct 2019 07:21:04 -0700 (PDT)
MIME-Version: 1.0
References: <201909251039413767352@zte.com.cn> <424bb1af-1ae9-5d60-c07c-3e53917821ae@joelhalpern.com>
In-Reply-To: <424bb1af-1ae9-5d60-c07c-3e53917821ae@joelhalpern.com>
From: Santosh P K <santosh.pallagatti@gmail.com>
Date: Thu, 03 Oct 2019 19:50:50 +0530
Message-ID: <CACi9rdtgENUA-Yt8eoMUO1r9+88uFjHm138YN4u3m7kYBgMG9w@mail.gmail.com>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: xiao.min2@zte.com.cn, rtg-bfd WG <rtg-bfd@ietf.org>, nvo3@ietf.org, "T. Sridhar" <tsridhar@vmware.com>, bfd-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b9e85c0594024b8a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/eu6gY31dGqsLnn6hDYQfpJg_ef4>
X-Mailman-Approved-At: Thu, 03 Oct 2019 11:11:26 -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: Thu, 03 Oct 2019 14:21:28 -0000
Joel,
Sure based on how the discussion goes will modify or keep the document
as it is.
Thanks
Santosh P K
On Wed, Sep 25, 2019 at 8:29 AM Joel M. Halpern <jmh@joelhalpern.com> wrote:
> As far as I can tell, the current document we have in front of us is
> explicit that the messages are originated and terminated at the VNI. If
> you want some other behavior, then we need a document that describes
> that behaviors.
>
> Yours,
> Joel
>
> On 9/24/2019 10:39 PM, 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.
> >
> >
> > Of course, in RFC8014 it also says:
> >
> > "Note that two different Tenant Systems (and TSIs) attached to a common
> NVE can share a VAP (e.g., TS1 and TS2 in Figure 2) so long as they connect
> to the same Virtual Network."
> >
> > Some people may argue that all Tenant Systems connecting to the same
> > Virtual Network MUST share one VAP, if that's true, then VAP1 and VAP3
> > should merge into one VAP and my explanation doesn't work. Copying to
> > NVO3 WG to involve more experts, hope for your clarifications and
> comments.
> >
> >
> > Best Regards,
> >
> > Xiao Min
> >
> > 原始邮件
> > *发件人:*SantoshPK <santosh.pallagatti@gmail.com>
> > *收件人:*Greg Mirsky <gregimirsky@gmail.com>;
> > *抄送人:*draft-ietf-bfd-vxlan@ietf.org
> > <draft-ietf-bfd-vxlan@ietf.org>;Dinesh Dutt <didutt@gmail.com>;rtg-bfd
> > WG <rtg-bfd@ietf.org>;Joel M. Halpern <jmh@joelhalpern.com>;T. Sridhar
> > <tsridhar@vmware.com>;bfd-chairs@ietf.org <bfd-chairs@ietf.org>;
> > *日 期 :*2019年09月23日 05:39
> > *主 题 :**Re: BFD over VXLAN: Trapping BFD Control packet at VTEP*
> > Greg,
> > Please see inline reply tagged [SPK]. I have added text requested.
> >
> > Thanks
> > Santosh P K
> >
> > On Fri, Aug 16, 2019 at 4:59 AM Greg Mirsky <gregimirsky@gmail...com
> > <mailto:gregimirsky@gmail.com>> wrote:
> >
> > Hi Santosh,
> > thank you for your comments. Please find my notes in-lined and
> > tagged GIM>>.
> >
> > Regards,
> > Greg
> >
> > On Tue, Aug 13, 2019 at 10:24 PM Santosh P K
> > <santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>
> > wrote:
> >
> > Greg,
> > Thanks for updated version of document. Here are few
> > comments on new draft.
> >
> > Section 4:
> > Destination MAC: This MUST NOT be of one of tenant's MAC
> > addresses. The MAC address MAY be configured, or it
> > MAY be
> > learned via a control plane protocol. The details of
> > how the
> > MAC address is obtained are outside the scope of this
> > document.
> >
> > I think we may need to give background on why we are saying MAC
> > address MUST not be one of tenant's MAC address. Like in this
> > thread we have discussed one of the tenant could have borrowed
> > the same VTEP mac address and we if we have to use BFD then we
> > need to avoid that conflict to ensure BFD packets get observed
> > in the VTEP itself. Should we add a section before 4 to set that
> > context so that above text makes more sense in that context?
> >
> > GIM>> Certainly. Please share the text you'd like to add.
> >
> > [SPK] Proposed text for why we should not use VTEP MAX address as
> > tenant MAC address.
> >
> > "In some scenarios tenant MAC is borrowed from VTEP MAC address. VXLAN
> > BFD MUST terminate BFD session at VTEP and MUST not forward BFD packets
> > to tenants. To terminate VXLAN BFD packets at VTEP, deployment MUST
> > ensure that there are no tenant VM which barrows VTEP MAC address."
> >
> >
> >
> > IP header:
> > Destination IP: IP address MUST NOT be of one of
> > tenant's IP
> > addresses. IP address MAY be selected from the range
> > 127/8 for
> > IPv4, for IPv6 - from the range
> 0:0:0:0:0:FFFF:7F00:0/104.
> >
> > TTL: MUST be set to 1 to ensure that the BFD packet is
> not
> > routed within the L3 underlay network.
> >
> >
> > I think we have added some text to address Sridhar comments on
> > why TTL MUST be 1 and dest IP address MUST be 127/8 range. I see
> > that text is missing now.
> >
> > GIM>> My apologies that I've missed to include the text from another
> > discussion thread. I believe the following would be complete:
> > TTL or Hop Limit: MUST be set to 1 to ensure that the BFD
> > packet is not routed within the Layer 3 underlay network.
> > This
> > addresses the scenario when the inner IP destination
> > address is
> > of VXLAN gateway and there is a router in underlay which
> > removes the VXLAN header, then it is possible to route the
> > packet as VXLAN gateway address is routable address.
> >
> > [SPK] This text looks good.
> >
> >
> > Section 5.1:
> > For such packets, the BFD session MUST be identified
> > using the following three-tuples of fields of the inner
> > header: the
> > source IP, the destination IP, and the source UDP port
> > number present
> > in the IP header carried by the payload of the packet in
> VXLAN
> > encapsulation. If BFD packet is received with non-zero Your
> > Discriminator, then BFD session MUST be demultiplexed only with
> Your
> > Discriminator as the key.
> >
> > Just with 3 tuple we will not be able to demux packet. We need
> > to consider VNI as well if we have multiple BFD session between
> > same pair of VTEP.
> >
> > GIM>> This is one of comments from Carlos we need to address. Your
> > comment have helped me to form the question:
> >
> > What is the goal running multiple BFD sessions between the pair
> > of VTEPs?
> >
> > [SPK] The goal of the multiple BFD session is to ensure check liveliness
> > of VXLAN tunnel. There is already a good amount of debate on this topic
> > that do we really need that? As per RFC 5884 we are running BFD per LSP
> > and we might hit scale issues there too. I think it is up to operator to
> > decide how they want to use multiple BFD session per VXLAN tunnel. It
> > could be possible that BFD session with special VNI is run at aggressive
> > interval where as MAY have multiple BFD sessions for different VNI at a
> > sedate interval, for that matter they could be running in demand mode as
> > well (run P/F sequence only when there is no data following for that
> > VNI). As WG if we think running multiple BFD session make sense then we
> > might need to add appropriate text.
> >
> > If the goal is to monitor per VNI, then the following text should
> > describe the demultiplexing of the initial BFD Control packet:
> > Demultiplexing of IP BFD packet has been defined in Section 3 of
> > [RFC5881]. Since multiple BFD sessions may be running between
> two
> > VTEPs, there needs to be a mechanism for demultiplexing received
> BFD
> > packets to the proper session. For demultiplexing packets with
> Your
> > Discriminator equal to 0, a BFD session MUST be identified using
> the
> > logical link over which the BFD Control packet is received. In
> the
> > case of VXLAN, the VNI number identifies that logical link. If
> BFD
> > packet is received with non-zero Your Discriminator, then BFD
> > session
> > MUST be demultiplexed only with Your Discriminator as the key.
> >
> > [SPK] I think this text for multiple BFD session between same pair of
> > VTEPs for multiple VNI makes sense only if as WG we think that could be
> > use case.
> >
> > Would there be need to run multiple BFD sessions with the same VNI
> > number?
> >
> >
> > [SPK] IMHO we should not allow multiple BFD session for the same VNI.
> >
> >
> >
> >
> > Thanks
> > Santosh P K
> >
> >
> > On Fri, Aug 9, 2019 at 4:27 AM Greg Mirsky
> > <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> wrote:
> >
> > Dinesh, thank you for your help, much appreciated.
> > Hi Joel and Sridhar,
> > could you please check if the updated text on the inner
> > Ethernet frame addressed your concern.
> >
> > On Wed, Aug 7, 2019 at 2:25 PM Dinesh Dutt <didutt@gmail.com
> > <mailto:didutt@gmail.com>> wrote:
> >
> > Looks god to me Greg. Thank you for your hard work in
> this,
> >
> > Dinesh
> >
> > On Wed, Aug 7, 2019 at 9:25 AM Greg Mirsky
> > <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
> > wrote:
> >
> > Hi Dinesh, Joel, Sridhar, et al.,
> > much appreciate the help you've given me sharing
> > your expertise. I hope that the updates you will
> > find in the attached diff and the working copy of
> > the draft be closer to the acceptable solution for
> > VTEP-VTEP BFD. Please note, that I'll shortly start
> > a new discussion thread to address one of Carlos's
> > questions on the ambiguity of the text on multiple
> > concurrent sessions between the same pair of VTEPs.
> > Please review the changes to Sections 4 and 6 and
> > share your feedback, suggestions, and questions.
> >
> > Regards,
> > Greg
> >
> > On Mon, Aug 5, 2019 at 6:03 PM Dinesh Dutt
> > <didutt@gmail.com <mailto:didutt@gmail.com>> wrote:
> >
> >
> >
> > On Mon, Aug 5, 2019 at 5:56 PM Greg Mirsky
> > <gregimirsky@gmail.com
> > <mailto:gregimirsky@gmail.com>> wrote:
> >
> > Hi Dinesh,
> > thank you for your expedient detailed
> response.
> > I believe that the ability to run BFD
> > session up to a tenant (VTEP-VTEP-tenant or
> > tenant-tenant) was never in jeopardy from
> > this specification.
> > I'm trying to provide precise specification
> > on what can be used ad the destination MAC
> > and IP addresses in the inner frame/packet
> > as I believe that likely will help to avoid
> > interoperability issues.
> > I'm interested to learn some more about the
> > "martian checking" function. As you know,
> > martian addresses have been used as
> > destination IP address in LSP Ping and BFD
> > over MPLS LSP and PW. I haven't heard that
> > any silicon feature caused problems for
> > operators using these tools.
> >
> >
> > Interesting. I didn't know this aspect of use
> > with MPLS ping. Did those packets ever go
> > through a firewall though? In any case, maybe
> > suggest the use of those addresses with a
> > statement that this is how LSP does it, but that
> > other MAC/IP pairs are possible as long as the
> > conditions of the endpoint owning the MAC/IP was
> > honored.
> >
> > Dinesh
> >
> >
> > Regards,
> > Greg
> >
> > On Mon, Aug 5, 2019 at 3:59 PM Dinesh Dutt
> > <didutt@gmail.com <mailto:didutt@gmail.com>>
> > wrote:
> >
> > Hi Greg,
> >
> > That we agree on the problem definition
> > is the first step forward. Your original
> > document had my cases covered and so I
> > was surprised by the track this thread
> > took. It doesn't matter, we're back on
> > track.
> >
> > My recommendation is to not worry about
> > specifying the precise MAC/IP address
> > used in the inner header. The addresses
> > chosen MUST ensure that the packet is
> > trapped to the control plane of the VTEP
> > and not escape to the tenant if the BFD
> > is to the VTEP. Any solution MUST also
> > not preclude the use of the BFD by
> > tenant systems for that VNI. There are
> > many ways an implementer can choose to
> > implement this. For example, the inner
> > MAC address is whatever the VTEP
> > implementer would return if ARP'd for
> > the IP address used in the inner header
> > in the given VNI. The implementer can
> > pick a fixed MAC address, one that they
> > own etc. Multiple BFD sessions can be
> > run for testing path connectivity on
> > more than one VNIs. Limits should be in
> > place to avoid overwhelming the receiver
> > with BFD messages (you had words about
> > this in your currently published
> > draft). If the VNI is irrelevant in the
> > test i.e. only the VXLAN pipe at the
> > VTEP is being tested. the user can use
> > any VNI active on the VTEP on which the
> > VTEP owns an IP address.
> >
> > I'm concerned about the use of 127/8
> > address only because of firewalls or
> > implementations that drop packets with
> > these addresses as either the source or
> > destination. For example, on many
> > merchant silicon, I don't believe you
> > can turn off martian checking and drops
> > *only* for VXLAN-encapsulated BFD
> > packets. I don't know what the Linux
> > kernel does today on such packets, for
> > example (or Hyper-V). I'd like a
> > solution that doesn't demand additional
> > or new chip functionality or require
> > additional middle-box hole punch.
> >
> > Why do you feel you MUST to specify the
> > MAC/IP address on the inner packet? What
> > am I missing here?
> >
> > Dinesh
> >
> > On Mon, Aug 5, 2019 at 3:04 PM Greg
> > Mirsky <gregimirsky@gmail.com
> > <mailto:gregimirsky@gmail.com>> wrote:
> >
> > Hi Dinesh,
> > what do you see as the way forward?
> > I agree, that the proposed text
> > doesn't work for multi-VNI
> > concurrent monitoring because these
> > VNIs are tenant's VNIs. And in that
> > case, we need to specify another
> > mechanism to trap the BFD Control
> > packet at VTEP. It seems that VTEP's
> > Ethernet address must be used as the
> > destination MAC address in the inner
> > Ethernet frame. The destination IP
> > address may be either VTEP's address
> > of martian (I do prefer martian).
> > Let me give it try:
> > NEW TEXT:
> >
> > To monitor continuity of the
> > path between two VTEPs, an
> > operator MUST select a VNI
> > number to be used as Management
> > VNI. Management VNI number MUST
> > NOT be one of the tenant's VNIs
> > to prevent sending VXLAN packets
> > received on Management VNI to a
> > tenant. VNI number 1 is
> > RECOMMENDED as the default for
> > Management VNI. [Ed.note: What
> > we set the Destination MAC to?
> > Can it be invalid MAC that MUST
> > be ignored on receipt?]
> >
> > If an implementation supports
> > concurrent monitoring of
> > multiple VNIs, then the value of
> > VNI number MAY be one of
> > tenant's VNIs. The destination
> > MAC address in the inner
> > Ethernet frame encapsulating BFD
> > Control packet MUST be MAC
> > associated with the remote VTEP.
> > The destination IP address of
> > the inner IP packet MUST be
> > selected from the range 127/8
> > for IPv4, and for IPv6 from the
> > range 0:0:0:0:0:FFFF:7F00:0/104.
> > The TTL value in the inner IP
> > header MUST be set to 1.
> >
> > Regards,
> > Greg
> >
> > On Sun, Aug 4, 2019 at 9:07 AM
> > Dinesh Dutt <didutt@gmail.com
> > <mailto:didutt@gmail.com>> wrote:
> >
> > Hi Greg,
> >
> > Thanks for your clarifications.
> > I agree with your sentiment on
> > why you're running BFD over
> > VXLAN between VTEPs. I wasn't
> > arguing against it at all. All I
> > was saying was pointing to the
> > limitations of the use of
> > management VNI. I spoke to some
> > operators who're running EVPN
> > and mentioned the discussion on
> > this thread. They concur that
> > they're using specific VNIs to
> > test connectivity over that VNI
> > between VTEPs to ensure
> > misconfiguration doesn't lead to
> > blackholes. My statements are
> > based in real world operator
> > experience. And I was providing
> > language that ensured packets
> > didn't leak across to tenants
> > when they were destined to VTEPs.
> >
> > Dinesh
> >
> > On Sat, Aug 3, 2019 at 10:34 AM
> > Greg Mirsky
> > <gregimirsky@gmail.com
> > <mailto:gregimirsky@gmail.com>>
> > wrote:
> >
> > Hi Dinesh,
> > many thanks for your
> > detailed updates on how some
> > implementations process
> > VXLAN header and the inner
> > Ethernet frame. These are
> > very helpful in achieving
> > the workable solution for
> > the problem at hand.
> > You've noted that a path
> > between VTEPs may be
> > monitored in the underlay
> > network by merely
> > establishing a BFD session.
> > That is true, but by using
> > BFD with VXLAN encapsulation
> > between the pair of VTEPs we
> > are extending the OAM domain
> > by including, to some
> > extent, VXLAN forwarding
> > engine. Abstract in RFC 5880
> > defines the goal and the
> > domain in which BFD protocol
> > can detect a fault as:
> > This document describes
> > a protocol intended to
> > detect faults in the
> > bidirectional path
> > between two forwarding
> > engines, including
> > interfaces, data
> > link(s), and to the extent
> > possible the forwarding
> > engines themselves, with
> > potentially very low latency.
> > Thus, BFD in the underlay
> > will exercise a part of IP
> > forwarding engine while BFD
> > with VXLAN encapsulation,
> > ran between the same pair of
> > VTEPs, extends the OAM
> > domain. At the same time,
> > defining BFD between tenant
> > systems in outside the goal
> > of this specification. But
> > VXLAN BFD session between
> > VTEPs may be useful in
> > monitoring e2e path between
> > tenants, as described in the
> > update to -07:
> > At the same time, a
> > service layer BFD session
> > may be used between the
> > tenants of VTEPs IP1 and
> > IP2 to provide end-to-end
> > fault management.
> > In such case, for VTEPs
> > BFD control packets of that
> > session are
> > indistinguishable from
> > data packets. If end-to-end
> > defect detection
> > is realized as the set
> > of concatenated OAM domains,
> > e.g., VM1-1 - IP1
> > -- IP2 - VM2-1, then the
> > BFD session over VXLAN
> > between VTEPs SHOULD
> > follow the procedures
> > described in Section 6.8.17
> > [RFC5880].
> > I've attached the current
> > working version of the draft.
> >
> > Regards,
> > Greg
> >
> >
> > On Fri, Aug 2, 2019 at 5:43
> > PM Dinesh Dutt
> > <didutt@gmail.com
> > <mailto:didutt@gmail.com>>
> > wrote:
> >
> > What I mean is "How do
> > you infer that it
> > excludes the case I'm
> > talking about?".
> >
> > Dinesh
> >
> > On Fri, Aug 2, 2019 at
> > 5:41 PM Dinesh Dutt
> > <didutt@gmail.com
> > <mailto:didutt@gmail.com
> >>
> > wrote:
> >
> > The abstract reads
> > this: "
> >
> > This document
> describes the use of the Bidirectional Forwarding
> > Detection (BFD)
> protocol in point-to-point Virtual eXtensible Local
> > Area Network
> (VXLAN) tunnels forming up an overlay network."
> >
> > How do you infer
> > what you said?
> >
> > Dinesh
> >
> >
> > On Fri, Aug 2, 2019
> > at 5:38 PM Joel M.
> > Halpern
> > <jmh@joelhalpern.com
> > <mailto:
> jmh@joelhalpern.com>>
> > wrote:
> >
> > I am going by
> > what the draft
> > says its purpose
> > is. If you
> > (Dinesh) want
> > the draft to
> > fulfill a
> > different
> > purpose, then
> > either ask the
> > chairs to
> > take this draft
> > back to the WG,
> > or write a
> > separate draft.
> > As currently
> > written, the
> > behavior Greg
> > proposed meets
> > the needs, and
> > does so in a way
> > that is
> > consistent with
> > VxLAN.
> >
> > Yours,
> > Joel
> >
> > On 8/2/2019 8:30
> > PM, Dinesh Dutt
> > wrote:
> > > What is the
> > stated purpose
> > of this BFD
> > session? The
> > VTEP
> > reachability is
> > > determined by
> > the underlay, I
> > don't need
> > VXLAN-encaped
> > packet for that.
> > > Do we agree?
> > >
> > > If I want to
> > test the VXLAN
> > encap/decap
> > functionality
> > alone, picking
> any
> > > single VNI
> > maybe fine. But
> > is this all any
> > network operator
> > wants? Why?
> > > In what
> > situations has
> > this been a
> > problem? I
> > suspect
> > operators also
> > > want to
> > verify path
> > continuity over
> > a specific VNI.
> > If you say this
> is
> > > not defined
> > by the document,
> > I disagree
> > because the
> > current version
> > > talks about
> > controlling the
> > number of BFD
> > sessions between
> > the VTEPs
> > > (see section
> > 3). More
> > importantly,
> > this is a real
> > problem that
> > operators
> > > like to
> verify.
> > >
> > > Dinesh
> > >
> > > On Fri, Aug
> > 2, 2019 at 5:08
> > PM Joel M.
> > Halpern
> > <
> jmh@joelhalpern.com
> > <mailto:
> jmh@joelhalpern.com>
> >
> > >
> > <mailto:
> jmh@joelhalpern.com
> > <mailto:
> jmh@joelhalpern.com>>>
> > wrote:
> > >
> > > What is
> > special about
> > the management
> > VNI is precisely
> > that it is NOT a
> > > tenant
> > VNI. The VxLAN
> > administration
> > does know how it
> > allocates VNI to
> > > tenants,
> > and which VNI it
> > has allocated.
> > In contrast, it
> > does not know
> > > which IP
> > addresses or MAC
> > adddresses teh
> > tenant is using
> > or may plan
> > > to use.
> > >
> > > Yours,
> > > Joel
> > >
> > > On
> > 8/2/2019 6:41
> > PM, Dinesh Dutt
> > wrote:
> > > > The
> > assumption of an
> > IP address
> > within any VNI
> > is suspect that
> way.
> > > > What's
> > special about a
> > single VNI, the
> > management VNI?
> > The VTEP IP
> > > >
> > address does not
> > belong in
> > reality in any
> > VNI...
> > > >
> > > > Dinesh
> > > >
> > > > On
> > Fri, Aug 2, 2019
> > at 3:17 PM Joel
> > M. Halpern
> > >
> > <
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
> > > >
> > <mailto:
> jmh@joelhalpern.com
> > <mailto:
> jmh@joelhalpern.com>
> > <mailto:
> jmh@joelhalpern.com
> > <mailto:
> jmh@joelhalpern.com>>>>
> > wrote:
> > > >
> > > >
> > Your response
> > seems to miss
> > two points:
> > > >
> > > >
> > First, the
> > problem you
> > describe is not
> > what the
> > document says
> > > it is
> > > >
> > solving. To
> > the degree it
> > discusses it at
> > all, the document
> > > says "
> > > >
> In
> > > >
> > most cases, a
> > single BFD
> > session is
> > sufficient for
> > the given
> > > VTEP to
> > > >
> > monitor the
> > reachability of
> > a remote VTEP,
> > regardless of the
> > > number of
> > > >
> > VNIs in
> common. "
> > > >
> > > >
> > Second, you
> > assume the
> > existence of an
> > IP address for a
> > VTEP
> > > within a
> > > >
> > VNI. As with
> > the MAC address,
> > the VTEP does
> > not have an IP
> > > address
> > > >
> > within the
> > VNI. Some
> > implementations
> > may have created
> > such a
> > > thing,
> > > > but
> > > >
> > the general
> > construct, as
> > defined to date,
> > does not support
> > such.
> > > >
> > > > In
> > short, you are
> > requiring a
> > behavior that
> > violates the
> > >
> architectural
> > > >
> > structure of
> > overlay /
> > underlay
> > separation, and
> > common
> > > usage.
> > And you
> > > >
> > are doing so
> > to support a use
> > case that the
> > working group
> > has not
> > > >
> > indicated in
> > the document as
> > important.
> > > >
> > > >
> Yours,
> > > >
> Joel
> > > >
> > > > On
> > 8/2/2019 5:01
> > PM, Dinesh Dutt
> > wrote:
> > > > >
> > Joel,
> > > > >
> > > > >
> > You understood
> > correctly.
> > > > >
> > > > >
> > The VNIs may not
> > share fate due
> > to
> >
> misconfiguration. And
> > I
> > > strongly
> > > > >
> > suspect someone
> > will want to use
> > BFD for that
> > because its
> > > about
> > > >
> > checking
> > > > >
> > path continuity
> > as stated by the
> > draft. As long
> > as there's a
> > > >
> > valid IP
> > > > >
> > (because it's
> > BFD) owned by
> > the VTEP in that
> > VNI, you can
> > > use BFD in
> > > > >
> > that VNI. Thats
> > all that you
> > need to
> > dictate. That
> > IP address
> > > >
> > has a MAC
> > > > >
> > address and you
> > can use that on
> > the inner frame.
> > That is
> > > all normal
> > > > >
> > VXLAN
> > processing. The
> > outer IP is
> > always that of
> > the VTEP.
> > > > >
> > > > >
> > Dinesh
> > > > >
> > > > >
> > On Fri, Aug 2,
> > 2019 at 11:03 AM
> > Joel M. Halpern
> > > >
> > <
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
> > >
> > <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>
> > > > >
> > <mailto:
> jmh@joelhalpern.com
> > <mailto:
> jmh@joelhalpern.com>
> > <mailto:
> jmh@joelhalpern.com
> > <mailto:
> jmh@joelhalpern.com>>
> > >
> > <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>>> wrote:
> > > > >
> > > >
> > > If I am
> > reading your
> > various emails
> > correctly Dinesh
> > > (and I
> > > >
> > may have
> > > >
> > > missed
> > something) you
> > are trying to
> > use the MAC
> address
> > > >
> > because you
> > > >
> > > want
> > > >
> > > to be
> > able to send
> > these BFD
> > packets over
> > arbitrary VNI to
> > > >
> > monitor the
> > > >
> > > VNI.
> > That is not a
> > requirement
> > identified in the
> > > document.
> > > > It
> > is not
> > > >
> > > even a
> > problem I
> > understand,
> > since all the
> > VNI between an
> > > >
> > ingress and
> > > >
> > > egress
> > VTEP share fate.
> > > > >
> > > >
> > > Yours,
> > > >
> > > Joel
> > > > >
> > > >
> > > On
> > 8/2/2019 1:44
> > PM, Dinesh Dutt
> > wrote:
> > > >
> > > > Thanks
> > for verifying
> > this. On Linux
> > and hardware
> > > routers
> > > >
> > that I'm
> > > >
> > > aware
> > > >
> > > > of
> > (Cisco circa
> > 2012 and
> > Cumulus), the
> > physical MAC
> > > address is
> > > >
> > > reused
> > > >
> > > > across
> > the VNIs on the
> > VTEP. Did you
> > check on a
> non-VMW
> > > >
> > device?
> > > >
> > > This is
> > > >
> > > > more
> > for my own
> > curiosity.
> > > >
> > > >
> > > >
> > > > To
> > address the
> > general case,
> > can we not
> define a
> > > >
> > well-known (or
> > > >
> > > reserve
> > > >
> > > > one)
> > unicast MAC
> > address for use
> > with VTEP? If
> > the MAC
> > > >
> > address is
> > > >
> > > >
> > configurable in
> > BFD command,
> > this can be moot.
> > > >
> > > >
> > > >
> > > > Dinesh
> > > >
> > > >
> > > >
> > > > On
> > Fri, Aug 2, 2019
> > at 10:27 AM
> > Santosh P K
> > > >
> > > >
> > <
> santosh.pallagatti@gmail.com
> > <mailto:
> santosh.pallagatti@gmail.com>
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>
> > > >
> > <mailto:
> santosh.pallagatti@gmail...com <mailto:santosh.pallagatti@gmail.com>
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>>
> > > >
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>
> > > >
> > <mailto:
> santosh.pallagatti@gmail...com <mailto:santosh.pallagatti@gmail.com>
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>>>
> > > >
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>
> > > >
> > <mailto:
> santosh.pallagatti@gmail...com <mailto:santosh.pallagatti@gmail.com>
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>>
> > > >
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>
> > > >
> > <mailto:
> santosh.pallagatti@gmail...com <mailto:santosh.pallagatti@gmail.com>
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>>>>>
> wrote:
> > > >
> > > >
> > > >
> > > > I
> > have cross
> > checked point
> > raised about MAC
> > address
> > > >
> > usage. It is
> > > >
> > > >
> > possible that
> > tenant could be
> > using physical
> MAC
> > > >
> > address and
> > > >
> > > when a
> > > >
> > > >
> > packet comes
> > with valid VNI
> > with a MAC
> address
> > > that is
> > > >
> being
> > > >
> > > used by
> > > >
> > > >
> > tenant then
> > packet will be
> > sent to that
> tenant.
> > > This rules
> > > >
> > > out the
> > > >
> > > >
> > fact that we
> > could use
> > physical MAC
> > address as
> > > inner
> > > >
> MAC to
> > > >
> > > ensure
> > > >
> > > >
> > packets get
> > terminated at
> > VTEP itself.
> > > >
> > > >
> > > >
> > > >
> Thanks
> > > >
> > > >
> > Santosh P K
> > > >
> > > >
> > > >
> > > > On
> > Wed, Jul 31,
> > 2019 at 11:00 AM
> > Santosh P K
> > > >
> > > >
> > <
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>
> > > >
> > <mailto:
> santosh.pallagatti@gmail...com <mailto:santosh.pallagatti@gmail.com>
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>>
> > > >
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>
> > > >
> > <mailto:
> santosh.pallagatti@gmail...com <mailto:santosh.pallagatti@gmail.com>
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>>>
> > > >
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>
> > > >
> > <mailto:
> santosh.pallagatti@gmail...com <mailto:santosh.pallagatti@gmail.com>
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>>
> > > >
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>
> > > >
> > <mailto:
> santosh.pallagatti@gmail...com <mailto:santosh.pallagatti@gmail.com>
> > >
> > <mailto:
> santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>>>>>>
> > > >
> > > >
> wrote:
> > > >
> > > >
> > > >
> > > >
> > Joel,
> > > >
> > > >
> > Thanks for
> > your inputs. I
> > checked
> > > >
> > implementation
> > within
> > > >
> > > >
> > Vmware.
> > Perhaps I should
> > have been more
> clear
> > > >
> > about MAC
> > > >
> > > address
> > > >
> > > >
> > space while
> > checking
> > internally. I
> > will cross
> > > >
> > check again for
> > > >
> > > >
> > the same and
> > get back on this
> > list.
> > > >
> > > >
> > > >
> > > >
> > Thanks
> > > >
> > > >
> > Santosh P K
> > > >
> > > >
> > > >
> > > >
> > On Wed, Jul
> > 31, 2019 at
> > 10:54 AM Joel M.
> > > Halpern
> > > >
> > > >
> > <
> jmh@joelhalpern.com <mailto:jmh@joelhalpern...com>
> > >
> > <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
> > >
> > <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>
> > > >
> > <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
> > >
> > <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>>
> > > >
> > >
> > <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
> > >
> > <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
> > >
> > <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>
> > > >
> > <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
> > >
> > <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> <mailto:
> jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>>>> wrote:
> > > >
> > > >
> > > >
> > > >
> > Sorry to
> > ask a stupid
> > question. Whose
> > > >
> > implementation?
> > > >
> > > >
> > > >
> > > >
> > The reason
> > I ask is that as
> > far as I
> > > can tell,
> > > >
> > since the
> > > >
> > > >
> > tenant
> > does not
> > > >
> > > >
> > have any
> > control access
> > to the VTEP,
> > > there is
> no
> > > >
> > > reason for
> > > >
> > > >
> > the VTEP to
> > > >
> > > >
> > have a MAC
> > address in the
> > tenant
> > > space.
> > Yes, the
> > > >
> > > device has
> > > >
> > > >
> > a physical
> > > >
> > > >
> > MAC
> > address. But
> > the tenant could
> > well be
> > > >
> > using that MAC
> > > >
> > > >
> > address.
> Yes,
> > > >
> > > >
> > they would
> > be violating the
> > Ethernet spec.
> > > >
> > But the whole
> > > >
> > > >
> > point of
> > > >
> > > >
> >
> > segregation is
> > not to care
> > about such
> > > issues.
> > > >
> > > >
> > > >
> > > >
> > On the
> > other hand, if
> > you tell me that
> > > the VMWare
> > > >
> > > >
> >
> > implementation
> > has an
> > > >
> > > >
> > Ethernet
> > address that is
> > part of the
> tenant
> > > >
> > space, well,
> > > >
> > > >
> > they made
> up
> > > >
> > > >
> > this
> > particular game.
> > > >
> > > >
> > > >
> > > >
> > Yours,
> > > >
> > > >
> > Joel
> > > >
> > > >
> > > >
> > > >
> > On
> > 7/31/2019 1:44
> > PM, Santosh P K
> > wrote:
> > > >
> > > >
> > > I have
> > checked with
> > implementation
> > > in data
> > > >
> path.
> > > >
> > > When we
> > > >
> > > >
> > receive a
> > > >
> > > >
> > > packet
> > with valid VNI
> > then lookup
> > > for MAC
> will
> > > >
> > > happen and
> > > >
> > > >
> > it is VTEP
> own
> > > >
> > > >
> > > MAC
> > then it will be
> > trapped to
> control
> > > >
> > plane for
> > > >
> > > >
> >
> > processing. I
> > think we
> > > >
> > > >
> > > can
> > have following
> > options
> > > >
> > > >
> > > 1.
> > Optional
> > managment VNI
> > > >
> > > >
> > > 2.
> > Mandatory inner
> > MAC set to VTEP
> mac
> > > >
> > > >
> > > 3.
> > Inner IP TTL set
> > to 1 to avoid
> > > >
> > forwarding of
> > packet
> > > >
> > > >
> > via inner
> IP
> > > >
> > > >
> > > address.
> > > >
> > > >
> > >
> > > >
> > > >
> > >
> > > >
> > > >
> > >
> Thoughts?
> > > >
> > > >
> > >
> > > >
> > > >
> > > Thansk
> > > >
> > > >
> > > Santosh
> P K
> > > >
> > > >
> > >
> > > >
> > > >
> > > On Wed,
> > Jul 31, 2019 at
> > 9:20 AM Greg
> > > Mirsky
> > > >
> > > >
> >
> > <
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
> > > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
> > > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>>
> > > >
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>
> > > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>>>
> > > >
> > > >
> > >
> > <mailto:
> gregimirsky@gmail.com
> > <mailto:
> gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
> > > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>
> > > >
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>>
> > > >
> > > >
> >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
> > > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>
> > > >
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
> > > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>>>>> wrote:
> > > >
> > > >
> > >
> > > >
> > > >
> > > Hi
> > Dinesh,
> > > >
> > > >
> > >
> > thank you for
> > your
> consideration
> > > of the
> > > >
> > > proposal
> and
> > > >
> > > >
> > questions.
> > What
> > > >
> > > >
> > >
> > would you see
> > as the scope of
> > > testing
> the
> > > >
> > > >
> >
> > connectivity
> > for the
> > > >
> > > >
> > >
> > specific VNI?
> > If it is
> > > >
> >
> tenant-to-tenant, then
> > > >
> > > VTEPs
> > > >
> > > >
> > will treat
> > these
> > > >
> > > >
> > >
> > packets as
> > regular user
> > frames. More
> > > >
> > likely, these
> > > >
> > > >
> > could be
> > Layer 2
> > > >
> > > >
> > >
> > OAM, e.g. CCM
> > frames. The
> reason
> > > to use
> > > >
> > 127/8 for
> > > >
> > > >
> > IPv4, and
> > > >
> > > >
> > >
> >
> 0:0:0:0:0:FFFF:7F00:0/104 for
> > > IPv6 is
> > > > to
> > safeguard
> > > >
> > > >
> > from
> leaking
> > > >
> > > >
> > >
> > Ethernet
> > frames with BFD
> > Control
> > > packet
> > > > to
> a
> > > >
> > > tenant.
> > > >
> > > >
> > >
> > You've
> > suggested using
> > a MAC
> > > address to
> > > >
> > trap the
> > > >
> > > >
> > control
> > packet at
> > > >
> > > >
> > >
> > VTEP. What
> > that address
> > could be? We
> > > >
> > had proposed
> > > >
> > > >
> > using the
> > > >
> > > >
> > >
> > dedicated MAC
> > and VTEP's MAC
> and
> > > both
> > > >
> raised
> > > >
> > > concerns
> > > >
> > > >
> > among VXLAN
> > > >
> > > >
> > >
> > experts. The
> > idea of using
> > > Management
> > > >
> > VNI may
> > > >
> > > be more
> > > >
> > > >
> > acceptable
> > > >
> > > >
> > >
> > based on its
> > similarity to the
> > > practice
> > > > of
> > using
> > > >
> > > >
> > Management
> > VLAN.
> > > >
> > > >
> > >
> > > >
> > > >
> > >
> > Regards,
> > > >
> > > >
> > > Greg
> > > >
> > > >
> > >
> > > >
> > > >
> > > On
> > Wed, Jul 31,
> > 2019 at 12:03 PM
> > > Dinesh
> > > >
> Dutt
> > > >
> > > >
> >
> > <
> didutt@gmail.com <mailto:didutt@gmail.com>
> > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com>> <mailto:didutt@gmail.com
> <mailto:didutt@gmail.com>
> > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com>>>
> > > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com> <mailto:didutt@gmail.com
> <mailto:didutt@gmail.com>>
> > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com> <mailto:didutt@gmail.com
> <mailto:didutt@gmail.com>>>>
> > > >
> > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com> <mailto:didutt@gmail.com
> <mailto:didutt@gmail.com>>
> > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com> <mailto:didutt@gmail.com
> <mailto:didutt@gmail.com>>>
> > > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com> <mailto:didutt@gmail.com
> <mailto:didutt@gmail.com>>
> > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com> <mailto:didutt@gmail.com
> <mailto:didutt@gmail.com>>>>>
> > > >
> > > >
> > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com>
> > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com>>
> > > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com> <mailto:didutt@gmail.com
> <mailto:didutt@gmail.com>>>
> > > >
> > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com> <mailto:didutt@gmail.com
> <mailto:didutt@gmail.com>>
> > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com> <mailto:didutt@gmail.com
> <mailto:didutt@gmail.com>>>>
> > > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com> <mailto:didutt@gmail.com
> <mailto:didutt@gmail.com>>
> > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com> <mailto:didutt@gmail.com
> <mailto:didutt@gmail.com>>>
> > > >
> > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com> <mailto:didutt@gmail.com
> <mailto:didutt@gmail.com>>
> > >
> > <mailto:
> didutt@gmail.com <mailto:didutt@gmail.com> <mailto:didutt@gmail.com
> <mailto:didutt@gmail.com>>>>>>>
> > > >
> > > >
> > wrote:
> > > >
> > > >
> > >
> > > >
> > > >
> > >
> > Hi Greg,
> > > >
> > > >
> > >
> > > >
> > > >
> > >
> > As long as the
> > inner MAC
> > > address is
> > > >
> such
> > > >
> > > that the
> > > >
> > > >
> > packet is
> > > >
> > > >
> > >
> > trapped to the
> > CPU, it should be
> > > >
> > fine for
> > > >
> > > use as
> > > >
> > > >
> > an inner
> > MAC is
> > > >
> > > >
> > >
> > it not?
> > Stating that is
> > > better
> than
> > > >
> > trying to
> > > >
> > > >
> > force a
> > management
> > > >
> > > >
> > >
> > VNI. What if
> > someone wants
> > > to test
> > > >
> > >
> connectivity
> > > >
> > > >
> > on a
> specific
> > > >
> > > >
> > >
> > VNI? I would
> > not pick a
> > > loopback
> IP
> > > >
> > > address
> for
> > > >
> > > >
> > this since
> > that
> > > >
> > > >
> > >
> > address range
> > is host/node
> local
> > > >
> > only. Is
> > > >
> > > there a
> > > >
> > > >
> > reason
> you're
> > > >
> > > >
> > >
> > not using the
> > VTEP IP as the
> > > inner IP
> > > >
> > > address ?
> > > >
> > > >
> > >
> > > >
> > > >
> > >
> > Dinesh
> > > >
> > > >
> > >
> > > >
> > > >
> > >
> > On Wed, Jul
> > 31, 2019 at 5:48
> AM
> > > >
> > Greg Mirsky
> > > >
> > > >
> > >
> > <
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
> > > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>
> > > >
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>>
> > > >
> > > >
> >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
> > > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>
> > > >
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
> > > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>>> <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
> > > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>
> > > >
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>>
> > > >
> > > >
> >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
> > > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com> <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>
> > > >
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>
> > > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>
> > >
> > <mailto:
> gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>>>>>> wrote:
> > > >
> > > >
> > >
> > > >
> > > >
> > >
> > Dear All,
> > > >
> > > >
> > >
> > thank you
> > for your
> comments,
> > > >
> > >
> > suggestions on
> > > >
> > > >
> > this issue,
> > > >
> > > >
> > >
> > probably
> > the most
> > >
> challenging
> > > >
> > for this
> > > >
> > > >
> >
> > specification.
> > In the
> > > >
> > > >
> > >
> > course of
> > our discussions,
> > > >
> > we've agreed to
> > > >
> > > >
> > abandon the
> > > >
> > > >
> > >
> > request to
> > allocate the
> > > >
> > dedicated MAC
> > > >
> > > address
> > > >
> > > >
> > to be used
> as
> > > >
> > > >
> > >
> > the
> > destination MAC
> > > address in
> > > >
> > the inner
> > > >
> > > >
> > Ethernet
> > frame.
> > > >
> > > >
> > >
> > Also,
> > earlier using VNI
> > > 0 was
> > > >
> > changed from
> > > >
> > > >
> > mandatory
> > to one
> > > >
> > > >
> > >
> > of the
> > options an
> > > >
> > implementation
> may
> > > >
> > > offer to
> > > >
> > > >
> > an
> operator.
> > > >
> > > >
> > >
> > The most
> > recent
> > >
> > discussion was
> > > >
> > whether
> > > >
> > > VTEP's
> > > >
> > > >
> > MAC address
> > > >
> > > >
> > >
> > might be
> > used as the
> > > >
> > destination MAC
> > > >
> > > address
> > > >
> > > >
> > in the
> inner
> > > >
> > > >
> > >
> > Ethernet
> > frame. As I
> > > recall
> > it, the
> > > >
> > > comments
> > > >
> > > >
> > from VXLAN
> > > >
> > > >
> > >
> > experts
> > equally split
> > > with one
> > > >
> for it
> > > >
> > > and one
> > > >
> > > >
> > against.
> Hence
> > > >
> > > >
> > >
> > I would
> > like to propose
> > > a new
> > > >
> > text to
> > > >
> > > resolve
> > > >
> > > >
> > the issue.
> The
> > > >
> > > >
> > >
> > idea is to
> > let an
> > > operator
> > select
> > > >
> > > Management
> > > >
> > > >
> > VNI and use
> > > >
> > > >
> > >
> > that VNI
> > in VXLAN
> > >
> encapsulation
> > > > of
> BFD
> > > >
> > > >
> > Control
> > packets:
> > > >
> > > >
> > >
> > NEW TEXT:
> > > >
> > > >
> > >
> > > >
> > > >
> > >
> > An
> > operator MUST
> > > select a
> VNI
> > > >
> > > number to
> > > >
> > > >
> > be used as
> > > >
> > > >
> > >
> >
> > Management
> > VNI. VXLAN
> > > >
> > packet for
> > > >
> > > >
> > Management
> > VNI MUST NOT
> > > >
> > > >
> > >
> > be
> > sent to a
> > tenant. VNI
> > > >
> > number 1 is
> > > >
> > > >
> >
> > RECOMMENDED as
> the
> > > >
> > > >
> > >
> >
> > default for
> > >
> > Management VNI.
> > > >
> > > >
> > >
> > > >
> > > >
> > >
> > With that
> > new text, what
> > > can be the
> > > >
> > > value of
> > > >
> > > >
> > the
> > destination
> > > >
> > > >
> > >
> > MAC in the
> > inner Ethernet? I
> > > >
> > tend to
> > > >
> > > believe
> > > >
> > > >
> > that it
> can be
> > > >
> > > >
> > >
> > anything
> > and ignored by
> the
> > > >
> > reciever VTEP.
> > > >
> > > >
> > Also, if
> the
> > > >
> > > >
> > >
> > trapping
> > is based on VNI
> > > >
> > number, the
> > > >
> > > >
> >
> > destination IP
> > address
> > > >
> > > >
> > >
> > of the
> > inner IP packet
> > > can from
> > > >
> > the range
> > > >
> > > >
> > 127/8 for
> > IPv4,
> > > >
> > > >
> > >
> > and for
> > IPv6 from the
> range
> > > >
> > > >
> >
> >
> 0:0:0:0:0:FFFF:7F00:0/104. And
> > > >
> > > >
> > >
> > lastly,
> > the TTL to be
> > > set to 1
> (no
> > > >
> > > change
> here).
> > > >
> > > >
> > >
> > > >
> > > >
> > >
> > Much
> > appreciate your
> > > comments,
> > > >
> > >
> > questions, and
> > > >
> > > >
> >
> suggestions.
> > > >
> > > >
> > >
> > > >
> > > >
> > >
> > Best
> regards,
> > > >
> > > >
> > >
> > Greg
> > > >
> > > >
> > >
> > > >
> > > >
> > > > >
> > > >
> > >
> >
> >
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>
- BFD over VXLAN: Trapping BFD Control packet at VT… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Dinesh Dutt
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… T. Sridhar
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: BFD over VXLAN: Trapping BFD Control packet a… Greg Mirsky
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re:BFD over VXLAN: Trapping BFD Control packet at… xiao.min2
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: BFD over VXLAN: Trapping BFD Control packet a… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:BFD over VXLAN: Trapping BFD Control packet at… xiao.min2
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: BFD over VXLAN: Trapping BFD Control packet a… Jeffrey Haas
- Re: BFD over VXLAN: Trapping BFD Control packet a… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- RE: [nvo3] BFD over VXLAN: Trapping BFD Control p… John E Drake
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel Halpern Direct
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re:[nvo3] BFD over VXLAN: Trapping BFD Control pa… xiao.min2
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Dinesh Dutt
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Selvakumar Sivaraj
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Selvakumar Sivaraj
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Jeffrey Haas
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Anoop Ghanwani
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Joel M. Halpern
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Greg Mirsky
- Re: [nvo3] BFD over VXLAN: Trapping BFD Control p… Santosh P K