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

Anoop Ghanwani <anoop@alumni.duke.edu> Fri, 27 September 2019 21:35 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 41980120129; Fri, 27 Sep 2019 14:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 lQVyWLirgfJ4; Fri, 27 Sep 2019 14:35:46 -0700 (PDT)
Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) (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 005F91201E3; Fri, 27 Sep 2019 14:35:45 -0700 (PDT)
Received: by mail-vk1-f172.google.com with SMTP id j21so1523752vki.11; Fri, 27 Sep 2019 14:35:45 -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=YJTaaFy00+9UlClQFw7KCtwC02jOcQaNYgqfVXi+nAI=; b=tjQpU0SzNmj3AQL0jU/RVAZdu7PSdHKSIyxxSIaIzzdFaKbTrDRBOscK0cE8f9reGq AYYXU/j6VyxRdBiTgAavTIHDpEQ4FCOUdLUMoOhMcyoRKRzUN9iMnHMxa6jYkYHCN8ap S8sVXnVk4gz35y0R28G+8tnGpqqPaT6wyr6oTzwz9iFGMbxJAn7HFDU7z563RJvthzYt EzdQgza5jXsNkJmKAQg7uDs7MO+n/1vV6aarjf+y15XnLNASmQ7JXcLAk2Wn1Y0lwrB4 kBluyB/sQu95q8flWN1rsKzqqkjAWnNYTNp19+C57pWJp6hvdIdAWIpWZRp9DyLEr5ER TgDw==
X-Gm-Message-State: APjAAAWuNXc6wECMUbI0D5shbNvHU8SljBIQKO14g4hw9AYf2GCcNjMX 4M54OFSdLgxYlHWFqzh0v1CTEq+Agop1YkqbsGU=
X-Google-Smtp-Source: APXvYqzMBlyqhcGp6WvK9dP+e4ezxqlJBtJ0awnnxaCG74O85efxkz1XWOsfkq5/U9dbrIpj8q49GCkp5ixioO+JJWo=
X-Received: by 2002:a1f:2051:: with SMTP id g78mr1593840vkg.51.1569620144849; Fri, 27 Sep 2019 14:35:44 -0700 (PDT)
MIME-Version: 1.0
References: <CA+-tSzxoPC07Z_Y=LxmLbmC=__NQSK2+r_0jSH53baN+hXExEQ@mail.gmail.com> <201909271049039305172@zte.com.cn>
In-Reply-To: <201909271049039305172@zte.com.cn>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Fri, 27 Sep 2019 14:35:33 -0700
Message-ID: <CA+-tSzz-cKRA6G+Q-o2d_bKvmo214ocpLONAtp04LCfMkDYRRA@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="0000000000002a897505938fabe4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/3UrOhmzGOxSqi3iakKx6y78VRug>
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: Fri, 27 Sep 2019 21:35:50 -0000

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>;
> santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com>;rtg-bfd WG <
> rtg-bfd@ietf.org>;Joel M. Halpern <jmh@joelhalpern.com>;
> tsridhar@vmware.com <tsridhar@vmware.com>;bfd-chairs@ietf.org <
> bfd-chairs@ietf.org>;
> *日 期 :*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>;
>> santosh.pallagatti@gmail.com <santosh.pallagatti@gmail.com>;rtg-bfd WG <
>> rtg-bfd@ietf.org>;Joel M. Halpern <jmh@joelhalpern.com>;
>> tsridhar@vmware.com <tsridhar@vmware.com>;bfd-chairs@ietf.org <
>> bfd-chairs@ietf.org>;
>> *日 期 :*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
>>>
>>
>>
>