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