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

Greg Mirsky <gregimirsky@gmail.com> Fri, 07 June 2019 00:18 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 734A312010D; Thu, 6 Jun 2019 17:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 vhCK3zNns9B0; Thu, 6 Jun 2019 17:18:21 -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 3ECB01200FD; Thu, 6 Jun 2019 17:18:21 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id a25so264993lfg.2; Thu, 06 Jun 2019 17:18:21 -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=2gAv6iJxOVjXD6ovFqTB8/lmq86/+Id7R450wTdGbRM=; b=J8N5Fysxd98xYMonkbB9W6WaY750l4Dv2qO3fpGIoInFeSFlD2oXNxPPeNdAmPDFpp zN5J/flpworAXRBWzNFtdIZvNZ/ePjJANyzKh3NnIr2N3SA7zbE+HMJVhDuIKDv5kqIO xhzv5rFMCkXnyc9e0r0gAr6oCI1QhYHWO6DWY3NQ53tdkEm7W1gziHpv9nokYuALbMFS 8hX+w6dlaGA0/PE8R3oLkuC1jY0Pt8rYtv40m8EaFICoZjamPkbbtyJCu5lM7Y4h5LTx 5QDUx16Cxp5qBat3SSy+QUU5CUfHQ5tiEuzc+X19nbxUT3PE5iJEpghS8J1JoXIOpANF TeDQ==
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=2gAv6iJxOVjXD6ovFqTB8/lmq86/+Id7R450wTdGbRM=; b=IsJz0nh/x9AT7QmvXSff2spxt1ZvDUo88fy6D8P0n1sZ+BQgRY6q5tgPL2Y/cwggIi ZYfYy8SQmmwFeTY+pksT7huGf/3JzW0d3/PlSoQYIN1WwnX5twzs36K2kvtl+g1xvLeA ywrewyqpDStzFOMQpDS1tTijcjEF47WiSf21983NGVxchAPTcICzEiYKv9iYfoxtx9SO zjbzyTDBm3sVLwsXyVX8m+nHfAea16GyKxbZiLL+WLnLMw1Y83XrwZWVMRWZ5gEG4q6D CmKvy73gG6Q/7B9rsXipxXZuKn4NaoE0nMSStxpT3t6F6hqrkfOw7d0K9uuFGP53MEys Bwkw==
X-Gm-Message-State: APjAAAVm9lB2EgpfKlbw3ydSzmtrrARIlwAzdAEypEgzVgqvYmFAqyQg SL5GPDXqqJfHJhnSUDEckz3I0YVrbbNKZPGiRa/xI124iLE=
X-Google-Smtp-Source: APXvYqykTflPjaystIv3ZSwCoxN0j0HFtCHErdefFZMByk63fUghg9fryuYfU+DejeoTaWPdExyMQ2JCzRFe2KSRPOo=
X-Received: by 2002:ac2:569c:: with SMTP id 28mr11751814lfr.147.1559866699287; Thu, 06 Jun 2019 17:18:19 -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> <CA+RyBmXmuL+v55SEgHfx-E=bkpLSZe4ceZG5k6e4R=QSuWQ=Ag@mail.gmail.com> <a8ead230-a09d-8ab9-5263-7414d2bd1acc@joelhalpern.com>
In-Reply-To: <a8ead230-a09d-8ab9-5263-7414d2bd1acc@joelhalpern.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 6 Jun 2019 17:18:08 -0700
Message-ID: <CA+RyBmVAhKGCxBPujtBU54wPCqY39zr_U8TA6rfbzQcaHm9oCw@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="0000000000008210e6058ab0c4d3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/qh5KeeUht4jwM2Gop-oK4rDAkl8>
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, 07 Jun 2019 00:18:25 -0000

Hi Joel,
thank you for the clarification of your concern. For the inner Ethernet
header, the destination and source MAC addresses are as described in
Section 5 of RFC 7348 for VXLAN's outer Ethernet header:
     The outer destination MAC address in this frame may
      be the address of the target VTEP or of an intermediate Layer 3
      router.
As I understand this example, a VTEP must have MAC address assigned. The
address used as the source MAC address of the outer Ethernet frame and may
be used by a remote VTEP as destination MAC address in the outer Ethernet
frame. This MAC address is not, as I understand, associated with any VNI.
Perhaps we can add text to point to Section 5 RFC 7348 and how VTEP MAC
address is used in the outer Ethernet header of a VXLAN packet. If you
agree, I'll polish the new update in a day.

Regards,
Greg

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

> I am having trouble parsing your response.  Apologies.
> The first part talks about a VTEP receiving a packet, and determining if
> there is a receiver VM for the inner MAC.  That is a quote from 7348
> Section 4.1.  I understand it.
>
> You then go on to quote from section 5 of the BFD over VxLAN
> specification saying that it modifies this to specify that the VTEP
> checks for its own MAC address.
> The only problem is that the VTEP is not part of the tenant network.
> Any MAC address you want it to use may be in use by the tenant network.
> As far as I know, in normal VxLAN oepration, VTEPs do NOT have their own
> MAC addresses within the scope of the VNI.
>
> Now, if you say that BFD will only be used with VNI 0 (i.e. a VNI that
> is not assigned to a tenant), then the conflict goes away.  But again,
> there is no need for special MAC checking.  Just declare that the VTEP
> looks for OAM content on VNI 0.
>
> So no, your proposed change does not address my concern, as "VTEP's MAC
> address is not, to the best of my knowledge, a well-defined term.  I am
> happy to be shown where such a thing is defined for use within tenant VNIs.
>
> Yours,
> Joel
>
> On 6/5/19 9:55 PM, Greg Mirsky wrote:
> > 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
> > <mailto: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>
> >     <mailto: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
> >      >
> >
>