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

From: Greg Mirsky <[email-masked]>
Date: Wed, 5 Jun 2019 14:20:57 -0700

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 <
[email-masked]> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 5 Jun 2019 17:47:49 -0400

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:
> On Thu, May 23, 2019 at 3:06 PM Joel Halpern via Datatracker 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Reviewer: Joel Halpern
>     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
>     request. The purpose of the review is to provide assistance to the
>     Routing ADs.
>     Although these comments are primarily for the use of the Routing
>     ADs, it would
>     comments that you receive, and strive to resolve them through
>     discussion or by
>     updating the draft.
> 
>          The scoping of the BFD usage is unclear.  In places, this looks
>     like it is
> 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.
> 
> 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>.
> 
>          laid out.  The inner packet is an Ethernet Packet with an IP
>     packet (with
>         There is further confusion as to whether the processing is
>     driven by the VNI

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 5 Jun 2019 18:55:42 -0700

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 5 Jun 2019 23:20:38 -0400

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:
> 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:
> BFD over VXLAN specification in section 5 clarifies the processing of 
> the received VXLAN packet by the remote VXLAN:
> On Wed, Jun 5, 2019 at 2:47 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Reviewer: Joel Halpern
>      >     they pass through IETF last call and IESG review, and
>     sometimes on
>      >     special
>      >     be helpful if you could consider them along with any other
>     IETF Last
>      >     Call

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 6 Jun 2019 17:18:08 -0700

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 6 Jun 2019 20:53:11 -0400

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:
> 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 <[email-masked] 
>      > On Wed, Jun 5, 2019 at 2:47 PM Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     The inner packet of a VxLAN header with a VNI is a tenant
>     packet for
>      >     the
>      >      > 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
>      >      > <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> 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
>      >      >
>      >
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 6 Jun 2019 21:21:14 -0400

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:
>> 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:
>> 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
>>
>>      > 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
>>      > <mailto:[email-masked] <mailto:[email-masked]>>> 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
>>      >      > <[email-masked] <mailto:[email-masked]>
>>      >     <mailto:[email-masked] <mailto:[email-masked]>
>>      >      >
>>      >      >     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
>>      >      >
>>      >
>>
> 
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 6 Jun 2019 19:43:32 -0700

Hi Joel,
>     MAC addresses within the scope of the VNI.
I agree and note that VTEP's MAC addresses used in the inner Ethernet
header don't have to be associated with a VNI. They are the same as used in
the outer Ethernet header. And the BFD over VXLAN specification does modify
the processing of the inner Ethernet frame comparing to the procedure
described in RFC 7348.
I don't say that the described method of encapsulating BFD over VXLAN is
the only one, but it is what has been discussed and supported by BFD WG.
Also, AFAIK, at least one implementation already exists.

Regards,
Greg

On Thu, Jun 6, 2019 at 5:53 PM Joel M. Halpern <[email-masked]> wrote:

> >      >      >     request. The purpose of the review is to provide
> >     assistance
> >      >     to the
> >      >      >     Routing ADs.
> >      >      >          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
> >      >      > BFD session using VXLAN encapsulation and, possibly,
> >     monitor that
> >      >     VXLAN
> >      >      > 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.
> >      >      >
> >      >      > GIM>> The explanation of the format states in regard to
> >     the inner
> >      >     IP header:
> >      >      >         IP header:
> >      >      >
> >      >      >     In most cases, a single BFD session is sufficient for
> the
> >      >     given VTEP

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 6 Jun 2019 23:05:11 -0400

As far as I can tell, what you describe violates the base VxLAN 
specification by requiring that the VTEP have a MAC address within the 
tenant space.

If there were no other way to make BFD work for VxLAN except biolating 
the spec, then I would epect the document to be very explicit that it 
was taking MAC address away from the tenant space.

Given that there clearly are other ways to achieve the goal that do not 
violate the underlying VxLAN spec, I think the IETF is obliged to use 
something else.

Yours,
Joel

PS: Having said that, I grant that for this purpose I have no more 
standing than any other WG member.

On 6/6/19 10:43 PM, Greg Mirsky wrote:
> header don't have to be associated with a VNI. They are the same as used 
> in the outer Ethernet header. And the BFD over VXLAN specification does 
> modify the processing of the inner Ethernet frame comparing to the 
> procedure described in RFC 7348.
> On Thu, Jun 6, 2019 at 5:53 PM Joel M. Halpern <[email-masked] 
>     Ethernet
>      > On Wed, Jun 5, 2019 at 8:20 PM Joel M. Halpern
>      >     As far as I know, in normal VxLAN oepration, VTEPs do NOT
>     have their
>      >     own
>      >      > VXLAN-encapsulated frame received by VTEP must be
>     forwarded to a VM
>      >      >     Once a packet is received, VTEP MUST validate the
>     packet.  If the
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >      >
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>> wrote:
>      >      >      >
>      >      >      >     be helpful if you could consider them along
>     with any other
>      >      >     IETF Last
>      >      >      >     Call
>      >      >      >          The scoping of the BFD usage is unclear. 
>     In places,
>      >      >     this looks
>      >      >      >     like it is
>      >      >      >           Destination IP: IP address of the
>     terminating VTEP.
>      >      >      >
>      >      >      >     But the diagram shows this as being the IP
>     address of the
>      >      >      >     In most cases, a single BFD session is
>     sufficient for the
>      >      >     given VTEP