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