Your response seems to miss two points:
First, the problem you describe is not what the document says it is
solving. To the degree it discusses it at all, the document says " 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. "
Second, you assume the existence of an IP address for a VTEP within a
VNI. As with the MAC address, the VTEP does not have an IP address
within the VNI. Some implementations may have created such a thing, but
the general construct, as defined to date, does not support such.
In short, you are requiring a behavior that violates the architectural
structure of overlay / underlay separation, and common usage. And you
are doing so to support a use case that the working group has not
indicated in the document as important.
Yours,
Joel
On 8/2/2019 5:01 PM, Dinesh Dutt wrote:
Joel,
You understood correctly.
The VNIs may not share fate due to misconfiguration. And I strongly
suspect someone will want to use BFD for that because its about checking
path continuity as stated by the draft. As long as there's a valid IP
(because it's BFD) owned by the VTEP in that VNI, you can use BFD in
that VNI. Thats all that you need to dictate. That IP address has a MAC
address and you can use that on the inner frame. That is all normal
VXLAN processing. The outer IP is always that of the VTEP.
Dinesh
On Fri, Aug 2, 2019 at 11:03 AM Joel M. Halpern <[email protected]
<mailto:[email protected]>> wrote:
If I am reading your various emails correctly Dinesh (and I may have
missed something) you are trying to use the MAC address because you
want
to be able to send these BFD packets over arbitrary VNI to monitor the
VNI. That is not a requirement identified in the document. It is not
even a problem I understand, since all the VNI between an ingress and
egress VTEP share fate.
Yours,
Joel
On 8/2/2019 1:44 PM, Dinesh Dutt wrote:
> Thanks for verifying this. On Linux and hardware routers that I'm
aware
> of (Cisco circa 2012 and Cumulus), the physical MAC address is
reused
> across the VNIs on the VTEP. Did you check on a non-VMW device?
This is
> more for my own curiosity.
>
> To address the general case, can we not define a well-known (or
reserve
> one) unicast MAC address for use with VTEP? If the MAC address is
> configurable in BFD command, this can be moot.
>
> Dinesh
>
> On Fri, Aug 2, 2019 at 10:27 AM Santosh P K
> <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
>
> I have cross checked point raised about MAC address usage. It is
> possible that tenant could be using physical MAC address and
when a
> packet comes with valid VNI with a MAC address that is being
used by
> tenant then packet will be sent to that tenant. This rules
out the
> fact that we could use physical MAC address as inner MAC to
ensure
> packets get terminated at VTEP itself.
>
> Thanks
> Santosh P K
>
> On Wed, Jul 31, 2019 at 11:00 AM Santosh P K
> <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
> wrote:
>
> Joel,
> Thanks for your inputs. I checked implementation within
> Vmware. Perhaps I should have been more clear about MAC
address
> space while checking internally. I will cross check again for
> the same and get back on this list.
>
> Thanks
> Santosh P K
>
> On Wed, Jul 31, 2019 at 10:54 AM Joel M. Halpern
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
>
> Sorry to ask a stupid question. Whose implementation?
>
> The reason I ask is that as far as I can tell, since the
> tenant does not
> have any control access to the VTEP, there is no
reason for
> the VTEP to
> have a MAC address in the tenant space. Yes, the
device has
> a physical
> MAC address. But the tenant could well be using that MAC
> address. Yes,
> they would be violating the Ethernet spec. But the whole
> point of
> segregation is not to care about such issues.
>
> On the other hand, if you tell me that the VMWare
> implementation has an
> Ethernet address that is part of the tenant space, well,
> they made up
> this particular game.
>
> Yours,
> Joel
>
> On 7/31/2019 1:44 PM, Santosh P K wrote:
> > I have checked with implementation in data path.
When we
> receive a
> > packet with valid VNI then lookup for MAC will
happen and
> it is VTEP own
> > MAC then it will be trapped to control plane for
> processing. I think we
> > can have following options
> > 1. Optional managment VNI
> > 2. Mandatory inner MAC set to VTEP mac
> > 3. Inner IP TTL set to 1 to avoid forwarding of packet
> via inner IP
> > address.
> >
> >
> > Thoughts?
> >
> > Thansk
> > Santosh P K
> >
> > On Wed, Jul 31, 2019 at 9:20 AM Greg Mirsky
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>> wrote:
> >
> > Hi Dinesh,
> > thank you for your consideration of the
proposal and
> questions. What
> > would you see as the scope of testing the
> connectivity for the
> > specific VNI? If it is tenant-to-tenant, then
VTEPs
> will treat these
> > packets as regular user frames. More likely, these
> could be Layer 2
> > OAM, e.g. CCM frames. The reason to use 127/8 for
> IPv4, and
> > 0:0:0:0:0:FFFF:7F00:0/104 for IPv6 is to safeguard
> from leaking
> > Ethernet frames with BFD Control packet to a
tenant.
> > You've suggested using a MAC address to trap the
> control packet at
> > VTEP. What that address could be? We had proposed
> using the
> > dedicated MAC and VTEP's MAC and both raised
concerns
> among VXLAN
> > experts. The idea of using Management VNI may
be more
> acceptable
> > based on its similarity to the practice of using
> Management VLAN.
> >
> > Regards,
> > Greg
> >
> > On Wed, Jul 31, 2019 at 12:03 PM Dinesh Dutt
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>>
> wrote:
> >
> > Hi Greg,
> >
> > As long as the inner MAC address is such
that the
> packet is
> > trapped to the CPU, it should be fine for
use as
> an inner MAC is
> > it not? Stating that is better than trying to
> force a management
> > VNI. What if someone wants to test
connectivity
> on a specific
> > VNI? I would not pick a loopback IP
address for
> this since that
> > address range is host/node local only. Is
there a
> reason you're
> > not using the VTEP IP as the inner IP
address ?
> >
> > Dinesh
> >
> > On Wed, Jul 31, 2019 at 5:48 AM Greg Mirsky
> > <[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>> wrote:
> >
> > Dear All,
> > thank you for your comments,
suggestions on
> this issue,
> > probably the most challenging for this
> specification. In the
> > course of our discussions, we've agreed to
> abandon the
> > request to allocate the dedicated MAC
address
> to be used as
> > the destination MAC address in the inner
> Ethernet frame.
> > Also, earlier using VNI 0 was changed from
> mandatory to one
> > of the options an implementation may
offer to
> an operator.
> > The most recent discussion was whether
VTEP's
> MAC address
> > might be used as the destination MAC
address
> in the inner
> > Ethernet frame. As I recall it, the
comments
> from VXLAN
> > experts equally split with one for it
and one
> against. Hence
> > I would like to propose a new text to
resolve
> the issue. The
> > idea is to let an operator select
Management
> VNI and use
> > that VNI in VXLAN encapsulation of BFD
> Control packets:
> > NEW TEXT:
> >
> > An operator MUST select a VNI
number to
> be used as
> > Management VNI. VXLAN packet for
> Management VNI MUST NOT
> > be sent to a tenant. VNI number 1 is
> RECOMMENDED as the
> > default for Management VNI.
> >
> > With that new text, what can be the
value of
> the destination
> > MAC in the inner Ethernet? I tend to
believe
> that it can be
> > anything and ignored by the reciever VTEP.
> Also, if the
> > trapping is based on VNI number, the
> destination IP address
> > of the inner IP packet can from the range
> 127/8 for IPv4,
> > and for IPv6 from the range
> 0:0:0:0:0:FFFF:7F00:0/104. And
> > lastly, the TTL to be set to 1 (no
change here).
> >
> > Much appreciate your comments,
questions, and
> suggestions.
> >
> > Best regards,
> > Greg
> >
>
