Re: [RTG-DIR] Rtgdir last call review of draft-ietf-bfd-vxlan-07

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 07 June 2019 01:21 UTC

Return-Path: <jmh@joelhalpern.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 88D96120077; Thu, 6 Jun 2019 18:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 HV7Zrf91qgNF; Thu, 6 Jun 2019 18:21:16 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BABA41200FF; Thu, 6 Jun 2019 18:21:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 45Kl981R5Zz15NyR; Thu, 6 Jun 2019 18:21:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1559870476; bh=0suMN+baZMs3h9n/zISEoe+tjDtOgEWLTcMhttSOdzI=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=lGLMjNL93ZYbGSfft6p7bTkrBhMpMTwiXpo4DvGY7n0DYiT8B1s77nuxtscyVBkpB VfzpKQ9RanGU012j2F9RlEHj6IenCUyCK56wR6J3Xr0Te+fEf10tswBK8FULP+qzX6 0qSIIfCDp720PAej6ADLRB0UYdk6LnhlY7gUWXYI=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 45Kl9720R6z15NjH; Thu, 6 Jun 2019 18:21:14 -0700 (PDT)
Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-bfd-vxlan-07
From: "Joel M. Halpern" <jmh@joelhalpern.com>
To: Greg Mirsky <gregimirsky@gmail.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>
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> <CA+RyBmVAhKGCxBPujtBU54wPCqY39zr_U8TA6rfbzQcaHm9oCw@mail.gmail.com> <4903980b-49e2-1f8c-7575-2af4614e2c6b@joelhalpern.com>
Message-ID: <83e80a61-39f5-8bd2-09df-5692fda8bce8@joelhalpern.com>
Date: Thu, 6 Jun 2019 21:21:14 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <4903980b-49e2-1f8c-7575-2af4614e2c6b@joelhalpern.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/x9MUG66vitKuZx389CZqxGqo1aE>
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 01:21:20 -0000

I have looked again at the base VxLAN spec, the BFD spec, and the draft 
we are discussing.
There seems to be a MUCH simpler frame encapsulation which avoids 
messing with the inner Ethernet header address space.

1) Declare that VxLAN BFD always uses VNI 0
2) Use one of the reserved bits, and define it to mean that the VxLAN 
payload, when the VNI is 0, is a BFD payload without any Ethernet, IP, 
or UDP header.

That would seem to monitor what the document says it wants to monitor.

Yours,
Joel

On 6/6/19 8:53 PM, Joel M. Halpern wrote:
> There is a reason the "Outer Ethernet Header" in section 5 of 7348 is 
> labeled as "example".  That outer header will actually vary hop by hop 
> along the IP network between the source VTEP and the desination VTEP.
> Unless the source and destination VTEP are one IP hope apart, the source 
> VTEP will not even know the Ethernet MAC address of the destination VP. 
> It will simply address the outer IP packet, and let IP rotuing do its 
> job (that is the whole point of VxLAN.)
> 
> More importantly, it is not associated with any VNI as it is the outer 
> header.  Your usage is as an inner Ethernet Destination address.  The 
> inner Ethernet header is the tenant space.  The VTEPs do not impinge on 
> that space.  Nor use any values from it.
> 
> Yours,
> Joel
> 
> On 6/6/19 8:18 PM, Greg Mirsky wrote:
>> 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 
>> <mailto: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>
>>      > <mailto: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>>
>>      >     <mailto: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
>>      >      >
>>      >
>>
> 
>