Hi Joel, Perhaps we need to say use of an address owned by the device containing the VTEP.
Or are you suggesting that the use of the loopback address space is a MUST? Anoop On Mon, Oct 28, 2019 at 10:22 AM Joel M. Halpern <j...@joelhalpern.com> wrote: > There is something I am missing in your assumption about IRB. > > As I understand VxLAN, the VTEP is under the control of the operator. > As such, it is a pure bridge. If you run IRB behind it, that is fine. > Yes, an operator may offer IRB. But as I understand it, conceptually, > in terms of the VxLAN architecture the IRB is an entity behind the VTEP, > not part of the VTEP. > > Yours, > Joel > > On 10/28/2019 12:23 PM, Anoop Ghanwani wrote: > > Santosh, > > > > Does it have to be a MUST? What if I am running IRB and there are IP > > addresses per VNI assigned to the VTEPs? Why can the operator not > > choose to use those? > > > > Anoop > > > > On Mon, Oct 28, 2019 at 7:51 AM Santosh P K > > <santosh.pallaga...@gmail.com <mailto:santosh.pallaga...@gmail.com>> > wrote: > > > > Dinesh, Anoop et all, > > Lets us know if this text works for 127/8 address range? > > > > [proposed text for firewall] > > > > "As per section 4 inner destination IP address MUST be set to 127/8 > > address. There may be firewall configured on VTEP to block 127/8 > > address range if set as destination IP in inner IP header. It is > > recommended to allow 127/8 range address through firewall only if > > 127/8 IP address is set as destination address in inner IP header." > > > > > > In section 4 we are talking about using 127/8 and not really giving > > reason why. I think we should have text as RFC 5884 has mentioned > > with below text. > > > > [From RFC 5884] > > "The motivation for using the address range 127/8 is the same as > > specified in Section 2.1 of [RFC4379] > > <https://tools.ietf.org/html/rfc4379#section-2.1>. This is an > > exception to the behavior defined in [RFC1122 > > <https://tools.ietf.org/html/rfc1122>]." > > > > > > > > Thanks > > Santosh P K > > > > > > > > On Thu, Oct 24, 2019 at 1:24 AM Dinesh Dutt <did...@gmail.com > > <mailto:did...@gmail.com>> wrote: > > > > Looks good to me Greg. I see that the text around the use of the > > inner IP address as also quite acceptable. Will you add any > > words about the firewall? > > > > Dinesh > > > > On Wed, Oct 23, 2019 at 8:36 PM, Greg Mirsky > > <gregimir...@gmail.com <mailto:gregimir...@gmail.com>> wrote: > >> Hi Dinesh, et al., > >> please check the updated version that removed the reference to > >> Hypervisor in the text and Figure 1. > >> > >> Regards, > >> Greg > >> > >> On Wed, Oct 23, 2019 at 10:47 AM Santosh P K > >> <santosh.pallaga...@gmail.com > >> <mailto:santosh.pallaga...@gmail.com>> wrote: > >> > >> Dinesh, > >> Please see my inline comments [SPK] > >> > >> > >> - In section 3, there's a sentence that is: "BFD > >> packets intended for a Hypervisor VTEP MUST NOT..". I > >> recommend getting rid of the word "Hypervisor" ashe > >> logic applies to any VTEP. > >> > >> [SPK] Thanks for comments. We will change this. > >> > >> - You already explained the precedence of the use of > >> 127/8 address in the inner header in MPLS. I have no > >> specific comments in that area. I have only two > >> questions: > >> - Has anybody verified that the use of 127/8 > >> address (and the right MAC) works with existing > >> implementations, including the silicon ones? If this > >> doesn't work there, is it worth adding the possibilit > >> y of another address, one that is owned by the VTEP > node? > >> > >> - Do we know if Firewalls stop such VXLAN packets? > >> I ask this because VXLAN has an IP header and I don't > >> know if firewalls stop packets with 127/8 in the inner > >> header. If not, is it worth adding a sentence to say > >> that firewalls allow such packets? The use of a > >> non-127/8 address may alleviate this case as well. > >> > >> [SPK] I think we may need to add the text about firewall > >> as some checks in firewall will be there if they are not > >> already using MPLS OAM which has inner IP header with > >> 127/8 address range. > >> > >> > >> The rest of the draft looks good to me, > >> > >> Dinesh > >> > >> On Wed, Oct 23, 2019 at 7:58 AM, Greg Mirsky > >> <gregimir...@gmail.com <mailto:gregimir...@gmail.com>> > >> wrote: > >>> Hi Dinesh, > >>> I greatly appreciate your comments. Please heave a > >>> look at the attached copy of the working version and > >>> its diff to -07 (latest in the datatracker). > >>> > >>> Regards, > >>> Greg > >>> > >>> On Tue, Oct 22, 2019 at 9:52 PM Dinesh Dutt > >>> <did...@gmail.com <mailto:did...@gmail.com>> wrote: > >>> > >>> I have the same feeling as Anoop. Greg, can you > >>> please point me to the latest draft so that I can > >>> quickly glance through it to be doubly sure, > >>> > >>> Dinesh > >>> > >>> On Wed, Oct 23, 2019 at 4:35 AM, Anoop Ghanwani > >>> <an...@alumni.duke.edu > >>> <mailto:an...@alumni.duke.edu>> wrote: > >>>> Greg, > >>>> > >>>> I think the draft is fine as is. > >>>> > >>>> I discussion with Xiao Min was about #3 and I > >>>> see that as unnecessary until we have a draft > >>>> that explains why that is needed in the context > >>>> of the NVO3 architecture. > >>>> > >>>> Anoop > >>>> > >>>> On Tue, Oct 22, 2019 at 11:17 AM Greg Mirsky > >>>> <gregimir...@gmail.com > >>>> <mailto:gregimir...@gmail.com>> wrote: > >>>> > >>>> Hi Anoop, et al., > >>>> I agree with your understanding of what is > >>>> being defined in the current version of the > >>>> BFD over VxLAN specification. But, as I > >>>> understand, the WG is discussing the scope > >>>> before the WGLC is closed. I believe there > >>>> are three options: > >>>> > >>>> 1. single BFD session between two VTEPs > >>>> 2. single BFD session per VNI between two > VTEPs > >>>> 3. multiple BFD sessions per VNI between > >>>> two VTEPs > >>>> > >>>> The current text reflects #2. Is WG accepts > >>>> this scope? If not, which option WG would > >>>> accept? > >>>> > >>>> Regards, > >>>> Greg > >>>> > >>>> On Tue, Oct 22, 2019 at 2:09 PM Anoop > >>>> Ghanwani <an...@alumni.duke.edu > >>>> <mailto:an...@alumni.duke.edu>> wrote: > >>>> > >>>> I concur with Joel's assessment with the > >>>> following clarifications. > >>>> > >>>> The current document is already capable > >>>> of monitoring multiple VNIs between VTEPs. > >>>> > >>>> The issue under discussion was how do we > >>>> use BFD to monitor multiple VAPs that > >>>> use the same VNI between a pair of > >>>> VTEPs. The use case for this is not > >>>> clear to me, as from my understanding, > >>>> we cannot have a situation with multiple > >>>> VAPs using the same VNI--there is 1:1 > >>>> mapping between VAP and VNI. > >>>> > >>>> Anoop > >>>> > >>>> On Tue, Oct 22, 2019 at 6:06 AM Joel M. > >>>> Halpern <j...@joelhalpern.com > >>>> <mailto:j...@joelhalpern.com>> wrote: > >>>> > >>>> From what I can tell, there are two > >>>> separate problems. > >>>> The document we have is a VTEP-VTEP > >>>> monitoring document. There is no > >>>> need for that document to handle the > >>>> multiple VNI case. > >>>> If folks want a protocol for doing > >>>> BFD monitoring of things behind the > >>>> VTEPs (multiple VNIs), then do that > >>>> as a separate document. The > >>>> encoding will be a tenant encoding, > >>>> and thus sesparate from what is > >>>> defined in this document. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 10/21/2019 5:07 PM, Jeffrey Haas > >>>> wrote: > >>>> > Santosh and others, > >>>> > > >>>> > On Thu, Oct 03, 2019 at 07:50:20PM > >>>> +0530, Santosh P K wrote: > >>>> >> Thanks for your explanation. > >>>> This helps a lot. I would wait for > more > >>>> >> comments from others to see if > >>>> this what we need in this draft to be > >>>> >> supported based on that we can > >>>> provide appropriate sections in the > >>>> draft. > >>>> > > >>>> > The threads on the list have > >>>> spidered to the point where it is > >>>> challenging > >>>> > to follow what the current status > >>>> of the draft is, or should be. :-) > >>>> > > >>>> > However, if I've followed things > >>>> properly, the question below is > >>>> really the > >>>> > hinge point on what our > >>>> encapsulation for BFD over vxlan > >>>> should look like. > >>>> > Correct? > >>>> > > >>>> > Essentially, do we or do we not > >>>> require the ability to permit > >>>> multiple BFD > >>>> > sessions between distinct VAPs? > >>>> > > >>>> > If this is so, do we have a sense > >>>> as to how we should proceed? > >>>> > > >>>> > -- Jeff > >>>> > > >>>> > [context preserved below...] > >>>> > > >>>> >> Santosh P K > >>>> >> > >>>> >> On Wed, Sep 25, 2019 at 8:10 AM > >>>> <xiao.m...@zte.com.cn > >>>> <mailto:xiao.m...@zte.com.cn>> wrote: > >>>> >> > >>>> >>> Hi Santosh, > >>>> >>> > >>>> >>> > >>>> >>> With regard to the question > >>>> whether we should allow multiple BFD > >>>> sessions > >>>> >>> for the same VNI or not, IMHO we > >>>> should allow it, more explanation as > >>>> >>> follows. > >>>> >>> > >>>> >>> Below is a figure derived from > >>>> figure 2 of RFC8014 (An Architecture > for > >>>> >>> Data-Center Network > >>>> Virtualization over Layer 3 (NVO3)). > >>>> >>> > >>>> >>> | > >>>> Data Center Network (IP) | > >>>> >>> | > >>>> | > >>>> >>> > >>>> > +-----------------------------------------+ > >>>> >>> | > >>>> | > >>>> >>> | > >>>> Tunnel Overlay | > >>>> >>> > >>>> +------------+---------+ > >>>> +---------+------------+ > >>>> >>> | > >>>> +----------+-------+ | | > >>>> +-------+----------+ | > >>>> >>> | | Overlay > >>>> Module | | | | Overlay > >>>> Module | | > >>>> >>> | > >>>> +---------+--------+ | | > >>>> +---------+--------+ | > >>>> >>> | | > >>>> | | | | > >>>> >>> NVE1 | | > >>>> | | | | > >>>> NVE2 > >>>> >>> | > >>>> +--------+-------+ | | > >>>> +--------+-------+ | > >>>> >>> | |VNI1 VNI2 VNI1 > >>>> | | | | VNI1 VNI2 VNI1 | | > >>>> >>> | > >>>> +-+-----+----+---+ | | > >>>> +-+-----+-----+--+ | > >>>> >>> |VAP1| VAP2| | > >>>> VAP3 | |VAP1| VAP2| | VAP3| > >>>> >>> > >>>> +----+-----+----+------+ > >>>> +----+-----+-----+-----+ > >>>> >>> | | | > >>>> | | | > >>>> >>> | | | > >>>> | | | > >>>> >>> | | | > >>>> | | | > >>>> >>> > >>>> > -------+-----+----+-------------------+-----+-----+------- > >>>> >>> | | | > >>>> Tenant | | | > >>>> >>> TSI1 | TSI2| | > >>>> TSI3 TSI1| TSI2| |TSI3 > >>>> >>> +---+ +---+ > >>>> +---+ +---+ +---+ +---+ > >>>> >>> |TS1| |TS2| > >>>> |TS3| |TS4| |TS5| |TS6| > >>>> >>> +---+ +---+ > >>>> +---+ +---+ +---+ +---+ > >>>> >>> > >>>> >>> To my understanding, the BFD > >>>> sessions between NVE1 and NVE2 are > >>>> actually > >>>> >>> initiated and terminated at VAP > >>>> of NVE. > >>>> >>> > >>>> >>> If the network operator want to > >>>> set up one BFD session between VAP1 of > >>>> >>> NVE1 and VAP1of NVE2, at the > >>>> same time another BFD session > >>>> between VAP3 of > >>>> >>> NVE1 and VAP3 of NVE2, although > >>>> the two BFD sessions are for the same > >>>> >>> VNI1, I believe it's reasonable, > >>>> so that's why I think we should allow > it > >>>> > >>>> > _______________________________________________ > >>>> nvo3 mailing list > >>>> n...@ietf.org <mailto:n...@ietf.org> > >>>> > https://www.ietf.org/mailman/listinfo/nvo3 > >>>> >
