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

Dinesh Dutt <didutt@gmail.com> Wed, 23 October 2019 01:52 UTC

Return-Path: <didutt@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 0C68E12022C; Tue, 22 Oct 2019 18:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.796
X-Spam-Level:
X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" 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 aSI4Oi6QsIvy; Tue, 22 Oct 2019 18:52:30 -0700 (PDT)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 D6E4E1200CD; Tue, 22 Oct 2019 18:52:30 -0700 (PDT)
Received: by mail-pf1-x434.google.com with SMTP id y5so11842142pfo.4; Tue, 22 Oct 2019 18:52:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:message-id:in-reply-to:references :mime-version; bh=uA7kWDSOr5ce5T8j6teOA1xg+D7wh4fllJ72QMjfbFI=; b=P84qp9Sl/ya0lMxGcVIUM9MtGrEsHKDE1X9yPCJBhPUUwcBIm4Xt7KP/vHzJJNjrbB 4m1/ey+YDD6BOB8c0mivKJVV/fBi+W0cwNfmDJ1iNnvm93TVKJsThhiozsrEwZAL3rhk jY7PR1FklYUie5Q5m1z5tfwZpXZxsLD3qMmyGSjszOH0v4SIysd2uerCAaPyPwHDZVKC 9SieaL9A+ftYRxcYSqsfVdbr+yrRUD+7vdtVQNIZpmOrp2/Vx+6CoZqAnGQJSEnrEKMd 60kvffk/Kop4+xiEQ32bgQD+wZvF1Yh0ohj3WnAyhKwsSneFBERMgWh7kIpwMiXR8Aoq T7Rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:message-id:in-reply-to :references:mime-version; bh=uA7kWDSOr5ce5T8j6teOA1xg+D7wh4fllJ72QMjfbFI=; b=W6FoxPSlm6hraiZ42skp0xWmdsNdaH5R9aXv2WcXqwUaF5E3V2bXzJCqYLgjf1ZgKs zzYn9BbRvvYmR6apLTjow3WHRM/rjVnjZTZ88v9nNLT756cWJfe8YYTo0IgkuIAAFUdG rmlh1AxfpRFeQMR5/BHnhEPYOfvxP+kBKMFyLVN3XzhtuL1Ac1H5A2HJcr5qi0RntU0Y wvXVQCNiT6c37LfjhEPOxxedN/ruvm1VaXgeec8IEP7fIKdIpymk9Nfr2vTnMe4iN8N4 awYsKQCmgd1dOJrnjp3oox2AS8VkyTN5Y56gilFckSTXP8J2axeB9CYSjm3/z15+rljL 41vw==
X-Gm-Message-State: APjAAAWau97ZhlnvaYgMjqiJY0xY3o/1wWey/PvP0iN0x2KVDtz8EFHx LRRWFhm49MFYp2aKQjye5c4=
X-Google-Smtp-Source: APXvYqzINgC9jIfDaYEJ5BPhMJtPb7VJjSsnTAMcS/plSt4RdHKnDXv82T8iv35RM6OPQsu9ubxqpA==
X-Received: by 2002:a17:90a:bc06:: with SMTP id w6mr8248923pjr.138.1571795550121; Tue, 22 Oct 2019 18:52:30 -0700 (PDT)
Received: from [192.168.0.108] ([117.216.128.128]) by smtp.gmail.com with ESMTPSA id j16sm21417335pje.6.2019.10.22.18.52.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Oct 2019 18:52:29 -0700 (PDT)
Date: Wed, 23 Oct 2019 06:52:22 +0500
From: Dinesh Dutt <didutt@gmail.com>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: Anoop Ghanwani <anoop@alumni.duke.edu>
Cc: Greg Mirsky <gregimirsky@gmail.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Jeffrey Haas <jhaas@pfrc.org>, Santosh P K <santosh.pallagatti@gmail.com>, 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
Message-Id: <1571795542.10436.5@smtp.gmail.com>
In-Reply-To: <CA+-tSzyHgspKBfLWZ3C69EBb+-k-POqJ7vG7VoN=g077+qzGBA@mail.gmail.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> <CA+-tSzyHgspKBfLWZ3C69EBb+-k-POqJ7vG7VoN=g077+qzGBA@mail.gmail.com>
X-Mailer: geary/0.12.4
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=-dagu79cbogutom+Tsa/l"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/FUY5128HHJiY2KBaoH86jtOKz34>
X-Mailman-Approved-At: Wed, 23 Oct 2019 11:02:09 -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: Wed, 23 Oct 2019 01:52:33 -0000

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> 
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> 
> 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:
>> single BFD session between two VTEPs
>> single BFD session per VNI between two VTEPs
>> 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> 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> 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> 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
>>>> https://www.ietf.org/mailman/listinfo/nvo3