Re: Rtgdir last call review of draft-ietf-bfd-vxlan-07

Greg Mirsky <gregimirsky@gmail.com> Thu, 06 June 2019 01:55 UTC

Return-Path: <gregimirsky@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 5BB42120148; Wed, 5 Jun 2019 18:55:58 -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 sz4K2jZd-FoO; Wed, 5 Jun 2019 18:55:55 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 C74BE120130; Wed, 5 Jun 2019 18:55:54 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id v18so446175ljh.6; Wed, 05 Jun 2019 18:55:54 -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=RdZXByvPbjW9iuktL1dJ9lzp9sCzQSmGjGA2S8ccPiY=; b=GctEbuhMNorSezERch64qze2nFx3uyGmxnpxl4426pjHSJyC5jFDVRBJjpqyeVgC96 dxAHL0j2GIBE+wiHRaqUY7O40Z5U2bDfx+88+THwHOwzZ38BZum4/UHl/Fiz0dVGb3nn QXA4kDr0ab0CrZeQQKjCN3WUDeD7a5D+yY+aaYwHOO2yXnM4JYlyRXImcsZg57tQMezY 6iFzC7/roaCdNEouwfHKL23zcMst2UXxZdbcIy5EmmIAqn+jct39N7BuEv6K9oCbMUVh JGD5ylrjkJxCm5woC//vwpxO1GqmLVxIqss9UExkACWjLc8HNeU/Cjob3adBUPNYHVcD c2Tg==
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=RdZXByvPbjW9iuktL1dJ9lzp9sCzQSmGjGA2S8ccPiY=; b=kNhPo0iS7dgTve42gUeNhy1xvakNG2mCE9DWCLRk1Na7ig4pGj1DlkJnTfzYOrBoJn R4JwJK/5BOAwEFpiLy8aYqF3WB6tav8gi3Wy9zx06cBjMR2rwxTJhVYb0Ai2YulI1tuD rNL2Yalhb80LiNGrp3BOm8jiOuzmADCV/qnx9yxu3ZHS9QUF7hQQPbPHyATqOCMKRhKO 4TMPIU1kp30mUQnSfAZoBHpVBPwtfWc51IadAZ9UAR0q+xdlVDQWZ26iTdDKJ2zD0ezA ylwzmHefF2L9x1Y1RVSuw7wGOy8MiRyYTssLm4TnLN97G5JU3d9lkYj0dyBTcK7Ir4rH pXig==
X-Gm-Message-State: APjAAAXUiue4Ea9MU92wR5IwxLzrmF8uUEyTiEHZ7rlvQiUuIRNKWyvY uJr02dyrFd8RC/qx4uR2AiUlTDiRfWWcwVBPuObHgCOnX9EWEQ==
X-Google-Smtp-Source: APXvYqy9XH/ATJO8yrpGa3KMlIyvKUE4mN2z8n0MShS1nsjYpoCb+o3DOLfphHunImcgelmtu8V1KFIpohFaIW0IJJY=
X-Received: by 2002:a2e:96c3:: with SMTP id d3mr11250883ljj.68.1559786152870; Wed, 05 Jun 2019 18:55:52 -0700 (PDT)
MIME-Version: 1.0
References: <155864919758.8626.11137277913302380197@ietfa.amsl.com> <CA+RyBmXO5tYtrm_79KOKJmTp2mbYwynze20EoJA=2gGnJ5jEsw@mail.gmail.com> <98825f67-6958-8845-d5d5-3e0ac5e996e1@joelhalpern.com>
In-Reply-To: <98825f67-6958-8845-d5d5-3e0ac5e996e1@joelhalpern.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 5 Jun 2019 18:55:42 -0700
Message-ID: <CA+RyBmXmuL+v55SEgHfx-E=bkpLSZe4ceZG5k6e4R=QSuWQ=Ag@mail.gmail.com>
Subject: Re: Rtgdir last call review of draft-ietf-bfd-vxlan-07
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: rtg-dir@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>, draft-ietf-bfd-vxlan.all@ietf.org, IETF list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009146e9058a9e0352"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/pp9z-PLRwVNVu4kAOz66aB1yW6E>
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, 06 Jun 2019 01:55:58 -0000

Hi Joel,
I cannot find the text in RFC 7348 that suggests that any
VXLAN-encapsulated frame received by VTEP must be forwarded to a VM
associated with the specified VNI. But I've found the text in section 4.1
that makes the forwarding of the inner frame to VM conditional to the
destination MAC address matching to VM's MAC:
   Upon reception, the remote VTEP
   verifies the validity of the VNI and whether or not there is a VM on
   that VNI using a MAC address that matches the inner destination MAC
   address.  If so, the packet is stripped of its encapsulating headers
   and passed on to the destination VM.
BFD over VXLAN specification in section 5 clarifies the processing of the
received VXLAN packet by the remote VXLAN:
   Once a packet is received, VTEP MUST validate the packet.  If the
   Destination MAC of the inner MAC frame matches the MAC address of the
   VTEP the packet MUST be processed further.

   The UDP destination port and the TTL of the inner IP packet MUST be
   validated to determine if the received packet can be processed by
   BFD.  BFD packet with inner MAC set to VTEP's MAC address MUST NOT be
   forwarded to VMs.
Would this text address your concern?

Regards,
Greg

On Wed, Jun 5, 2019 at 2:47 PM Joel M. Halpern <jmh@joelhalpern.com>; wrote:

> The inner packet of a VxLAN header with a VNI is a tenant packet for the
> tenant identified by the VNI.  That is the meaning of the inner packet.
>
> If you declare that the flag bits change that meaning, then that flag
> bit has to adjust the packet processing at the VTEP such taht it will
> intercept the packet.  As such, it doesn;t need special inner source or
> dest mac addresses or IP addresses.  In fact, the inner packet can just
> be OAM payload.
>
> If that is not what you intend, then how is it that the VTEP knows that
> the inner addresses are for it to examine, rather than belonging to the
> tenant.  As far as I know we are not free to take addresses away from
> the tenant.
>
> It may be that I am completely missing how this is supposed to work.  If
> so, it needs better explanation.
>
> Yours,
> Joel
>
> On 6/5/19 5:20 PM, Greg Mirsky wrote:
> > Hi Joel,
> > thank you for your review and the pointed questions. Please find my
> > answers, comments in-line and tagged GIM>>.
> >
> > Regards,
> > Greg
> >
> >
> > On Thu, May 23, 2019 at 3:06 PM Joel Halpern via Datatracker
> > <noreply@ietf.org <mailto:noreply@ietf.org>> wrote:
> >
> >     Reviewer: Joel Halpern
> >     Review result: Has Issues
> >
> >     Hello,
> >
> >     I have been selected as the Routing Directorate reviewer for this
> >     draft. The
> >     Routing Directorate seeks to review all routing or routing-related
> >     drafts as
> >     they pass through IETF last call and IESG review, and sometimes on
> >     special
> >     request. The purpose of the review is to provide assistance to the
> >     Routing ADs.
> >     For more information about the Routing Directorate, please see
> >     http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> >
> >     Although these comments are primarily for the use of the Routing
> >     ADs, it would
> >     be helpful if you could consider them along with any other IETF Last
> >     Call
> >     comments that you receive, and strive to resolve them through
> >     discussion or by
> >     updating the draft.
> >
> >     Document: ddraft-ietf-bfd-vxlan-07
> >     Reviewer: your-name
> >     Review Date: date
> >     IETF LC End Date: date-if-known
> >     Intended Status: copy-from-I-D
> >
> >     Summary: This document does not appear to be ready for publication
> as a
> >     Proposed Standard RFC.
> >
> >     Major issues:
> >          The scoping of the BFD usage is unclear.  In places, this looks
> >     like it is
> >          intended to be used by the underlay service provider,  who will
> >     monitor the
> >          connectivity between VTEPs.
> >
> > GIM>> I think that the DCI provider would not be able to instantiate a
> > BFD session using VXLAN encapsulation and, possibly, monitor that VXLAN
> > part of forwarding operates properly. Such BFD session may monitor the
> > path between the two VTEP but, if there exists ECMP environment in the
> > transport, ensuring that that BFD session follows the same path as VXLAN
> > data may be challenging.
> >
> >     In other places it seems to be aimed at
> >          monitoring individual VNIs.
> >
> > GIM>> The BFD session between VTEPs is not actually used to monitor the
> > particular VNI but MAY be used to communicate, as concatenated path
> > state signaling, the change of VNI state using the method described in
> > Section 6.8.17 RFC 5880
> > <https://tools.ietf.org/html/rfc5880#section-6.8.17>;.
> >
> >     This is made worse when the packet format is
> >          laid out.  The inner packet is an Ethernet Packet with an IP
> >     packet (with
> >          UDP, with BFD).  This means that it is a tenant packet.
> >
> > GIM>> Could you please point to the text which suggests that the BFD
> > control packet is a tenant packet? Meant to be delivered to a tenant?
> >
> >     The IP address is
> >          a tenant IP.
> >
> > GIM>> The explanation of the format states in regard to the inner IP
> header:
> >         IP header:
> >
> >           Source IP: IP address of the originating VTEP.
> >
> >           Destination IP: IP address of the terminating VTEP.
> >
> >     But the diagram shows this as being the IP address of the
> >          VTEP.  Which is not a tenant entity.
> >
> >         There is further confusion as to whether the processing is
> >     driven by the VNI
> >         the packet arrived with, or the VNI is ignored.
> >
> > GIM>> The use of VNI is implementation specific. Section 6 states:
> >   6.  Use of the Specific VNI
> >
> >     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.  When the single BFD session is used to
> >     monitor the reachability of the remote VTEP, an implementation SHOULD
> >     choose any of the VNIs but MAY choose VNI = 0.
> >
> >
> >     Minor Issues:
> >         N/A
> >
> >     Nits: N/A
> >
>