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

["Joel M. Halpern" <[e-mail]>]

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 <[e-mail] 
>> <mailto:[e-mail]>> 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
>>     <[e-mail] <mailto:[e-mail]>
>>      > <mailto:[e-mail] <mailto:[e-mail]>>> 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
>>      >      > <[e-mail] <mailto:[e-mail]>
>>     <mailto:[e-mail] <mailto:[e-mail]>>
>>      >     <mailto:[e-mail] <mailto:[e-mail]>
>>     <mailto:[e-mail] <mailto:[e-mail]>>>> 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
>>      >      >
>>      >
>>
> 
>