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

Anoop Ghanwani <anoop@alumni.duke.edu> Tue, 08 October 2019 04:15 UTC

Return-Path: <ghanwani@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 2D6EC120111; Mon, 7 Oct 2019 21:15:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.476
X-Spam-Level:
X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 ILTnqZvW_W_W; Mon, 7 Oct 2019 21:15:17 -0700 (PDT)
Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) (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 6A1EB1200E3; Mon, 7 Oct 2019 21:15:17 -0700 (PDT)
Received: by mail-vs1-f52.google.com with SMTP id v19so10464573vsv.3; Mon, 07 Oct 2019 21:15:17 -0700 (PDT)
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=SllYUBW2EYjv012pLKDbSw8fKZtUNJF8HQsgfe/pa1c=; b=nlN8hy1U/sdHvUUL7wRhD4nplCzPub9pFJvxnGG5s606jcvigyCYv/TGCQR1Q/UyhU u/mmb3B315A8aPCs6W0TGi9zpOwWonWnFN5eI1HdwsYTwDKMBfcmrJ4Ij//j1qcpwIlw mR2XAv+MsUHeAIg1viJSO+c3MKRmShHNLPzGUWNm0hGDd8KhCMUXOHbcqhheo+r7nNem syM+5mL7BJCgL3Kks/6LMILLoplXUZr5LhV1kzKtKM3mhDgo+bvj8YeO+ifvjsMwqw7h FKn5aGohjR9KXqksYYokuCkQaMy8WcWRYeiiMd3duC4bFDeHv8uTyQa5S5Imkd9RIOmU Rotw==
X-Gm-Message-State: APjAAAU5HYqVjZme8Ic9Epkfn7AmdZJ+Q66wJ1u6kFDo0QimpUOXIOjF WErXeWCFqPLMl6UAtLjzZ3YXgU720QUn9Hz8++M=
X-Google-Smtp-Source: APXvYqy44kyFjVK1E1+8t7JyRh2HiHic9klxaPKmcolV4S35OARjaozUXNTPaHuA+GcqFGyCes2MguN0O5FbgzEe6MM=
X-Received: by 2002:a67:43c5:: with SMTP id q188mr17002575vsa.162.1570508116463; Mon, 07 Oct 2019 21:15:16 -0700 (PDT)
MIME-Version: 1.0
References: <CA+-tSzz-cKRA6G+Q-o2d_bKvmo214ocpLONAtp04LCfMkDYRRA@mail.gmail.com> <201910081028298610829@zte.com.cn>
In-Reply-To: <201910081028298610829@zte.com.cn>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Mon, 7 Oct 2019 21:15:04 -0700
Message-ID: <CA+-tSzwU1-pErVmWDEM6KNv-vTbWNvs12Dd7Rh1wp6e==_X_uw@mail.gmail.com>
Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP
To: xiao.min2@zte.com.cn
Cc: Greg Mirsky <gregimirsky@gmail.com>, didutt@gmail.com, draft-ietf-bfd-vxlan@ietf.org, nvo3@ietf.org, santosh.pallagatti@gmail.com, rtg-bfd WG <rtg-bfd@ietf.org>, "Joel M. Halpern" <jmh@joelhalpern.com>, tsridhar@vmware.com
Content-Type: multipart/alternative; boundary="00000000000066175605945e6a32"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/6zY-r1NTrIZcg8l3XvBCisG5wD0>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Oct 2019 04:15:21 -0000

Hi Xiao Min,

Is there a draft that describes MPLS over Geneve?  It sounds like the NVE
is an MPLS router in this case and if you're using the same VNI as you
switch MPLS, then it's a one-armed router.  That doesn't change how BFD
needs to be run between NVEs.

Anoop

On Mon, Oct 7, 2019 at 7:28 PM <xiao.min2@zte.com.cn> wrote:

> Hi Anoop,
>
>
> Sorry for the late response, I just come back from vacation.
>
> The use case is that the network between the VM and the NVE is an MPLS
> network, within which the packet is forwarded basing on MPLS label, but not
> Ethernet MAC address and/or 802.1Q VLAN. When two such kind of MPLS
> networks need to communicate with each other, through a Geneve tunnel, the
> encap I illustrated would be used.
>
>
> Best Regards,
>
> Xiao Min
> 原始邮件
> *发件人:*AnoopGhanwani <anoop@alumni.duke.edu>
> *收件人:*肖敏10093570;
> *抄送人:*Greg Mirsky <gregimirsky@gmail.com>;didutt@gmail.com <
> didutt@gmail.com>;draft-ietf-bfd-vxlan@ietf.org <
> draft-ietf-bfd-vxlan@ietf.org>;nvo3@ietf.org <nvo3@ietf.org>rg>;
> santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com>;rtg-bfd WG <
> rtg-bfd@ietf.org>;Joel M. Halpern <jmh@joelhalpern.com>om>;
> tsridhar@vmware.com <tsridhar@vmware.com>om>;
> *日 期 :*2019年09月28日 05:36
> *主 题 :**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP*
> Hi Xiao Min,
>
> Thanks for the details about the encap but the use case is not clear.  It
> might help if you explain why its necessary to map a physical Ethernet port
> and/or 802.1Q VLAN to the same VNI as an MPLS packet without an L2 header.
>
> Thanks,
> Anoop
>
> On Thu, Sep 26, 2019 at 7:50 PM <xiao.min2@zte.com.cn> wrote:
>
>> Hi Anoop,
>>
>>
>> Due to the fact that a variety of Tunnels could be used under the NVO3 architecture,
>> as an example, below figure illustrates the format of MPLS packet over
>> Geneve Tunnel.
>>
>>     0                   1                   2                   3
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                                                               |
>>    ~                      Outer Ethernet Header                    ~
>>    |                                                               |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                                                               |
>>    ~                        Outer IPvX Header                      ~
>>    |                                                               |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                                                               |
>>    ~                        Outer UDP Header                       ~
>>    |                                                               |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |                                                               |
>>    ~                          Geneve Header                        ~
>>    |                                                               |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
>>    |                                                               |  |
>>    ~                         MPLS Label Stack                      ~  M
>>    |                                                               |  P
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  L
>>    |                                                               |  S
>>    |                                                               |
>>    ~                             Payload                           ~  P
>>    |                                                               |  K
>>    |                                                               |  T
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
>>    |                               FCS                             |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>> Note that in NVO3 working group Greg and I have submitted an individual
>> draft draft-xiao-nvo3-bfd-geneve, which is used to address BFD over Geneve.
>>
>> The intention is to make the two drafts draft-ietf-bfd-vxlan and
>> draft-xiao-nvo3-bfd-geneve aligned, that is to say, we try to define the
>> identical mechanism for the common part of BFD over VxLAN Tunnel and BFD
>> over Geneve Tunnel. For the common part, draft-xiao-nvo3-bfd-geneve would
>> reference to draft-ietf-bfd-vxlan, and for the other part specific to
>> Geneve, we'll define the specific mechanism in draft-xiao-nvo3-bfd-geneve.
>>
>>
>> Hope that clarifies.
>>
>>
>> Best Regards,
>>
>> Xiao Min
>> 原始邮件
>> *发件人:*AnoopGhanwani <anoop@alumni.duke.edu>
>> *收件人:*肖敏10093570;
>> *抄送人:*Greg Mirsky <gregimirsky@gmail.com>;didutt@gmail.com <
>> didutt@gmail.com>;draft-ietf-bfd-vxlan@ietf.org <
>> draft-ietf-bfd-vxlan@ietf.org>;nvo3@ietf.org <nvo3@ietf.org>rg>;
>> santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com>;rtg-bfd WG <
>> rtg-bfd@ietf.org>;Joel M. Halpern <jmh@joelhalpern.com>om>;
>> tsridhar@vmware.com <tsridhar@vmware.com>;bfd-chairs@ietf.org <
>> bfd-chairs@ietf.org>gt;;
>> *日 期 :*2019年09月26日 23:16
>> *主 题 :**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP*
>> Hi Xiao Min,
>> I think we would need more detail around the use case below.  What does
>> the MPLS packet over Tunnel look like?
>>
>> Thanks,
>> Anoop
>>
>> On Wed, Sep 25, 2019 at 11:37 PM <xiao.min2@zte.com.cn> wrote:
>>
>>> Hi Anoop,
>>>
>>>
>>> Thanks for your comments.
>>>
>>> Considering a scenario where TS1 has an MPLS access (i.e. MPLS-Packet
>>> over Tunnel between NVEs) to VNI1, TS3 has an Ethernet access (i.e.
>>> MAC-Frame over Tunnel between NVEs) to VNI1, then how can TS1 and TS3 share
>>> one VAP?
>>>
>>>
>>> Best Regards,
>>>
>>> Xiao Min
>>> 原始邮件
>>> *发件人:*AnoopGhanwani <anoop@alumni.duke.edu>
>>> *收件人:*肖敏10093570;
>>> *抄送人:*Greg Mirsky <gregimirsky@gmail.com>;didutt@gmail.com <
>>> didutt@gmail.com>;draft-ietf-bfd-vxlan@ietf.org <
>>> draft-ietf-bfd-vxlan@ietf.org>;nvo3@ietf.org <nvo3@ietf.org>rg>;
>>> santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com>;rtg-bfd WG <
>>> rtg-bfd@ietf.org>;Joel M. Halpern <jmh@joelhalpern.com>om>;
>>> tsridhar@vmware.com <tsridhar@vmware.com>;bfd-chairs@ietf.org <
>>> bfd-chairs@ietf.org>gt;;
>>> *日 期 :*2019年09月26日 08:36
>>> *主 题 :**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP*
>>> _______________________________________________
>>> nvo3 mailing list
>>> nvo3@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>
>>> >>>
>>> 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.
>>> >>>
>>>
>>> I would be one of those that would argue that they MUST share on VAP if
>>> they connect to the same Virtual Network.  IMO, the NVO3 arch doc should
>>> have been clearer about this.
>>>
>>> Thanks,
>>> Anoop
>>>
>>> On Tue, Sep 24, 2019 at 7:40 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
>>>>
>>>
>>>
>>
>