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@xxxxxxxxxxxxxxx
<mailto:jmh@xxxxxxxxxxxxxxx>> 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@xxxxxxxxxxxxxxx <mailto:jmh@xxxxxxxxxxxxxxx>
> <mailto:jmh@xxxxxxxxxxxxxxx <mailto:jmh@xxxxxxxxxxxxxxx>>> 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@xxxxxxxx <mailto:noreply@xxxxxxxx>
<mailto:noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>>
> <mailto:noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>
<mailto:noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>>>> 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
> >
>
