The abstract reads this: " This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Virtual eXtensible Local Area Network (VXLAN) tunnels forming up an overlay network."
How do you infer what you said? Dinesh On Fri, Aug 2, 2019 at 5:38 PM Joel M. Halpern <[email protected]> wrote: > I am going by what the draft says its purpose is. If you (Dinesh) want > the draft to fulfill a different purpose, then either ask the chairs to > take this draft back to the WG, or write a separate draft. > As currently written, the behavior Greg proposed meets the needs, and > does so in a way that is consistent with VxLAN. > > Yours, > Joel > > On 8/2/2019 8:30 PM, Dinesh Dutt wrote: > > What is the stated purpose of this BFD session? The VTEP reachability is > > determined by the underlay, I don't need VXLAN-encaped packet for that. > > Do we agree? > > > > If I want to test the VXLAN encap/decap functionality alone, picking any > > single VNI maybe fine. But is this all any network operator wants? Why? > > In what situations has this been a problem? I suspect operators also > > want to verify path continuity over a specific VNI. If you say this is > > not defined by the document, I disagree because the current version > > talks about controlling the number of BFD sessions between the VTEPs > > (see section 3). More importantly, this is a real problem that operators > > like to verify. > > > > Dinesh > > > > On Fri, Aug 2, 2019 at 5:08 PM Joel M. Halpern <[email protected] > > <mailto:[email protected]>> wrote: > > > > What is special about the management VNI is precisely that it is NOT > a > > tenant VNI. The VxLAN administration does know how it allocates VNI > to > > tenants, and which VNI it has allocated. In contrast, it does not > know > > which IP addresses or MAC adddresses teh tenant is using or may plan > > to use. > > > > Yours, > > Joel > > > > On 8/2/2019 6:41 PM, Dinesh Dutt wrote: > > > The assumption of an IP address within any VNI is suspect that > way. > > > What's special about a single VNI, the management VNI? The VTEP IP > > > address does not belong in reality in any VNI. > > > > > > Dinesh > > > > > > On Fri, Aug 2, 2019 at 3:17 PM Joel M. Halpern > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > > > 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]> > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[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]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > <mailto:[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]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > > > <mailto:[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]>> > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > > > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>> > > > <mailto:[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] > >>> > > > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>> > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>> > > > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>>> > > > > > <mailto:[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]>>> > > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>>> > > > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > > > <mailto:[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]>>> > > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>>> <mailto:[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>> > > > > <mailto:[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>>> > > > > > <mailto:[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 > > > > > > > > > > > > > > > > > > > > >
