Hi Dinesh, if I recall correctly, T.Sridhar has noted that VTEP's MAC must not be used as the destination MAC address in the inner Ethernet frame. Also, I should have been more precise in the proposed text, please see the updated version to stress that the management VNI MUST NOT be one of the tenant's VNIs: NEW TEXT:
An operator MUST select a VNI number to be used as Management VNI. Management VNI number MUST NOT be one of the tenant's VNIs to prevent sending VXLAN packets received on Management VNI to a tenant. VNI number 1 is RECOMMENDED as the default for Management VNI. On Wed, Jul 31, 2019 at 2:25 PM Dinesh Dutt <did...@gmail.com> wrote: > Hi Greg, > > On Wed, Jul 31, 2019 at 9:20 AM Greg Mirsky <gregimir...@gmail.com> 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. >> > > If you use the inner IP address as the VTEP IP address, then use the MAC > address that the VTEP would respond with when replying to an ARP for that > VTEP IP address. If a VXLAN expert disagrees with this, could you kindly > tell me who it is so that I can understand their disagreement? So this > handles the case where the VNI is not a user-tenant VNI. If the VNI used in > the BFD packet is a user-tenant VNI, then the receiving VTEP MUST have an > IP address in that VNI (mapped to a VRF) else you cannot use that VNI in > the BFD packet. Why won't this combination address all the cases you've > listed? What am I missing? Define VNI 1 as a possible use, not VNI 0. I > objected to VNI 0 because there are too many switching siicon out there and > some of them will not be able to handle this scenario. > > Dinesh > >> >> Regards, >> Greg >> >> On Wed, Jul 31, 2019 at 12:03 PM Dinesh Dutt <did...@gmail.com> 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 <gregimir...@gmail.com> >>> 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 >>>> >>>
