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]> 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]>> 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]>> 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]>> 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 > > >
